5 Bad Habits Of Software Developers

There is no hard and fast rule as to how a programmer should program. So, there is nothing wrong if you have your own style of programming.

There is no fixed set of habits for a programmer, but I would like to mention some of the behaviors that hamper the progress of a programmer.

And here are the top 5 habits which developers should avoid to climb the ladder faster:

Agreed upon larger-scale code structure (architecture) and agreed smaller-scale code style is a must thing. Sometimes programmers start with a project without defining these, and, as a result, when the project goes wide and large, it becomes difficult to manage it.

Moreover, the code structure and style helps in certain conditions when more than one programmer is working on the project—it is easy to handle the code management.

We all use code off the internet, no doubt.

In fact, not reusing code is not the smartest idea. But every time you use some code, do you blindly paste it and check if it worked? Well, if yes, you are missing an opportunity to learn.

The reason you looked for the code is that you either did not know how to do it or you wanted to save time. Attempt to understand the snippet that you used at least at a high level. You do not have to follow the code line by line but at least understand the approach used.

The next level is to reproduce the same solution from scratch. Maybe even make it simpler. This way, you'll get the most out of this.

Most programmers are night owls.

That usually dates back to the fact that most programmers would always program late at night, cause less focused (or more proactive) programmers are on during the day (more time to debug and compile without saturated servers), and no meetings.

Why nights? Because nights give the chance to be alone, and just straight-up program. That's why usually programmers are most productive during the late-night hours.

Feeling productive though doesn't mean we actually are. What if all this work will have to be thrown away and reworked? Because of the new information tomorrow morning when talking with your colleagues?

Also, developers still have to go to work in the morning. And staying late at night, in this scenario, will accumulate tiredness and stress. Without (stable over time) good night sleep, mental and physiological issues will start to pile up, which could create negative self-reinforcing cycles of burnout, depression, sicknesses, etc.

The solution here is to get a good night of sleep regularly, be refreshed, and learn how to be productive and focused during the day.

Thinking that documentation is a burden and should be pushed on the back burner when possible and rushed when it's not.

This causes technical debt and is the main hindrance to onboarding a new developer onto the team.

If people put more effort toward documentation, then better processes would be created to handle this.

This would begin to increase the ability to cross-train devs quickly and efficiently.

Putting aside the debate about the pros and cons of TDD, having some tests is pretty much a must.

Some prefer to write them first, others write the tests afterward. Either way is better than having no tests at all.

Having a good test coverage encourages developers to make changes more confidently, and with fewer bugs, and fix structural problems in the code more often. Which, in turn, improves team speed and allows for more value to be delivered to the end-user.

As of now, just pay attention to these behaviors and try to correct your habits, once it becomes a pattern in you, you will automatically know what works best for you.

If you want to learn more about how to succeed in dev careers without stress, find useful tips in my weekly newsletter, along with your FREE Professional Networking Cheat Sheet.

Thank you for reading! 🙏

If you have any thoughts on this post, feel free to reach out to me on Twitter, and leave comments below.