Any developer, with any level of experience, can have bad habits. This is the junior developer neglecting the ripple effect of his changes. It could just as easily be the senior engineer rampaging through the codebase with her rewrites.
Bad habits are just habits; they do not define a person or their abilities. When your colleague’s code falls below your expectations, it’s unfair to point fingers and blame them for your company’s growing mountain of tech debt. With large-scale software development, success and failure are never attributable to individuals; success and failure are attributable to teams.
Bad habits can be replaced with good habits. Here are my top 10 bad habits for software developers. Watch out for these—we’ve all been guilty.
Bad Habit #1
You don’t test things.
Solution: Start testing things.
Bad 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 codeowners and get other engineers to sign off on your changes.
Bad 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’re trying to do tomorrow. If you’re shoving a square peg into a round hole, take a moment and rethink your strategy.
Bad 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.
Bad 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 that only you are using.
Solution: When in doubt, copy existing patterns as long as they’re reasonable. If they aren’t, what can you do about it? There’s a reason why it’s implemented that way.
Bad Habit #6
Too many things can only be tested in production.
Solution: Aside from emergency incidents, there are very, very few situations where you should be messing around in production.
Bad 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 building and how to debug it.
Bad 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 have any side-effects, which is wonderful. Maybe your changes are one deploy away from a large-scale incident, not so wonderful.
Bad 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, and simplicity.
Bad Habit #10
You don’t properly monitor and verify your changes in production.
Solution: Don’t hit the Merge Button and run 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!