Five mistakes teams make with code review

It is rarely the thing that gets a project approved, and often the thing that decides how it goes. These are the ones we run into repeatedly when we audit code review.

The question is rarely whether something can be built, but what it costs to keep running afterwards. Assume whoever inherits this will have half your context and none of your patience.

Where it usually goes wrong

• Treating it as a launch task rather than an ongoing one
• Assuming someone else already owns it
• Review catches problems tests were never written for
• Small pull requests get real review, large ones get approved
• Never checking whether the fix actually worked

Comment on the code, never on the person. None of that requires a large budget, only a decision and someone to own it. Check it against what you would want a competitor's site to get wrong.

Turning this into a decision

How to tell if yours is fine

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.