I Probably Hate Your Code Review Process

One thing that people quickly realize about me is that I hate lots of things. Partly that’s because I tend to be very critical, partly because I am a little too candid for my own good, partly because here in Middle America the scale starts at “it’s okay…” when people talk about the worst thing in the world. Usually this isn’t a huge deal. I warn people, they understand. A few weeks go by and they realize they didn’t really understand, but eventually we settle on some good compromise where we each understand what we mean.

But even within that shared understanding, there are ranges. If I say I hate brain freeze, or cancer everyone nods and says “yeah, they’re the worst!”. If I say I hate leafy vegetables or Tom Hanks movies (except for Apollo 13), people kind of give me the side-eye but go along with it.

The worst is when I say I hate code reviews.

Pretty much everyone in earshot reflexively reaches for the nearest pitchfork. Then they look at each other to wordlessly agree who will be the one to engage. Then comes the usual argument:

“Come on Matt, code reviews are super useful! They catch bugs. They make sure people are writing good, legible code. They help make better code since the reviewer can offer suggestions. They help spread knowledge, both of the codebase and various tips-and-tricks that each individual knows. They can help make sure people write tests and documentation. They make sure nobody is putting backdoors in the code… How can you possibly hate that?”

That is all true.
And I hate it.

Photo by Jon Tyson on Unsplash

The reason I hate your code review process isn’t because of the value it provides, but because of the cost it incurs.

Take the “it catches bugs” argument for example. It’s commonly accepted that the earlier you find a bug, the cheaper it is to fix. Code reviews necessarily occur after the code has already been written. Any bug found is found after the programmer has done a bunch of work to implement the thing. Other techniques like pre-coding design discussions or (*shudder*) pair programming do a better job at identifying the sort of bugs caught in code review earlier in the process.