What It Actually Means
Mechanically it usually happens through a pull request: the change is proposed, someone else reads it, comments, and approves or asks for adjustments. Nothing reaches the live system until that has happened.
Why It Matters To You Commercially
The obvious benefit is defects caught early, and early is dramatically cheaper. A problem found in review costs minutes. The same problem found by a customer costs the fix, the investigation, the deployment, the apology, and whatever it did before anyone noticed.
The less obvious benefit is the one worth paying for. Review is how knowledge spreads across a team. Every change is seen by at least two people, so no part of your system ends up understood by exactly one person.
That is a business risk rather than a technical one. A system only one developer understands is a system whose cost and timeline that developer effectively sets, and whose continuity depends on them staying. Review dissolves that quietly and continuously, and it is the strongest argument for insisting on it even when a team feels it slows them down.
What Good Review Looks Like
Small changes. A review of forty lines is careful. A review of four thousand is a rubber stamp with a comment about naming. If everything arrives in enormous batches, review is not happening in any real sense.
Timely. Changes waiting days for review stall work and create pressure to skip it. Same day is a reasonable expectation.
Substantive. Comments about whether the approach is right, what happens in edge cases, whether anything else breaks. Purely stylistic comments suggest a formality rather than a check, and most style questions should be automated away entirely.
Applied to everyone. Including the senior person, including urgent fixes. Exceptions become the norm, and urgent changes are precisely the ones most likely to be wrong.
What To Ask
You cannot assess the quality of review yourself, and you can ask about the process, which tells you most of what you need.
- Is every change reviewed before it goes live? The answer should be yes without qualification.
- Can anyone push straight to production? Ideally nobody, including whoever is most senior.
- How long do reviews take to happen? Days indicates a bottleneck that will eventually be bypassed.
- Is any part of our system understood by only one person? An honest team will name it.
For A Solo Developer
If one person is building your system, formal review is impossible, and the risk it addresses is at its highest.
The substitutes are worth asking for: automated tests that check behaviour without a human, automated style and security checks, written documentation of decisions, and occasionally paying a second developer to review the work independently.
That last one costs little relative to a build and is genuinely worth doing at least once, particularly before a system starts holding money or personal data. It is much cheaper as a scheduled review than as an emergency.
More terms are in the glossary.
