10 Bad Software Developer Habits

Any developer, with any level of experience, has the potential to be what I call “dangerous.” This is the accidentally negligent junior who can’t grok the ripple effect of his or her changes. It could just as easily be the senior engineer rampaging through the codebase with re-writes.

Before diving further into this topic, a manager’s perspective must be given. It’s unfair to assign blame directly 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 should 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 actually, no one’s fault. At a company, success and failure are never attributable to any one individual; success and failure are attributable to teams. It’s important to remember this.

Anyway, let’s go over these bad habits. Here are my top 10 bad software developer habits. We’ve all been guilty of these.

Dangerous Habit #1

You don’t test things.

Solution: Start testing things.


Dangerous Habit #2

You re-write 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 re-written. If so, communicate your “refactor” with code-owners and get at least one person to OK your changes.


Dangerous Habit #3

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

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, deprecating features because you feel like it, 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: Do not deploy and take off to an Internet-free 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 *