A practical checklist for code review

The advice here is unglamorous, which is probably why it gets skipped. Run through this the next time code review comes up.

Code gets read far more often than it gets written, and usually by someone with less context than the author had. Anything you cannot measure here, you are deciding by taste, which is fine as long as everyone knows it.

The checklist

• Review catches problems tests were never written for
• Small pull requests get real review, large ones get approved
• Comment on the code, never on the person
• Someone is named as the owner
• There is a date to review it again

What is actually at stake

Review catches problems tests were never written for. That sounds obvious written down. It is still the thing most often skipped. It is worth deciding this deliberately rather than inheriting whatever the last person set up.

What this looks like day to day

The question is rarely whether something can be built, but what it costs to keep running afterwards. Three things worth confirming about code review before you move on:

• Someone can say what the current setup is without going to look
• Small pull requests get real review, large ones get approved — and you know whether that is true here
• There is a way to tell whether the last change to this helped

Worth checking on your own setup before it becomes someone else's problem to fix.