5 Bad Programming Habits - Don’t Do This
5 Bad Programming Habits - Don’t Do This

This are 5 bad programming habits that you should never do if you want to be a professional developer.

Code from other people is bad

Most programmers like their own code and don't like code from other people. It happens for 2 reasons. First of all we all understand the code that we wrong better, it's something that we created on our own. This is normal to like what you create. But code from other people is often not clear for us, it takes time to understand it, even if it's good code we want to write it differently.

And actually it's a big problem. In other professions you don't go and change what other people did just because you don't like it for example while building a house but for some reason it is totally fine to change or rewrite the code of other people.

Here are some important thoughts from 10 years of experience:
- You don't need to like code of other people but either you don't need to change it without reason
- The reason to change the code is: it's not working, it's not fast enough and it will be a bottle neck, it's so unreadable that it's not possible to support. And it's better to change the code before it was merged to the main development branch
- You also need to be good at reading and understanding code of any complexity and it should not matter how bad the code is

We need to refactor everything

Which brings us to the next point. We don't need to refactor everything. It's a bad habits to come to new company see the code and say "This code is bad we must rewrite the whole application". Most programmers like to rewrite everything because they think that their code will be simpler, easier to support and better. Here is a truth: "Business doesn't need your refactoring. Project should work, don't be super buggy and new features should be implemented in the reasonable time". There should always be reasonsing about refactoring. Project is slow or it's impossible to build new features without breaking what is build are the main realistic reasons to refactor something. The reasons like "Code is bad", "This framework is better", "I can't understand the code" are not a valid reasons to refactor anything.

And realistically your code won't be better. It will also have bugs. It will take long time to make project stable again.

We will do better later. I need to code fast

One more bad habit is to take shortcuts. Really often when I think "Let's do it like this because if I do it correctly it will cost 2 more days" it takes longer to get to the point that you see that this code is not supportable or scalable and that you need to build it correctly from the start. After some years of experience you get a feeling when you do something write or wrong, if it's correct and scalable or it's just a hack. Realistically I would hack something only if I have release tomorrow and it should be done today. But if I'm in such situation that means that everything is already wrong if you need to fix your project with hacking 1 evening before release.

Thinking only about happy path

Developers are always optimistic. We build things and assume that they will always work. That API will be stable, that we never get 500, that the data will always we in correct format and that users won't click on button several times. It's the wrong attitude. You must build bulletproof code. You always need to think about things that can go wrong, about edge cases and try to cover them. It eliminates bugs, makes debugging and development faster and simpler. It's not about if you should do it or not. It's a bad habit to cover only a happy path of your code.

Copy code without understanding or change lines to fix something

A lot of programmers like to change order of lines or variables in order to fix something. I never got why they are doing it. You need to understand on 100% code with which you are working. Every single line and variable. Sure if you are a beginner it is difficult but need to get it as a habit. Changing the code that you don't understand is like making a surgery without knowing what you are doing. You go line by line from the beginning, you understand every single line and property, you use a debugger to check if everything is correct and it's a value that you expect.

Over engineer simple problems

And here is my bonus point which is a bit tricky. It's avoid over engineering or under engineering problems. Normally developers either write to simple code and copy paste it too much because it's not reusable or they try to make everything reusable, scalable and configurable. It's a difficult skill to learn but you totally need it. You need to find balance in building things that are scalable and reusable but not that you over engineer it completely so it's difficult to support and change.

Here are one advice how to do this. Try to make sharable only things that are really sharable and not just to avoid copy paste. ArticleForm component which is sharable between Creating article and Editing article is a good idea to share and just try to several lines that you duplicate out without isolating it is specific reusable function or component is a bad idea.

So this there 5 bad programming habits that you need to avoid.

Also if you want to improve your programming skill I have lots of full courses regarding different web technologies.