Code review, explained without the jargon

Every audit we run turns up some version of this. Here is code review without the vocabulary that usually surrounds it.

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.

The short version

Review catches problems tests were never written for. Small and consistent beats large and occasional here. Budget a little time for it every quarter and it never becomes a project of its own.

Why people complicate it

Most of the confusion comes from tooling rather than from the idea itself. That sounds obvious written down. It is still the thing most often skipped.

Small pull requests get real review, large ones get approved. Where this goes wrong is almost never a lack of knowledge. It rarely shows up as a line item, which is exactly why it slips.

A reasonable first step

Comment on the code, never on the person. Small and consistent beats large and occasional here. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.

How to tell if yours is fine

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

Pick the one that would hurt most if it failed, and start there.