Death to Code Reviews 💀

Happy Friday!

I have been making an effort to reconnect with folks this summer. If you know me, you probably also realize I rarely check in with you or anyone else. It's one of my flaws. Believe me, it isn't that the fondness or relationship has died off, but the act of reaching out just doesn't occur to me.

Just yesterday, I was talking with someone who told me they were introducing WIP limits, as I had shown them 10 years ago. The reason was they were seeing a pattern that plays out that I bet you've seen.

Work is sitting and waiting in code review.

Now, this is the big bottleneck folks have been talking about ever since LLMs and agentic coding practices spread. The instinct is to review harder. More eyes on all that generated code.

I'll resist the full soapbox, but here's the part that matters: AI is only amplifying the problems you already had. The problem of humans using AI to write bad code won't be solved by humans reading it. We were never good at catching bugs by eye, and ten times the volume doesn't make us better at it.

For a long time, I have maintained that code reviews should be abandoned. More specifically, they're a practice that you use as a crutch but stop using once you're strong enough without it.

Let me explain.

There are just a few desirable results from successful code reviews: bug catching, tech debt prevention, standardization, and teaching.

Bug Catching

This is arguably the most important result from code review and also one of the least likely. It turns out folks are terrible at finding bugs in code.

Remember how, in school, we were all terrible at editing our own essays for spelling and grammar errors? It didn't get easier when we suddenly started doing it in code.

Bug prevention is a better approach to this, which means we look at the activities developers perform before declaring their code done.

Tech Debt Prevention and Standardization

Okay, code goes into review, and someone looks at it. Nine times out of ten, they will leave notes and comments that are either obvious gaps in written standards or highly opinionated ideas about how the code should be styled and designed.

This leaves everyone stuck with a riddle of assessing whether the comments are valid and, if so, whether they should be fixed now.

Guess what happens most of the time? The code is shipped under pressure to deliver.

Standards are generally easy to instrument, which means they aren't very useful to code review. Tech debt, on the other hand, is subjective and may not warrant comment, debate, or a fix.

Teaching

The act of teaching through code review is almost accidental, since it isn't the goal, but sometimes folks learn or internalize how to code from the types of comments they receive.

This leads to an implicit homogenizing of coding practices in the industry. That doesn't mean those practices are good, just similar.

I find this fascinating, by the way. How a whole industry winds up coding almost identically without talking about it and with the same weaknesses.

Fix or Abandon

All of the weaknesses that come from implicit and informal code review practices can be fixed, but it takes time and reflection that many folks have no real skill at.

For example, when someone leaves a comment on code they don't like, it would be more actionable if there were an obvious way to tell which comments needed to be addressed and which didn't.

It would be better if folks reached consensus on what they were reviewing for and what they were not. This would help avoid the issue of gaming reviews by getting them to a preferred person.

But here's the thing to me. Identifying tech debt, teaching, standards, and bug prevention all are better handled at other times in other ways. Bug prevention happens during development, teaching can be constant as a part of working together and not as individuals, and standards are a tooling issue.

None of these need a formal gate to prevent work if you can move these issues to a new place.

I left off tech debt prevention for a reason, though. It deserves special attention. I think groups should meet periodically to look at chunks of code. It isn't a gate like a review, but an opportunity for groups to gather, look at how things are shaping up, and figure out what, if anything, would make it better. I used to call this "Sacrificing code to the code gods."

The other thing that is lost on so many groups is that every time you go into code, you make small, tiny, constant improvements. Chipping away at the entropy of code like this compounds quickly, and you'd be amazed at how infrequently you'll hear complaints about tech debt when this is a cultural norm.

Teams that make micro-refactorings, focus on bug prevention, and collaborate more don't need to gate code with reviews. They've found better ways to work.

Let me know what you think. Does the idea of abandoning reviews sound good or like inviting disaster?

Sincerely,

Ryan

PS: Do you know how effective your reviews actually are? Can you measure if they're worth it? If you'd like to figure that out or how to build your team's performance, reply back or call.