16 Nov Bad habits of an average programmer

In 2020, the coronavirus pandemic significantly changed the work schedule of many developers. Many had to learn to work from home. Such unexpected changes are a good reason to reassess your approach to work. This is our chance to eliminate bad habits that hinder development and prevent us from reaching our full potential.

These bad habits have a significant impact on work, even under normal conditions. Now, when many teams are forced to work remotely, unproductive approaches can aggravate the situation.

At the same time, getting out of the old rut is a good opportunity to introduce beneficial changes in your life and improve your skills.

Let’s take a look at some of the worst habits that can reduce a programmer’s productivity and think about how to get rid of them.

Mindlessly copying code

The Internet offers fantastic opportunities to learn and grow, especially if you are into web development. But when you cannot seek advice from colleagues, using the Internet can sometimes limit your potential as a programmer.

For example, everyone has at least once happened to use a code found somewhere on the Internet. But blindly copying someone else’s code into your project is a wasted opportunity for growth.

Take some time to discover the code you find. Understand how it solves your problem, study its basic structure.

Lack of style or structure in the code

Programmers who are overly addicted to copying someone else’s code fall into another trap: their code becomes logically incoherent, it loses structure. You can improve the readability of your code by using comments for each passage and dividing the tasks performed by the code into smaller ones.

When your code is not written according to any predetermined plan, it looks amateurish. Worse, it makes it difficult for your teammates to work with your code in one way or another.

Technical expert Dando Rilan says: “It is important to implement a specific architecture and start adhering to a specific style in the earliest stages of work on projects. This way, your projects will be clearer and easier to maintain. Also, the architecture and style, defined in advance, help anyone looking into your code quickly find what they need and understand the course of your thoughts. Develop your own coding style: this will make your programs more understandable, and in addition, your style will become your “handwriting.” 

Defending your position and views

In general, having a position and defending it is not bad if it does not harm your working relationship. And in a non-standard situation, in which many of us find ourselves because of quarantine measures, you should be especially careful.

There is a stereotype that all programmers are unsociable creatures who have difficulty communicating. Unfortunately, this stereotype did not arise from scratch: relations between developers are often bad.

One of the main reasons for bad relationships with colleagues can be know-it-all behavior. When you demonstrate your unshakable self-righteousness, you come across as an arrogant person, repelling others. Also, programmers can get in trouble if they get defensive every time someone criticizes their code.

Working all night long

Even if you didn’t have to work all night to complete a project or meet a deadline, you probably stayed late at least once in the office. Staying at work is especially easy when you work from home, and the boundaries between work and normal home life are too blurred.

But while developers often work at night, it hurts more than helps.

“Consider whether your work is productive at night,” advises tech writer Rami Salik. It doesn’t matter how many lines of code you manage to write in a night if you have to redo everything the next morning. After all, we are all human, and we need rest to maintain our mental and physical health. If you deny yourself time to rest, it will definitely reduce your productivity in the long run. Even if, due to circumstances, you are not physically at work and you do not need to travel to the office, try to stick to your everyday work schedule and “leave work” at your usual time.

Ignoring documentation

Documentation is another aspect of good teamwork. But developers often do not pay enough attention to it, considering it to be something unimportant. You know what you have done and what you are doing, so why write about it?

But documentation is essential: it facilitates communication between team members. And in a remote work environment, when you can’t just walk up to a colleague’s desk and ask something, documentation becomes especially important.

The lack or poor quality of documentation often upsets the developers themselves. For example, it makes it longer and more challenging to get familiar with the codebase of new team members.

Writing documentation can seem like a tedious chore, but you still have to write it in the end. And, as with any routine, it is much better to do it often, but little by little. 

Perfectionism

It is quite difficult to fight perfectionism. Of course, we do not advise anyone to try to work worse deliberately. But in some situations, an excessive desire to do everything perfectly only slows down progress.

When you’re experimenting, fixing urgent bugs, rushing to meet deadlines, writing just working code is all it takes, and the time spent perfecting is wasted.

If you work from home, perfectionism can drive you to overwork: you can spend hours trying to do something “right” (especially if you’re not busy with anything more urgent).

All we can advise is to learn to discern where your skills should be applied and not necessary. Of course, there are situations when the code should be in perfect order, and you should fully optimize its elements. But there are other cases where optimization will only make it difficult to maintain this code further.

Try not to forget about the project’s main goals, and when writing code, focus not on performance in the short term but on the alignment of the code with the main goals.