The Battleground of the Software Developer’s Ego

Code review is one of “those” parts of software engineering where if it’s done well it may verge on OK, and if it’s done poorly, it will be a disaster show.

I don’t think code reviews are easy. Getting them right isn’t easy, I know that.

Yet we should have processes that stop them from degenerating into a process where we bash our software engineers. The fact that we still have processes that verge on bullying is a red flag for the entire industry.

So, what’s going on and how can we stop it?

A Sick Culture

Somewhere along the way, software development has become a Hunger-games style battle to survive.

Interviews can be overlong and contain irrelevant trivia. Performance reviews become a battle to convince a superior that you can code. Code reviews become a battle to maintain your sanity.

It just all needs to stop.

Toxic Feedback

Constructive criticism is a fantastic gift for any software developer. You are given guidance about how to improve and support to help you do so. 

Sadly, many code reviews are taken as opportunities to display one developer’s technical superiority over others. It’s not “helping” the team to take someone’s work and describe how “it works but could be better” after countless hours spent working. Oftentimes the “suggested improvement” doesn’t work within the context of the PR. Well, thank you, Sherlock, but unless you’re offering a solution, what’s the point of that comment?

This type of feedback does more harm than good, especially when it’s habitual. It’s one thing to offer a suggestion or raise a valid concern, but when the feedback becomes personal, condescending, or incorrect it erodes team cohesion. After all, the review is supposed to be about the code, not a referendum on someone’s worth as a developer.

The Ideal Code Review

A team should agree what a code review is actually about. I’ll tell you what it should actually be about, it should be about the codebase. That doesn’t mean your ego, so-called senior developer.

Other functions that the senior developer should perform include fostering learning, encouraging best practices, and creating an environment where mistakes are opportunities for growth. Note that developing shame in coworkers is absent from that list, with good reason.

So instead of trying to prove how much smarter you are than your colleagues, how about actually explaining why something might be wrong or could be improved? Or better yet, suggest changes that align with team standards and help maintain consistency across the codebase. If it’s not breaking anything, and it works fine, maybe just… approve the damn thing and get the code into production.

Avoiding the Nightmare

Developers need to stop treating code reviews like intellectual gladiator matches. We should be striving to make each other better, not dragging each other down. And for the love of all things open-source, can we finally agree that while clean code is important, nitpicking someone’s indentation style isn’t going to make or break the next release?

It’s time we reframe code reviews for what they should be, which is a tool for collaboration and improvement. 

Please stop the thinly disguised developer bashing. It’s unnecessary and not helpful.

Conclusion

The secret to better code reviews is simple. Less ego, more empathy. Actually, make your code review comments useful.

If you’re the one receiving feedback avoid taking it personally. Remember, we’re all in this mess together.