The work of a programmer is inextricably linked with the need to make many decisions. Sometimes we understand that the decision is no good, but still we make it.
There can be a variety of reasons: sports interest, laziness, etc. One thing is clear: you should not follow the steps listed in the article, although something may really seem like a good option.
1. Hasty decisions
Sometimes you know that your decision is not the best. Nevertheless, it is implemented, because it will be faster, and the code is functioning. At the same time, you have more time to debug everything else. It’s okay, right?
It’s nice when you can solve the problem in a short time. But getting the code to work is just a small part of the task. Haste becomes the cause of serious errors that lead to an increase in technical debt.
When making the next decision in a whip-up series for discussion, you should be aware that it can negatively affect the atmosphere in the team.
In your defense, it is worth saying that sometimes haste has no negative consequences. And in some cases, it even turns out to be the most correct way out (for example, if such a code is needed for a short period of time).
But if you need a code for the long term, haste in resolving problems will certainly respond later with some troubles. You should not justify such decisions by promises to bring everything in order later. We all know very well how such stories end.
2. The habit of swallowing errors in code
Many times I saw how inexperienced developers make a mistake by covertly handling errors in the code. Among the possible reasons are a lack of understanding of what is happening in the code at a lower level. However, sophisticated developers also tend to hush up mistakes. And, unlike the former, they do it intentionally.
When the work is full and the deadlines start to burn, you do not have time for all the problems that are poured into the bug tracker. Sometimes, in order not to startle from new notifications, you decide to silently “swallow” an error. This allows you to concentrate on other tasks already in the work.
One can imagine several precedents in which it would be preferable to hide the error notification (for example, for some reason it was not possible to create a log file, but there is nowhere to report it). Nevertheless, experience has shown that this is best not done.
Most developers at least once engaged in the introduction of some design patterns that were not particularly necessary. However, just because you can add a template doesn’t mean you need it.
This is a classic form of overengineering, and all that you will achieve with it is the complication of the technical side of the code base. This most often happens when developers lack difficult and motivating tasks, then they begin to create them for themselves.
Another reason for over-engineering is the belief that some piece of code is useful in the future. This fragment is added to the code base, but in reality it is unlikely to be useful later. Probably the best way to explain over-engineering is this: it is code that solves non-existent problems.
4. Attempts to invent a bicycle
Developers like to reinvent the wheel from time to time, collecting something from scratch. The reason is that this is a great way. understandhow some things work. Creating anew, you go all the way, which gives deeper knowledge.
Inventing a bicycle can be quite fun, but it takes time, which developers most often do not have. Deadlines must be respected, so such things are not encouraged.
Sometimes time expenses are justified, sometimes there is no need for them. And other tasks are so important that if you mess up something, it will lead to terrifying consequences. That’s why the decision to invent a bike is not the best thing you could do.
5. Uninformative comments on commits
Many developers write uninformative comments on commits, even knowing that in the long run they themselves will suffer from this. Any developer will understand why you may not be wasting time on a good comment. You have finished the feature that you have been trying to debug for so long, and you want to finally commit the final changes. And the sooner the better.
However, it’s extremely important to spend time and write quality comments on commits, with useful information about what changed and why. When everything flips head over heels, it is possible to quickly detect an error using the change history.
If you want to learn more about the importance of writing quality comments on commits, take a look at one of my articles.
You will encounter it quite often. Developers, as a rule, procrastinate when they are at a standstill or the project “does not enter.” At some point, you may find yourself procrastinating because you do not see the forest behind the trees. The amount of work that needs to be done is so crushing that you end up doing nothing.
It’s better not to procrastinate for too long, it’s a waste of time. Divide the work into smaller fragments. If that doesn’t work, try taking a short break to refresh your brain.
Action defeats inaction (Og Mandino)
There are things that programmers do, although they know that this has negative consequences. If we talk about writing code, this includes hasty decisions, hidden error handling, the creation of uninformative comments on commits, and over-engineering. In addition, trying to invent a bicycle – it takes too much time. The same applies to procrastination.
I hope you have become more aware of the above-mentioned not-so-successful actions, so you can try to avoid them (even if something still seems successful).
Thanks for reading!