A short guide to code review

Every audit we run turns up some version of this. Everything we would tell a client about code review in the time it takes to drink a coffee.

The question is rarely whether something can be built, but what it costs to keep running afterwards. The failure mode is not doing it wrong, it is doing it once and assuming it stays done.

The reason this keeps coming up

Review catches problems tests were never written for. Where this goes wrong is almost never a lack of knowledge. Anything you cannot measure here, you are deciding by taste, which is fine as long as everyone knows it.

How to approach it

Small pull requests get real review, large ones get approved. Where this goes wrong is almost never a lack of knowledge. Anything you cannot measure here, you are deciding by taste, which is fine as long as everyone knows it.

Common failure modes

Comment on the code, never on the person. In practice this is a scheduling problem more than a technical one. If it only works because one person remembers to do something, it does not work yet.

What this looks like day to day

Code gets read far more often than it gets written, and usually by someone with less context than the author had. Three things worth confirming about code review before you move on:

• Someone can say what the current setup is without going to look
• Comment on the code, never on the person — and you know whether that is true here
• There is a way to tell whether the last change to this helped

If you want a second opinion on how yours is set up, ask.