The “No A**holes” rule for software developers
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.
In his excellent book The No Asshole Rule, Robert Sutton identifies two tests to determine whether someone is an asshole:
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.
