Trash Code. A Candid Take on Keeping the Personal Out-of-Code Reviews
Photo by Hannah Busing on Unsplash
In this latest rant, I delve deeper into a particularly contentious pull request incident at work — a continuation of my ongoing critique on the poor level of code reviews in the software development community.
So many developers feel personally attacked during a code review that it needs to be dissected and stoped. Let’s take a look at this.
The Essence of Ad Hominem in Code Reviews
You’ve likely heard the term ‘ad hominem’, a Latin phrase that translates to ‘against the person.’ In the literary world, this denotes attacking your opponent’s character rather than their arguments.
It keeps happening. Time and time again.
A Typical Day in Code Review Hell
As usual, I find myself at the receiving end of what feels like personal jabs.
It’s not exactly an attack, although I was made to feel that way during a coding discussion.
We were talking about a specific coding problem. I told my colleague that I thought there was a problem with his code. He decided to pass whole objects to subclasses rather than just the couple of properties he needed.
His reasoning? He said that he might need them in the future. This coming from a developer who is more senior than me in the organization.
Now that is one thing. Another is how he finished the conversation. He wouldn’t make the changes and said that he was sorry. Like he’d won the argument. In practice, he just wanted to make sure he’d won the argument, even though it was because he could get away with it.
His justification? “I might need them later.”
This comes from a senior developer who outranks me. The conversation ended with him refusing to make adjustments, apologizing as if he’d won some sort of debate. In reality, he was just flexing his seniority muscles to win an argument by default.
Rethinking Our Approach to Code Reviews
In a previous post on the dire consequences of poor code review practices, I didn’t fully expand on how we ought to conduct these reviews. Here’s the lowdown:
It’s all about the mindset. We need to remember that the issue lies with the code, not the coder. I often remind my colleagues, “It’s just code.” Yet, many still view their work as a battleground of wins and losses. That’s not the spirit we need. We’re here to collaboratively solve problems and share insights, not to tally scores.
Decoding The Secret Developer’s Musings
Here’s what we should be doing:
Collaborate to resolve issues
Share knowledge and solutions
Treat code as separate from the coder
Foster teamwork
Avoid viewing code discussions as battles to be won or lost
Conclusion
We should be championing good code and not chastising developers personally for not meeting perfection. If only we weren’t navigating an office culture swamped with the less savory type of jerks. Now, wouldn’t that be nice?