7 bad habits of inefficient programmers

There are different developers: brilliant, competent, capable… and terrible. What is the problem of bad programmers? Bad habits!

The difference between a good and a bad developer often lies not in the level of intelligence or knowledge of a programming language. Even an experienced specialist can be ineffective. You need to look for the cause even deeper – the habits.

Fighting bad habits – both in life and in work – is very difficult, but possible. And it is essential if you want to succeed. The problem is that we do not always understand which of our habits are bad. That is why one needs an outside perspective – here it is, use it.

My code is the BEST

Any team needs modest, hungry and bright people:

Do not criticize someone else’s code, because one day yours may become a subject of criticism. Try to reason objectively and professionally, but do not look down upon somebody else’s work. Be humble and try to learn from people around you in all aspects of life and work.

Remember that your ego prevents you from growing and developing. When you believe in your infallibility, you kill the creator in you. When you decide that you have nothing more to learn, you will stop developing.

Reluctance to test code

Programmers have always considered code testing as something unworthy of their attention – something that can be compared to washing dishes. But the world seems to have flipped upside down. Developers who still live in the past are not in high demand. Testing is not a bonus for a programmer, but a real must-have. Smart programmers are able to grasp the importance of testing.

I will fix it right away

If you see a shortcut, this does not mean that it will lead you to the right place. Shortcuts are appealing and we all sometimes walk along them, but very often they are dangerous.

A quick solution can save you several hours or even days, but then it might cost you months and years of problems. Having succeeded now, you risk losing a good reputation that can’t be earned quickly.

The shortest path is not always the best one, remember this.

Inability to establish a connection with people

Ineffective developers are not team players. This can be a real problem in today’s constantly evolving world, where teamwork comes first. It has long been not like the old days when one programmer could work alone and cope with the creation of software. Software projects are becoming more complex and one can’t do without the help of the entire team.

In any case, an inefficient programmer will equally depend on the whole team. Pride can contribute to the development of the ineffective programmer who simply cannot work in a team environment. Knowing when and how to do the right thing in a given situation is a fundamental key to success. Do not let pride interfere with your development.

Poor communication can also contribute to team inefficiencies. It noticeably worsens the existing problems, when such a developer needs to communicate not only with the members of the development team but with the people outside it.

I remember everything, don’t need documentation

Documentation for programmers is like castor oil. Managers believe that it is useful, and developers hate writing it. And yet one can’t do without it.

Make it an integral part of your work. Any team is an unstable formation. People are hired and fired, transferred to other departments, get ill and retire. And according to Murphy’s law, this always happens at the most inopportune moment.

Well, even you can forget how your code works and stop recognizing it within a couple of months.

The line between a successful product release and a failed deadline is very thin. Support your work with design documents, API specifications, guides and comments to the code.

Nobody likes “irreplaceable” programmers, whose code is impossible to figure out. Do not be one of them, write documentation.

It wasn’t me!

Perhaps this statement is the most important characteristic of an unprofessional developer.

One can always find an excuse for your failures (and we do it regularly). You can often hear it from bad programmers that the root of evil lies in customers who misuse the product. The responsibility for mistakes gets shifted, shifted and shifted… and as a result, no one is responsible for it.

Do not be afraid to say, “sorry guys, my bad, let’s try to fix it together.” This is the right and healthy approach of a good specialist. Everyone makes mistakes and everyone understands this. The sooner you admit your mistake, the faster it will be fixed, and the less likely you are to repeat it.

When “done” isn’t done at all

If programming was sex, there would be many unsatisfied computers in the world. You do something in a hurry, say “done”, and go to sleep peacefully.

Remember, “done” – means-tested, meets user requirements and is approved by them. The user, not you! What is “done” for programmers is far from being “done” for users.

Good developers seek to learn new things, rise to the architectural level and evaluate their creation with a bird’s-eye view of it. They learn to understand a concept in parts and as a whole. They always doubt and are critical of any decision – always looking for an ideal solution.

Bad developers are tightly attached to their favourite technology/framework/template. They have chosen the “ideal” method for themselves, but do not think about other people with different requests that will use the product. They select tools and dependencies for themselves, and not for the project.

One word

The essence of all of the above fits into one simple word – ATTITUDE. The right attitude is always more important than the experience of programmers. It’s not enough to just work – you need to form the right attitude to work: responsible, positive and “hungry”. Such an attitude will make you more effective and happier in life and at work. It is contagious – your team will appreciate it.