Craft of code
Review tone
Questions and labeled nits beat commands. Explain why. Specific praise teaches what to repeat.
Tone decides whether review builds people or burns them. The same correctness catch can teach or humiliate. Prefer questions, labeled intent, and a reason the next reader can reuse.
Conventional Comments (praise:, suggestion:, issue:, nit:, question:) make intent scannable. Use them when your team likes structure; clarity matters more than the exact vocabulary.
Walking through phrasing
| Avoid | Prefer |
|---|---|
| "Fix this." | "What do you think about extracting X so Y stays readable?" |
| "This is wrong." | "I think this races if two webhooks arrive — does UNIQUE(event_id) cover it?" |
| Unlabeled drive-by style | Prefix non-blocking comments: nit: |
Explain why. "Rename to delayMs" is weaker than "Include units in the name so callers do not pass seconds." Praise specifically when something is genuinely good — deep modules, great tests, clear migrations. Specific praise teaches what to repeat.
How you reply to comments is part of the craft:
- Push back with evidence ("benchmark shows allocations are flat") not ego.
- For valid nits you will not fix now: "Follow-up ticket T-123" or fix in a 10-line follow PR immediately.
- Avoid force-of-will merges while a blocking thread is open — renegotiate the blocking bit instead.
- Say thanks for sharp catches; reinforce the reviews you want more of.
Review is a relationship across many PRs. People spend more care on authors who engage in good faith. Mentoring often is code review — see mentorship.
In interviews, behavioral questions often probe conflict on a PR. Good answers show you argued from user or operational risk, compromised on taste, and documented the outcome. Bring a story where you changed your mind when the author showed evidence.
Common mistakes
- Commands with no why. "Fix this" teaches nothing and trains people to wait for orders.
- Unlabeled nits that feel blocking. Prefix
nit:so the author can merge. - Ego replies. Evidence, or take it offline — see disagreement.
Check yourself
- Rewrite "This is wrong" for a possible webhook race.
"I think this races if two webhooks arrive — does UNIQUE(event_id) cover it?"
- When may an author merge without addressing a comment?
When the comment is labeled nit: and the review is LGTM — nits are optional.
Key takeaways
- Questions and labeled nits beat commands.
- Explain why; praise specifically.
- Reply with evidence; keep blocking threads honest.
Further learning
Conventional CommentsComments that are easy to grok and grepConventional Comments
Next: turnaround.
Related
Code review
Author small, reviewable PRs and give reviews that improve both the code and the author — design first, tone that teaches, turnaround that unblocks.
What to look at in a review
Design, then correctness, then tests, then readability, then nits. LGTM means you would own the merge.
Collaboration and disagreement
Build trust before you need it, disagree with data and options, and make cross-team asks easy to grant.