Code review is where engineering culture becomes visible. Done well, it's the fastest teaching mechanism in software — every pull request transfers judgment between teammates. Done badly, it's where defensiveness festers and careers quietly stall. The technical part of reviewing gets taught; the etiquette rarely does, and it's half the value. Here's how professionals run it on both sides.
Writing the PR: your first act of courtesy#
Review quality is bounded by what you submit:
- Small diffs win. Reviews of 200-line changes catch real issues; reviews of 2,000-line changes say "LGTM" from exhaustion. If work is big, split it into stacked PRs that each stand alone.
- Describe intent, not just contents. The reviewer knows what changed from the diff; tell them why — the problem being solved, the approach chosen, alternatives rejected. Link the ticket.
- Self-review before requesting. Read your own diff as an enemy would: leftover debug prints, commented-out code, naming you already regret, tests missing where behavior changed. Catching these yourself is respect for reviewers' time — and self-review genuinely finds things.
- Flag the feedback you want: "I'm unsure about the error-handling approach in file X — push back if there's a cleaner pattern." Directing attention to your doubts converts review from gatekeeping into collaboration.
- Never force-push mid-review without announcing it; reviewers' inline comments get orphaned and their work erased.
Giving feedback: critique the code, protect the person#
Every comment passes through a human who can't hear tone in text. The mechanics of criticism that lands well:
- Ask questions before asserting preferences. "What happens here when the list is empty?" invites explanation; "This is wrong" invites defense. Often the question reveals the author had a reason — or reveals the flaw to themselves, which teaches better than being told.
- Label severity explicitly. Prefix conventions keep this honest:
nit:for taste-level points,suggestion:for optional improvements,blocker:for genuine must-fixes. Unlabeled comments force authors to guess which criticisms are load-bearing. - Anchor to principles, not taste. "This duplicates logic we maintain elsewhere — could it reuse X?" beats "I'd do it differently." The former cites a shared standard; the latter cites you.
- Praise is also review content. Noting a clever solution isn't fluff — it tells teammates what excellence looks like here, and makes the critical comments credible as evenly weighted.
- Keep scope disciplined: comment on the change at hand, not the author's entire history ("you always…"). And never let style debates live in humans when they can die in tooling — formatters and linters exist precisely so nobody spends opinion capital on semicolons.
The test for any comment: would you write it identically if the author were standing behind you? If it needs softening for that audience, soften it; if it's true regardless, send it plainly.
Receiving feedback: the professional stance#
Your code is not you — internalizing that sentence is worth more than any framework skill:
- Respond to substance, ignore imaginary slights. Text strips warmth; assume competence and good faith from reviewers until proven otherwise, exactly as they should assume of you.
- Don't defend — investigate, then either fix or explain. "Good catch, fixed" and "I tried that but hit Y — thoughts?" are both complete answers. Silent resistance to every note teaches teams to stop reviewing you carefully.
- Push back with evidence when you're right. A respectful "I kept this because of X constraint — happy to change if that constraint doesn't apply" is senior behavior, not insubordination. Reviews are dialogs; capitulation isn't cooperation.
- Thank precision. A reviewer who caught a real bug saved you a production incident at 2 a.m. Saying so builds the relationship that makes future feedback generous.
- Extract patterns from recurring notes. Three comments about the same category of mistake across PRs isn't three nitpicks — it's one gap wearing costumes. Close gaps deliberately; that's how review accelerates growth (the roadmap phase where it matters most).
The team-level truth#
Teams that review well share two norms: everyone reviews, everyone gets reviewed (seniors included — nothing signals culture faster), and discussion that exceeds three comment-rounds moves to voice, with conclusions written back into the PR or a standards doc so the debate pays rent. Review exists to ship better code through better shared judgment — when it stops doing that, whatever form it has taken, it's failed regardless of who won the argument.
Related: portfolio presentation shows these same communication values externally, and reading unfamiliar code makes you the reviewer who understands context before commenting.
