Your Code Sucks

In the early 1200s, Muhammad, Shah of Khwarezm (city of Samarkand, in modern Uzbekistan) was approached by ambassadors, seeking to establish new trade routes with a warlord from the east along the silk road. Insulted, the shah had the ambassadors beheaded. In 1220, this same warlord sacked the city of Samarkand, slaughtering everyone who fled to the keep and pressing tens of thousands of residents into his service. The warlord’s name was Genghis Khan and it was a bad idea. The sultan’s reaction was not appropriate to the situation at hand, and it caused Genghis Khan to declare war, a war that ended up killing the sultan and everyone around him. It’s not just the message that has to be delivered that gets you into trouble, it’s the way you deliver it. While your coworkers aren’t Genghis Khan, the same basic dynamic of human behavior still applies. You periodically will have to tell someone that there is something wrong with their code, and the way you do it can have a profound and remarkable impact on the way your team interacts from there on out. People are protective of their code, thinking of it as a reflection on their quality as a person, and you WILL get bad reactions when you criticize that code in the wrong way. And those reactions may linger for years, slowly eroding team morale and cohesion, and probably causing even worse code to be written. However, you also can’t let bad code linger (if it is truly bad), because that also degrades the quality of the codebase and can lead to problems for the entire team, not just the person who wrote the bad code. Bad code also tends accrete more bad code over time, as people often end up writing bad code to mitigate the problems caused by bad code. When it finally comes time to rip out the bad code completely, it is often buried so deeply in the system that it can’t be removed without extreme effort. This dynamic, applied several times in a single codebase, will eventually mean that the codebase has to be rewritten entirely – and if you didn’t address bad code last time, it will happen again in the new codebase. It’s not hard to find things to criticize about other people’s code (or your own code from 6 months ago). However, it’s much more difficult to present a working solution and get everyone on board without upsetting anyone. Even if no one gets upset, you still want to make sure that any resolution of a coding problem leaves the codebase in a better state than you found it. Done properly, every time you find bad code, your team has an opportunity for growth. Done poorly, every time you find bad code is an opportunity for conflict. If you want to have a long and productive career, you need to master the art of telling people their code sucks in a way that helps fix it. Episode Breakdown Avoid your initial reaction Whether you are correct or not, your initial react has a fair chance of being wrong, overly emotional, or to be based on insufficient data. Even if you make a great and perfectly accurate snap decision, the speed of the decision will be taken as evidence that it is a bad decision. Even if you are correct, you still need to spend some time thinking of valid reasons someone would write bad code, simply to be in a good headspace to correct a team member. Remember that if you had all the information to determine instantly whether a piece of code is bad in a given context, it’s because you wrote it. Version control history is your friend. Make sure that the person you are blaming is the one that actually wrote it, rather than just the last to touch it. Determine why the code was written that way Most bad code isn’t written that way just because the developer is lazy, uninformed, or actively malicious. Something else is usually in the mix.