"Yes! That was my mistake, let me fix it!" These are the words you probably never said to someone if they came to you with a problem in your code. And if you did, my props to you.
And there might be a reason for that. We spent a great amount of effort on coding a given solution. We try if it works properly, we even validated all edge cases we can think of.
Everything seems to be in order…Until someone else tries it!
When someone else starts testing our changes, they always have some problems. And for us, mighty creators, this doesn't make any sense. After all, we're rock solid programmers and we don't do mistakes.
So we start to do, what anyone else would do. We start to make excuses.
After reading this article, you'll know what are the most common excuses that lazy programmers use. But most importantly, you'll have the option to pick one for yourself.
Next time, when you feel like the time is right, feel free to use it!
With that being said, let's jump right into the list.
What would be the better way to start this list, than by picking this good old evergreen? If these words didn't come out of your mouth yet, you have no right to call yourself a developer.
This excuse will buy you a couple of minutes. Best case, maybe even hours of free time. And if that's still not enough, you can just let others use your machine. After all, it works there!
Wrong data, wrong input, or old data that someone forgot to delete. These are the things that can haunt us forever. And of course, they require our immediate attention.
However, attention is something we don't like to offer. And for that reason, we make excuses. "It has to fail, you were using corrupt data. It's a good thing we received a failure." These words will be your best friend.
I don't like to play a blame game. But what I hate even more is fixing other people's mistakes. And I believe I'm not the same.
For the people that sympathize with me, we have this jack of all trades. If someone asks as to fix something. We can just simply say we didn't work on it.
To justify it, even more, how about saying that author of the error knows better what to do, and how to fix it?
Time is precious, and wasting it by writing unit tests, is the equivalent of asking for a recipe in a restaurant. You get your food, you just eat it. And if it doesn't taste good, complain!
The exact thing goes for writing code.
Let's just stay with the topic of unit tests for a while. Let's assume you have to write them, and there is no way you can wiggle your way out. What do we do in this case? Do we just give up and write unit tests?
Oh please, we're better than that. The most effective excuse to use is to say that we don't know how to write good unit tests. Of course, by saying that, we decreasing our value as a developer. But we're increasing our time we don't have to do anything.
So if you want to avoid writing unit tests, just acknowledge you're not good at writing them. After all, we're developers, not quality assurance.
If we want to play a blame game, there's a good candidate who can take all the blame. And it won't even say a word. The reason for that is because it can't talk.
If you want to blame that something is not working properly, blame a browser. Browser cache can cause a lot of problems and confusion. So why don't just use it to our advantage?
And who knows? Maybe your accusation will be correct.
If you're using Agile methodologies, all your tasks should be defined properly. It can be a lot of pain defining and estimating them. But once you've done it, a new possibility opens up for you. A new excuse if you will.
Now, you can use the evergreen amongst Agile development. You just say it wasn't specified in the requirements. If it's not in the task description, why would you do it?
The more you do, the more is the likelihood that something breaks up. So sit tight, read the description, and do exactly what it says.
This excuse is plain in simple, and on top of that, it lacks certain professionalism. But it doesn't mean we should avoid it. However, I only recommend using it in specific scenarios.
Are you presenting your work and something accidentally breaks up? Are you showing your changes and they suddenly stop working? This is the ideal occasion.
By saying that it worked a couple of some things ago, you can assure the other party that you did a good job. But something unexpected happened and caused the problem.
I see these words coming up a lot. And I even heard them in the workplaces I used to work. But I wouldn't use them.
This excuse is not backed by anything. You're not assuring anyone that what is broken will work. And you're not even showing signs of you caring. It's just a straight-up arrogant response. Use at your own risk!
For websites, this can be caused by browser cache. But not all developers are creating websites. Which means we can't play the browser cache card.
However, we can still blame the old version. This can happen for many reasons. After all, we're humans. We make mistakes, and we forget. And it doesn't hurt to ask someone to double-check if they're using the correct version.
If none of the previously mentioned excuses fit in. There is one hail mary we can always use. Sometimes, it may be hard to sell it to others, but it doesn't hurt to try.
As Michael Scott would say…
Credits: The Office
"It's not a bug, it's a feature" is the last excuse that made the list. What's left is to say a couple of final words.
Programming is hard, and developers are often overwhelmed by work. For that reason, we developed a list of excuses that can be used in order to avoid work. Or maybe just gain a couple of minutes for rest. To sum eveyrthing up.
Here is the list of excuses that programmers use:
- It Works on My Machine
- You Must Be Using Wrong Data
- I Didn't Work on That
- I Didn't Have Time to Write Unit Tests
- I Don't Know How to Write Good Unit Tests
- Your Browser Must Be Caching the Old Content
- That Wasn't Specified in the Requirements
- It Worked a Couple of Minutes Ago
- There's Nothing Wrong With My Code
- You're Not Using the Latest Version
- It's Not a Bug, It's a Feature