Code review: what to get right first

Every audit we run turns up some version of this. If you only fix one thing about code review this quarter, make it the first item below.

Code gets read far more often than it gets written, and usually by someone with less context than the author had. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.

Start here

Review catches problems tests were never written for. Getting it slightly wrong is survivable. Ignoring it entirely is not. The version that survives contact with a real deadline is the simple one.

Then this

Small pull requests get real review, large ones get approved. There is a version of this that is over-engineered, and it is worth avoiding. Budget a little time for it every quarter and it never becomes a project of its own.

Eventually

Comment on the code, never on the person. The teams that handle this well are rarely the ones with the biggest budgets. Budget a little time for it every quarter and it never becomes a project of its own.

What this looks like day to day

Most development decisions are really maintenance decisions wearing a different hat. Three things worth confirming about code review before you move on:

• Someone can say what the current setup is without going to look
• Review catches problems tests were never written for — 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.