As software developers, we routinely must maintain code that we did not build in the first place. Maybe the original developers left the company, or maybe they were consultants whose contracts ended. Our tendency is to blame these developers for whatever we dislike about their code to deflect criticism, apologize for defects, and gain permission to embark on projects to refactor or rebuild to suit our own preferences.
But developers who do this are assholes.
In his excellent book The No Asshole Rule, Robert Sutton identifies two tests to determine whether someone is an asshole:
- Do other people feel sad, less worthy, or demotivated after talking with the alleged asshole?
- Does the alleged asshole mistreat those who are less powerful?
It seems like we should get a pass on rule #1, because you’re not going to directly confront the departed developer with your complaints. But what about your coworkers? Does it make them sad to hear their former colleague bashed? If they’re friendly with the original developer and they relay the complaint, will the developer feel less worthy? If so, you’re being an asshole.
Rule #2 is easy, though. The developer in question is gone and, therefore, entirely less powerful than you are. In fact, it’s impossible to constructively criticize the work of someone who cannot respond because, in doing so, you decontextualize the code from the environment in which it was created. At most, we can evaluate the code against the current organizational needs, which we know about, but the old developer did not insist though we might that should have known — the mere passage of time represents a context shift, as the triangulation of priorities between fast, cheap, and good can definitely change over time even if nothing else does.
Here are some asshole scenarios:
- A team built a working prototype for a big project under the assumption that they would be allowed to rebuild it “properly” once its value was clear. Market fit was quickly proven, and the team was forced into a feature-building death march. They quit, and you were hired. You weren’t told that the code was a prototype, so you trash the original team, much to the satisfaction of the product team. You’re an asshole.
- A consultant built a website for a client with a hard launch date tied to the ending of a joint marketing contract. Halfway through the project, the client’s technical managers and designers all quit. The consultant and the client agreed to cut down the QA period in order to cope with the increased workload and hit the launch date, and the client hired a new team to take on maintenance. The new team arrived, the consultant departed, and the new team blamed every little inconvenience on the consultant, who was merely responding to the more urgent business demand — launch the site on time. The new team are assholes.
- An unskilled developer was brought on staff to develop a CMS. He did, but the resulting site crashed a lot and was very difficult to use. When he left, the business decided they needed expert advice to solve the obvious problems, so they hired a consulting firm, who audited the source code and found that the developer had hard-coded his personal email username and password to access a Google service. The consultants gleefully tattled on him, and they are assholes.
Even in this third case, where the original developer did something objectively irresponsible, it is asshole behavior to shame them for it. They were hired to do a job that was beyond their abilities, and the responsibility for that mistake is not theirs alone. Good consultants would help their client adjust their expectations.
Some tips to avoid asshole developer behavior:
- Keep things technical. When you encounter an issue, even if it seems to have been caused by direct developer malfeasance, report the problem and the solution in technical terms, not personal terms.
- If you fundamentally disagree with code architecture, ask others who were there about the requirements the original developer had and try to contextualize their experience. Maybe your issue tracker has the original tickets that were assigned when the project started.
- Think about the things you left behind when you left your previous job. How do you want your successor to talk about your work?
- Help your replacement by commenting your code with information about why you built things as you did, not just how.
- When you hear others engaging in asshole developer behavior, answer it with curiosity but don’t commiserate.
It’s no coincidence that these qualities also make for good engineering leaders. Good leaders aren’t assholes.
And if all else fails — remember, if the code were perfect, you wouldn’t have a job. Don’t be an asshole about it.