Excuses programmers and what they really mean

Stressful work undoubtedly teaches us to come up with good excuses

Software development is very difficult. When the stakes are high, programmers are faced with serious pressure. Work requires them to be accountable to management and colleagues.

Often this leads to the fact that people use excuses that can sometimes be true, but can also be found ridiculous – maybe because of inexperience and ingenuity, or maybe because of the competitive and stressful environment in which developers are located.

No matter what programming language you write and in which stack you specialize, sooner or later you will most likely hear the following excuses, which may have a completely different meaning.

I have not touched this code for several weeks now.

Yes, and I also made a few changes, and now it does not work.

This is a strange problem. She probably won’t happen again.

And not a day has passed since I said this.

This works, but has not been tested.

Of course, this does not work. Expect a bunch of bugs, which I will call “hardware problems.”

I forgot to commit the patch code.

I have not yet implemented this feature. Soon you will be able to see the WIP commit.

It works on my car.

Hell, the production code is linking to my localhost. And I did not run specific test cases of the target environment.

The code is self-documenting.

I’m too lazy to write comments. Watch out, you can see spaghetti.

This is not a bug, this is a feature.

You guys have been ignoring this issue all this time. So now this is a feature.

This is just a temporary solution.

The crutch that I wrote is terrible. And he will remain forever. Until it breaks again.

This is not a problem with the code. It is necessary to train our users.

I scored on the UX.

We need to rewrite this code.

There are a lot of legacy. And we do not understand how it works.

This is a problem with your cache.

I have no idea what a no-cache policy is.

You probably have the wrong version.

I have not configured continuous integration yet. Now I’ll quickly add hotfixes to all versions.

These are network issues.

It’s definitely not the network. I need time to fix this problem.

The project is still building.

He was building … a few minutes ago. Leave me alone, I need a smoke break.

This code violates Uncle Bob’s principles …

This is not my code. So let me tell you about a few clean code principles that I have never followed.

Conclusion

After all, not a single product is error-proof, and programmers are people, not machines. Mistakes can be made by any person, regardless of their experience. In order not to make excuses ahead of time, you can take a step back, analyze your code, find out where the problem may occur, and then specifically present all the facts.
That’s all. Thanks for reading.