Breaking the Cycle of the Mean Developer

We’ve all done it before.

Imagine this: you inherit code from some unknown, unseen website developer and you scoff at it as you begin to pore over it. You repeatedly face-palm as each new line of code brings another cry of, “Why did they do it like this?” You may even share the code with your developer friends or co-workers and chuckle at its quality in comparison to your own or your team’s.

But, why do we do it? What’s the point of perpetuating the stereotype of the mean developer by ridiculing the code of another, regardless of whether or not they’re aware you’re doing so? Who does it benefit? Most importantly, how can we, as developers, stop being so critical, cynical, and rude and start being more mindful of our words and actions while working toward a better web?

For the sake of our argument, we’re going to refer to “bad code” as code that may be ugly to look at (poorly formatted), repetitive, not extensible, or that is lacking in performance. If code raises security concerns, then that’s another boat altogether and should be addressed with care, but still not with ridicule.

Recognizing the problem of the mean developer

This is the easy part. If you’re a developer, there’s about a 99.99% chance you’ve laughed or groaned at someone else’s code when you were asked to take it over. Inheriting headaches is never fun, and sometimes you truly do take over code that is poorly written or not future-proof. These headaches, though, aren’t helped by agonizing someone else’s code not being up to your standards. In fact, doing so will only make things worse.

When you take over a codebase from someone else, you should consider that not everybody is at the same level as you find yourself. You may have been developing websites for the past 15 years when you adopt the code from a developer who has only been at it for a couple of years. Is the code they’ve written really any less valid than what you would have written? Sure, it can probably be improved upon, but do we need to act as a gatekeeper with new developers?

Think back to when you first started. For me, it was working in Notepad and building sites from scratch with beautiful, beautiful tables. As I and the web developed, I was able to add new tools to my workbench. When I first learned about the ability to put all of your styles in a single stylesheet and remove the need for inline styles, my mind was blown.

Just because I got to that point at that very moment in my journey, though, doesn’t mean that someone who didn’t learn about it for another six months was any less a developer than I was. Perhaps they only built sites every so often and weren’t as entrenched in web development at the time. Nonetheless, they still did the work and got there at their own pace.

The next time you’re bequeathed code from another developer and want to laugh or complain about what they’ve written, think about your own journey first. Think about how you would have written the very same thing two, three, or five years ago, and then think about how you would write it today.

How to deal with bad code

Just stop.

Take a step back.

Breathe in deep and let it back out (that last part is very important, please don’t forget to breathe out).

Then dive into the code.

You may be taking code over for any number of reasons. Maybe you’re forking a repo to build off of something else, or you’re on a project working with multiple vendors and need to integrate code from another developer/company into whatever it is you’re building. Perhaps you’re joining a new company and are taking over for someone who has since moved on.

The main thing to keep in mind is that nobody is writing what you consider to be bad code on purpose (probably). Developers are writing to the best extent of their knowledge at the time and could be dealing with any number of extraneous circumstances not made clear in the code.

How many times have you done anything in your life “good enough for now” because you were under a time crunch? One time, I royally messed up a pizza dough and it wound up tasting way more like a pretzel than a pizza. Still, it had cheese, sauce, and other toppings. It was technically edible—good enough for jazz, right?

While you may not be able to fix a bad pizza, you can fix bad code. Plus, if you’re working with the person who wrote the bad code, then you’ve got a wonderful teaching opportunity. If not? Well, then you can rest peacefully knowing that you’ve taken something and improved it with your good big brain. What a treat!

Dealing with bad code can be as much a learning experience for yourself as it can be for the developer who originally wrote the code. You have the unique ability to peek inside of someone else’s mind and try to parse what they were thinking when they wrote something. Maybe it looks wrong to you, but does it actually work? If so, isn’t it sort of neat that someone was able to accomplish something their own way with a working end result?

What’s important to remember is that bad code does not mean a bad coder wrote it. We’re always learning, growing, and trying new things. If your code from years ago looks the same as it does now, you’ve got a problem. So much changes and evolves in just a year that, as a developer, if you’re not constantly trying new things, then you’re going to find yourself falling behind.

Yes, maybe your code technically still does what it needs to do… but will the person ahead of you who has been experimenting and learning beyond your knowledge level see your code as “technically good” or as something on which to improve?

How to stop being a mean developer

This might be the easiest thing to do with the biggest hurdle in front of it. It’s easy to be cynical and catty in your daily life, and those instincts are multiplied when you’re in a rush or have a lot on your plate. As much as it pains me to take off my own tinfoil hat from time to time, it’s important to remind yourself that everybody else isn’t out to get you.

You aren’t picking up someone’s bad code as a punishment or a cruel joke. You’re simply nudging forward the life cycle of developers, code, and the web.

When you adopt someone else’s code and the logic behind it puzzles you, stop and ask yourself why someone would write something in this way. More often than not, they just didn’t know of any other way. It could be way over-engineered or needlessly complex, but that doesn’t mean it’s actually wrong. If you can accomplish the same thing in fewer steps or with better performance, do it!

If you’re in the unique position of working with the person whose code you’re inheriting, ask that person why they wrote something a certain way. There may be more behind their code than simply not knowing any better. Maybe they, too, were jumping onto some other previously written code and needed to tailor their new code to the existing codebase.

If you’re unsure of any issues you may run into by beginning a code cleanup, reach out to your team or community. Assuming the code is safe to share with your group, try to get some insight into why something could have been written a certain way while also sharing your suggestions for cleaning it up. You may find that someone has an even better solution than your own allowing yourself to grow as a developer and someone else to grow as a teacher.

When it comes down to it, just take a moment to think about what you’re doing. It may feel good to laugh at something like a pile of bad code, but it’s not getting anybody closer to solving any of your problems. It’s a pointless exhibition of elitism and potential gatekeeper behavior.

The next time you want to deride another developer’s code or process because, “I wouldn’t have done it this way,” or “This doesn’t make any sense,” don’t. Instead, appreciate that you have the opportunity to see someone else’s process while also expanding your own mind to see that there is almost always way more than one way to accomplish something.

Above all else, though? Don’t be a jerk!