How to fix your broken code review process

It's 4:00 PM on a Friday. Your latest pull-request has 67 comments, half of them nitpicks. It's been open since the start of the week. Your teammate gave his LGTM and just opened his 15th pull request. Sound familiar?

Code reviews are, by far, the most important part of delivering software. They hand down tribal knowledge, reveal how a team thinks, and guard production. When they flow you barely notice; when they don't, the pain is immediate.

When reviews break down, the symptoms are obvious—and the internet loves to complain about them.

The internet is littered with complaints

Having a great code review process is a solved problem. I'd like to help you solve it too - but let's agree on a few things first:

Ground rules: this is a human problem (and leadership must care)

Humans will do many surprising things when writing code and doing code reviews. Including, and not limited to:

• Slapping an "LGTM" on a pull/merge request they scanned for 5 minutes.
• Opening a pull request without running their code.
• Slopping the solution with AI without reviewing the output.
• Going on various personal crusades to enforce a standard without team alignment.

As much as I want every decision people make to be logical and have some sort of underlying motivation—they usually don't. You'll need to switch off the purely logical part of your brain for this one.

Leadership also has to care. The push to improve code reviews can come from anyone, but without advocacy and air-cover from management, the initiative quickly stalls and burns out its champions.

The rule "if it ain't broke, don't fix it" applies here. Figure out what problem you have first.

How to fix your code reviews

Start by identifying the symptom that best describes how you feel about code reviews right now.

Symptom 1: Drive-by LGTMs

Why it happens: Your culture is not emphasizing the importance of code reviews, and as a result, engineers are not carving out time blocks for it.

They resort to approving all PRs without reviewing them, for the sake of unblocking their team.

Fix: Get engineers to carve out time. The best time block is usually after lunch. This time block also has to be protected.

Symptom 2: PR opened without self-review

Why it happens: Engineers feel like they have too much on their plate to deal with something as petty and unimportant like running their own code.

Fix: This is a bandwidth problem. Reduce expectations on what you want engineers to deliver.

Symptom 3: PRs sit unmerged for days

This one can happen for many reasons:

The code was too complicated to review. There's that meme where if it's a 10-20 line change, the code is reviewed within 5 mins. If it's 500 lines, it takes a day. Engineers should be forced to split up PRs unless it's absolutely not possible.

Engineers are not pushing for their code to be reviewed. The engineer who opened their pull request already moved on to another task. This should be a big no no in any team.

The pull request keeps getting rejected. If the rejections are happening to a new hire, this is a signal that the new hire needs to spend significantly more time pairing with a more experienced engineer.

The team doesn't have bandwidth for reviews. Get engineers to carve out time dedicated to code reviews.

Symptom 4: Deploys cause downtime

Downtime can be acceptable because it helps you learn where you are weak and where you can do better for your customers.

Consistent downtime from the same mistakes, however, is not acceptable. The fix is to get better at passing down tribal knowledge, via:

• More experienced people doing code reviews.
• Documentation, with the expectation that it is maintained.
• Pairing on a code review.
• Using an AI code review tool (like wispbit!) to align on a set of common rules that caused downtime in the past.

Symptom 5: Reviews devolve into nitpicks

If engineers are discussing nitpicks and code style during reviews, give yourself a pat on the back and tell your team how great they are.

This is a sign that great code is being pushed. Any bigger problems would have taken priority.

The fix for this is agreeing on a set of code conventions as a team, and sticking to them.

When these fixes don't work

These ones are not really straight forward to fix, and are usually a hard-to-swallow pill for leadership.

• Engineers don't care. They are mentally checked out. On autopilot mode. Have silent quit.
• People are tired. Burnt out. Too much work. Not enough rest. Not appreciated or rewarded for the work done so far.
• Engineers don't respect each other and don't work well with each other.

If you are here, code reviews are the least of your worries.

Wrapping up

Healthy code reviews are a great indicator of a healthy engineering culture. Pick one symptom, experiment with a fix, and see how your team reacts.

P.S. - wispbit helps solve these problems. Try it here.