People think they lack motivation, what they really lack is clarity

– James Clear, Atomic Habits

Code review innocently asks a staggering question: “does this code look good to you?” It’s not even clear how to start to answer this question – which makes putting off code reviews easy.

With so many decisions left for the reviewer, the easiest decision is to opt out – to defer code review for a time when I have more mental energy.

This post explores the problem of decision fatigue in code review. Then it looks at individual and institutional strategies for fighting fatigue.

Code review is a request for my willpower

The chaotic evil response to an unreasonable review request

Code review is a big task for even a tiny change. But if your patch is enormous and tricky, then you’re asking for a titanic share of my willpower.

When a review demands too much of my daily willpower reserve, I have a few options:

  • Lawful Good: Carve out time when I know I’ll be able to power through the review.
  • Neutral: Defer reviewing your code — and devoutly wish that it somehow disappears.
  • Chaotic Evil: YOLO it into production and let you deal with the fallout.

None of these options is fair to both the developer and the reviewer.

Where to even begin code review

Often even the basic questions of code review are up to a reviewer to decide.

A thread on hacker news recently asked a fundamental question about code review: do you run the code as part of your review? The immediate responses were illuminating to me, and I can summarize them as follows:

  1. No, but here’s how I trick developers into running their own code
  2. Yes, because neglecting to run code has left me traumatized
  3. Rarely, because tests
  4. It depends, and you need a standard

Google’s code review guidelines are blasé on the subject:

You can validate the CL [code under review] if you want

– What to look for in a code review,

Google’s engineering practices documentation goes on to mention times you’ll definitely want to ensure you’ve run the code: UI changes and parallelism — places where it’s easy (even likely) for an individual to make a noticeable (in retrospect) mistake. But what about all the other code reviews?

Requesting changes to the code review process

We should optimize the code review process to reduce the decision fatigue of reviewers.

Here are a few tricks developers can use to lessen the mental load:

  • Split your merge request into smaller, independent merge requests
  • Add some tests and linting to exercise the code
  • Write clearer commit messages
  • Add comments to the code
  • Ask them for a narrower review — e.g., a design review or an architecture review
  • Write better code

Some tools exist that ease the burden of remembering your review backlog – Automattic has The Stick, and Microsoft has Nudge. And studies have shown code review reminder tools like these may speed up reviews by as much as 60%.

But there are no magic bullets. Code review’s harshest feedback is silence. There are times when you gape as your code rots, awaiting final judgement. And that sucks for everyone.

To speed up the process, we’ve got to make it easier for reviewers – we should start with a shared agreement about the scope of review. Perhaps beginning with the fundamental question of whether they’re even supposed to run the code. The answer here is probably different for different teams and various types of software, but we all do reviews; maybe we should all have review standards, too.

Thanks to Brennen Bearnes for reading an early draft of this post and making it less wronger.