Code Review Culture: What a Review That Grows Your Team Looks Like

When I became a team lead in a small team, the first thing I understood was this: code review is not a gate for checking code — it is the cheapest teaching tool a team has. We have many juniors and few seniors — a typical situation for local teams. Every PR is a chance to teach a lesson on real code, in real context. Build review as a "guard" and juniors start fearing to write code. Build it as a "mentor" and they grow visibly within six or seven months. In this article I describe the practices I introduced in my team and that actually worked.

What Review Looks For — In Priority Order

Not all comments carry the same weight. I gave the team an explicit order, top to bottom:

1. Correctness and security. Does the code work, are edge cases covered, is there a SQL injection or a hardcoded token. If a problem is found at this level, we do not discuss the rest — this gets fixed first.
2. Architectural fit. Does this code fit the project's existing structure? If logic that belongs in the service layer is written in a controller, it works today but gets expensive six months later.
3. Readability. Can another person understand this code without context: naming, function size, complex conditions.
4. Style. Whitespace, braces, import order. Do not give this level to a human at all — hand it to the linter and formatter. While a person debates comma placement, no time is left for architecture.

The last point saves the most time: style debates are the biggest time sink in review. After we made Prettier and ESLint mandatory in CI, the number of comments went down, but the value of each one went up.

PR Size: Review Dies After 400 Lines

Nobody honestly reads an 800-line PR — they skim it and hit "LGTM". In my experience, 200–400 lines is the boundary up to which a reviewer's attention lasts to the end. Three things helped me establish a small-PR culture:

• The habit of splitting tasks. Plan a big feature not as one huge PR but as a chain of small sequential ones: first the model and migration, then the service, then the endpoint, finally the UI.
• Feature flags. Unfinished functionality can be merged behind a flag — and the excuse "I'll wait until everything is ready" disappears.
• A written rule. Our team agreed in writing: "if a PR exceeds 400 lines, we first discuss whether it can be split." When the rule is written down, reminding someone of it is not a personal rebuke — it is part of the process.

Comment Tone: A Question, Not a Verdict

Even a technically correct comment, written in the wrong tone, does damage: the author goes on the defensive and the discussion stops being about the code and starts being about ego. That is why our main rule is: a question, not a verdict. The same thought can be said in two ways. A real example from our reviews:

Bad: "This is wrong. It crashes on an empty array, rewrite it."

Good: "What happens here if items comes in as an empty array? I think reduce without an initial value throws — could you check?"

The second form does three things: it does not force the author to defend themselves, it nudges them to think it through, and if the reviewer happens to be wrong, no awkward situation arises — a question is not an accusation.

Two more agreements keep the tone in order:

• The nit: prefix. We put nit: in front of small, taste-level suggestions — the author is not obliged to act on them. For example: "nit: these two ifs could collapse into one early return".
• Separating mandatory from optional. A comment that blocks the merge is marked explicitly — a "blocking:" prefix or request changes. Everything else is a suggestion. The author should never have to guess which comments are mandatory.

Reviewing Juniors: Direct, Don't Fix It For Them

The most common mistake is rewriting a junior's code into the "correct version" yourself. They will copy-paste it and learn nothing. Give direction instead: "This function does three things. Which part do you think could be extracted?" The process of finding the answer themselves is exactly what learning is. Yes, it takes longer. But that time is an investment in teaching, not just a review cost.

And in the first PRs, say something positive too. A single sentence like "You wrote tests — great, most people forget that in their first PR" completely changes a junior's attitude toward review. Someone who only received a list of flaws will be afraid to open the next PR — and that is exactly the outcome we do not want.

The Author's Side: Review Starts With You

Review quality does not depend on the reviewer alone. Three habits for the author:

• The PR description. Answer three questions: what changed, why (a task link is not enough — write one sentence of context), and how it was tested. The reviewer should not spend time excavating context.
• Self-review. After opening a PR, be the first reviewer yourself: read the diff from start to finish. Thanks to this habit I fix half of the would-be comments before the reviewer ever sees them — a forgotten console.log, a half-named variable, a stray file.
• Not taking comments personally. Review targets the code, not you. Letting go of the feeling that "my code is me" is not easy, but it is necessary: the fastest-growing developers are the ones who treat a comment as a gift, not an attack.

Process: SLA, an On-Duty Reviewer, and the LGTM Disease

Culture is not just tone. Three organizational rules hold it up:

• A review SLA of 24 hours. After a PR is opened, the first response must arrive within a day. The longer the wait, the more the author forgets the context, the branch goes stale, merge conflicts pile up. Importantly, within 24 hours you owe a first response, not a full review — "saw it, will look tomorrow" also counts, because the author knows where things stand.
• An on-duty reviewer. In a small team, when everyone is busy, PRs hang in the air. A weekly rotation — one person who is first responsible for reviews that week — solved this problem for us.
• A ritual against the LGTM stamp. Approving without reading is a team disease. We introduced a small rule: before approving, you must write at least one question or one substantive comment. Can't find a question — then you have not read the diff. This two-minute ritual brought our reviews back to life.

Conclusion

Code review is one of the most expensive blocks of shared team time, and the return on that investment depends directly on culture. Hand style to the linter, keep PRs small, ask questions instead of passing verdicts, give juniors direction rather than ready answers, and as an author, respect the reviewer's time. None of this is technically hard — it is all a matter of habit. But the result is measurably real: the quality of your reviews is the speed at which your team grows.