10 Bad Habits For Software Developer

Any developer, with any level of experience, has the potential to be dangerous. This is the junior developer having trouble grokking the ripple effect of his or her changes. It could just as easily be the senior engineer rampaging through the codebase with rewrites.

Before diving into this topic, a manager’s perspective must be given. Bad habits are just habits; they do not define a person or their abilities. When your colleague exhibits bad habits, it’s easy to point fingers and use them as a scapegoat. However, this kind of thinking is unfair; with large-scale software development, blame should never be assigned to an individual.

In the rare case where an individual’s presence at an organization becomes a disservice to the business, then that person needs to go. Bad apples aside, we must always remember that responsibility is bubbled up through management. It’s not your fault if your broken code gets through to production. Incidents in production are your team’s fault, your boss’s fault, and ultimately, the company’s fault—so in effect, no one’s fault. At a company, success and failure are never attributable to any single individual; success and failure are attributable to teams. It’s important to remember this.

With that said, here are my top 10 bad habits for software developers.

Dangerous Habit #1

You don’t test things.

Solution: Start testing things.


Dangerous Habit #2

You rewrite a lot of code, without being prompted to, whenever you feel like it.

Solution: There should be a good reason why something needs to be rewritten. If so, communicate your refactor with code-owners and get at least one person to sign-off on your changes.


Dangerous Habit #3

You forcefully extend an existing paradigm to fit your new feature without thinking about how it could be reworked.

Solution: No one is a soothsayer. No one knows the future. What exists today does not take into account what you are trying to do for tomorrow. If you’re shoving a square peg into a round hole, take some time and think about your strategy.


Dangerous Habit #4

You write too much code.

Solution: If you’re writing too much code, it’s probably wrong. Break it up into smaller pieces and get it reviewed.


Dangerous Habit #5

You create bespoke implementations and deviate from the codebase’s norms. Red flags include forking repos, aggressively deprecating features, and introducing “shared” components without any buy-in.

Solution: When in doubt, copy existing patterns as long as they’re reasonable. If they aren’t, what can you do about it?


Dangerous Habit #6

Too many things can only be tested in production.

Solution: Aside from emergency incidents, there are very, very, very few situations where you should be messing around in production.


Dangerous Habit #7

You find yourself unable to debug a feature you developed. Red flags include excessive copy & paste, spotty domain knowledge, and an inability to explain why something is working.

Solution: Fully understand what you’re developing and how to debug it.


Dangerous Habit #8

You’re unsure how your changes affect the rest of the platform.

Solution: All changes have a ripple effect. If you’re unsure of how your changes affect the broader system, you need to develop slower. Take your time and take an inventory of side-effects. Ask someone if you’re unsure. Maybe your changes don’t affect anything, and that’s wonderful, but you’ve got to be sure.


Dangerous Habit #9

You write unreadable code. Red flags include single character variable names, long lines, long files, and your inability to understand what you did six months ago.

Solution: Code is communication. Isn’t it annoying when someone mumbles something to you? Optimize for readability, clarity, simplicity, etc.

Dangerous Habit #10

You don’t properly monitor and verify your changes in production.

Solution: Don’t hit the Merge Button and take off to a beach. Take responsibility for your code, make sure it safely makes it through the pipeline, and monitor it in production. Be a good citizen!

Leave a Reply

Your email address will not be published. Required fields are marked *