Code review that actually helps
Code review can be one of the best things a team does, or one of the most demoralising. The difference lies entirely in how it is approached. Done well, it spreads knowledge, catches real problems early, and gently raises the quality of everything a team produces. Done badly, it becomes a gauntlet of nitpicks and bruised egos that people learn to dread. Here is how we try to keep ours on the right side of that line.
Review for the things that matter
The most common way review goes wrong is by fixating on trivia. Reviewers leave a dozen comments about spacing and variable names while the actual logic sails through unexamined. We solve the trivial layer with automation: formatting and style are enforced by tools, not people, so that no human ever has to argue about where a bracket goes. That frees the review to focus on the things only a person can judge — is this correct, is it clear, will it hold up, does it solve the real problem?
If a machine can catch it, let the machine catch it. Human attention is too valuable to spend on whitespace.
Ask, don't decree
Tone matters enormously. There is a world of difference between "this is wrong, change it" and "what happens here if the list is empty?" The first shuts down conversation; the second invites it. We try to frame review comments as questions and observations rather than commands, partly because it is kinder and partly because the reviewer is not always right. Sometimes the question has a perfectly good answer, and the discussion teaches the reviewer something. The goal is a conversation between colleagues, not a verdict handed down.
Be clear about what is optional
Not every comment carries the same weight. A genuine bug is not the same as a mild preference, and conflating the two is unfair to the author. We make the distinction explicit: if something is just a suggestion the author is free to ignore, we say so. That way the author knows which comments they must address and which are simply food for thought, and they do not waste energy agonising over a passing remark.
Keep changes small
The single biggest factor in review quality is the size of the change being reviewed. A small, focused change gets a careful, thoughtful review. A sprawling one gets a tired skim and a rubber stamp, because no reviewer can hold a thousand lines of change in their head at once. We keep our changes small and self-contained, which makes them easier to review, easier to reason about, and easier to roll back if something turns out to be wrong. A series of small, well-understood steps beats one enormous leap every time.
Review is how knowledge spreads
One of the most valuable things about review has nothing to do with catching bugs. It is how knowledge moves around a team. When you review someone's work, you learn about a part of the system you might not otherwise touch, and you pick up techniques from how they solved a problem. Over time this quietly erodes the silos where one person is the only one who understands a given area — which is exactly the kind of single point of failure we work hard to avoid. A team that reviews each other's work is a team where no one is irreplaceable and no corner is a mystery.
Praise what is good
Review does not have to be purely about finding fault. When someone solves a problem elegantly or handles a tricky case thoughtfully, saying so is worth the few seconds it takes. It makes the process feel less like an interrogation, and it teaches by example as effectively as criticism does. A reviewer who only ever points out problems trains people to fear review; one who also notices good work makes it something people are glad to take part in.
The point is the team, not the gate
It helps to remember what review is actually for. It is not a gate whose job is to keep bad code out, though it does that too. It is a practice whose real purpose is to make the whole team better — more knowledgeable, more aligned, and more capable than any one member alone. Approached in that spirit, with automation handling the trivia and people handling the judgement, code review stops being a chore to endure and becomes one of the quiet engines of a healthy team.
Written by the Arcwell engineering team. If you're wrestling with something similar, we're happy to compare notes.