Code review is a request for my willpower

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, https://google.github.io/eng-practices/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.