Fear of responsibility is part of human nature as much as fear of the dark. We software developers are no different.
I have made many excuses in my career, especially early on. Later on, I have heard many excuses from the standpoints of a colleague, team leader, and client.
Here are some of the most common programmer excuses along with a translation from dev-speak into human English and some thoughts on how to handle each situation.
I don’t have an eye for design
“I just have no feel for visual things, you know, which colors to put together. I think we need to hire a designer for this signup form.”
This excuse is made when:
The developer is assigned a task that requires a bit of visual thinking or creativity. This often happens if the team doesn’t have an in-house designer.
What it actually means:
The developer doesn’t want to leave the comfort zone that is his IDE. Lots of us, myself included, have tried to stay away from design matters.
How to react to it:
Help your programmers understand that there is logic to design. There are plenty of short courses that will help them understand the basics of space, text, and color. I recommend this free one from Coursera.
An appeal to team spirit can also be effective, as well as leading by example — how many things do you do that aren’t exactly in your job description?
How to make the situation worse:
“Well, sometimes you just gotta do something you don’t feel like doing. For example, I don’t feel like having this conversation for the 100th time but you don’t see me complaining.”
I don’t have time for refactoring
“I can make this change but I don’t have time to restructure all the parts that connect to it.”
This excuse is made when:
You are about to break a design principle or best practice to get a change deployed quickly.
What it actually means:
This is usually a sign either of irresponsibility or lack of forward-thinking. Or, sometimes, a lack of understanding of software architecture. This last one is the worst option because it’s the most difficult to remedy.
How to react to it:
If it’s not an urgent change, insist on immediate refactoring. If it is indeed urgent, create a separate task for refactoring and put it in the queue.
How to make the situation worse:
“Just make the thing work ASAP.”
It worked on my machine
“I don’t know why users can’t log into the site, I logged in perfectly with my Gmail on localhost.”
This excuse is made when:
An update is deployed to production and only then discovered to be faulty.
What it actually means:
There is a lack of proper testing, either automated or manual. The programmer is saving time at the expense of reliability and user experience.
Alternatively, the development environment is a variable in the software, which it really shouldn’t be if you know what’s good for you.
How to react to it:
Ask them how they tested the change. Work with them to define a better testing process. Consider using Docker or some other tool to negate the local effects of the OS, server configuration, or the developer’s cat sitting on the keyboard.
How to make the situation worse:
“So make the production server just like your local machine. Problem solved.”
I’m not good with Linux
“It’s really not my area of expertise. I think we need to hire a DevOps engineer to deploy our software.”
This excuse is made when:
It’s time to do a bit of work in the terminal or install 3rd-party software.
What it actually means:
The developer is comfortable with code but lacks understanding of underlying processes. Likely, they are afraid of doing something wrong.
How to react to it:
Explain that this is part of the job. Code is meaningless if you can’t turn it into a functioning application. Like with design, there are plenty of free resources online to help with edification.
Unlike design, there is a finite list of things you need to learn here. More than 90% of terminal work is done with 10% of the available commands.
How to make the situation worse:
“Look, I need this up on production in 40 minutes, figure it out.”
I’m an introvert
“I’m really not good with people, can I just stick to writing code?”
This excuse is made when:
The developer needs to give a presentation or mentor a junior colleague.
What it actually means:
Comfort zone, we meet again. Most software developers are introverts, yours truly included. Our brains want us to avoid stress and take the easy path even if the outcome isn’t optimal.
How to react to it:
Explain that the job is the job and if you can contribute best by mentoring someone rather than writing code, then you mentor someone.
If we need to present a new release for investors, who better to do it than the lead developer, regardless of how sweaty his palms are?
How to make the situation worse:
“No worries, we’ll have someone from marketing present this cutting-edge software framework to investors and if someone asks questions we’ll just improvise. How hard could it be?”
I don’t want to start anything I can’t finish
“I’m sort of between tasks and I don’t want to pick up something I can’t finish today.”
This excuse is made when:
Usually on Fridays. The developer doesn’t have any ongoing tasks and he doesn’t want to start any new ones because he can’t finish before the weekend.
What it actually means:
Everybody loves weekends, especially overworked software developers. Getting jitters around noon on a Friday is common and understandable.
How to react to it:
Starting something that requires focus and then leaving it half-finished for two days is, indeed, not ideal.
On occasion, the best option is to just let your team enjoy a few hours of an early weekend. More often, you can find something productive for them to do, be it documentation, mentoring, refactoring, or testing.
How to make the situation worse:
“No worries, I’ve got your back. Start now and you can finish it at home this weekend. Don’t text me about it though, I’ll be camping with the family.”
English isn’t my first language
“Talking in my own language is so much easier.”
This excuse is made when:
Documentation, comments, or other project-related communications are written in any language other than English.
What it actually means:
The developer doesn’t care who can read his writing and how it will affect the rest of the team.
How to react to it:
Ask them to translate everything that isn’t in English, be it Trello comments, code comments, or API examples. Like it or not, English is the 
How I Evolved My English Skills as a Non-Native Speakerlanguage of this profession, and it is very likely that the next person who joins the project will speak English, but not the current developer’s native language.
How to make the situation worse:
“Don’t write comments at all if you’re gonna write them in Cyrillic Serbian.”
Conclusion
As a team leader, senior developer, or boss, you often have to practice patience and understanding. It is frustrating when smart, capable people do things that are detrimental to success.
In every situation, it is important to remember that nobody is perfect and that dealing with programmers requires tact.
We’re an eccentric bunch but we get the job done with proper leadership.
Don't miss the next blog post!
I publish a new blog post every Wednesday. Join the newsletter to get:
- One valuable email a week.
- Zero spam.
- Exclusive content not found in the blog.
- Reply directly to me with questions or feedback.
Use the form at the bottom of this pageon the right to join the newsletter.
