I have been doing code reviews for a long time. First as the person being reviewed, then as the reviewer, and now, at Benevity, as a senior developer who reviews a lot of pull requests every week. After all these years I learned one simple thing. A code review is not a place to show how smart you are. It is a place to protect the company money.
Let me explain what I mean.
The real cost of a bad review
Every pull request that sits open is work that is not delivering value. The code is done, but the customer cannot use it. The developer cannot fully move on. The branch gets old and merge conflicts start to grow. Time passes and time is the most expensive thing a software team has.
Now imagine a review where the reviewer writes things like “this is wrong” with no explanation. Or asks for a rewrite because the style is not the style he would use. Or starts a long debate about a variable name while the feature waits. I saw all of this in my career. I also did some of this when I was younger, and I am not proud of it.
Years ago, before I moved to Canada, I watched two senior developers fight over a pull request for almost three weeks. The topic was the design of a small internal service. Both designs would work. Both were fine. But each one wanted to win. The feature was for a real client with a real deadline. We delivered late, the client was angry, and the relationship with that client never fully recovered. Three weeks of salary for two seniors, plus the trust we lost. That PR battle was one of the most expensive meetings my company ever paid for, and nobody put it in any budget.
That is the thing about ego in code review. It does not show up in any report. It shows up as slow delivery, as rework, and as good people updating their resumes.
Even Linus had to change
If you want a famous example, look at the Linux kernel. For many years Linus Torvalds was known for very harsh reviews. He is maybe the most respected programmer alive, and the kernel is one of the most successful projects in history. Still, in 2018 he stopped, apologized for years of aggressive behavior, and took time off to work on how he communicates. The kernel community adopted a code of conduct after that.
Think about this for a second. If the Linux kernel, with all its success, decided that harsh reviews were hurting the project, what excuse do the rest of us have? If being rude was a good engineering practice, Linus would not have changed. He changed because talented people were walking away, and losing talented people is expensive for any project, open source or not.
What a good review looks like
A good review is mostly boring, and boring is good. The reviewer reads the code with one question in mind. Does this change put the product or the team at risk? Bugs, security problems, things that will be hard to maintain, missing tests for important paths. These are worth a comment. Everything else is a suggestion, and a suggestion should sound like a suggestion.
Some habits that helped me a lot:
- Say why, not only what. “This query can be slow with many records because there is no index on this column” teaches something. “Bad query” teaches nothing.
- Separate “must fix” from “nice to have”. I write “not blocking” on comments that are only my preference.
- Approve with small comments instead of blocking for small things. Trust the author to fix the details.
- If the discussion takes more than three messages, stop typing and talk. Fifteen minutes of conversation is cheaper than three days of comments.
Martin Fowler wrote in Is High Quality Software Worth the Cost? that the health of a codebase is an economic question, not a beauty contest. I think the same applies to reviews. The goal is not perfect code. The goal is code that is good enough to keep delivery fast and risk low, reviewed in a way that keeps people wanting to work with you.
Respect is a speed tool
Here is something I tell younger developers. When you review with respect, people send you their code earlier. They show you the messy draft and ask for direction before they spend a week going the wrong way. That is where review saves the most money, before the code is even finished.
When you review with ego, people do the opposite. They hide. They make huge pull requests because they fear the comments, so they want to face the pain only once. Huge pull requests get worse reviews, which causes more bugs, which causes more late nights. The circle feeds itself.
I came from a country where being loud sometimes looks like being strong. It took me years to learn that in a code review the strongest move is a calm question. “What do you think about doing it this way?” wins more than “this is wrong” every single time.
So no, code review is not about ego. It is about money, time, and keeping good people on the team. Review the code, respect the person, and ship.
Pax et bonum.