Code review: reviewing and being reviewed like a senior Intermediate

The problem

The two most common kinds of broken review teams:

• The “LGTM” team: an 1,800-line PR is approved after 4 minutes. A double-charge bug reaches production because nobody read as far as the retry function in the 23rd file.
• The “gatekeeper” team: a 40-line PR waits 3 days, gets 27 comments about semicolons, then is asked to be “rewritten my way”.

Both cost money. This cluster is a set of rules for reviewing quickly, with focus, and without making people hate each other, for both PR authors and reviewers.

Reading order

Loading diagram…

In this cluster

Part	Answers
Review priorities	What is review for? What to look at first? How does a PR go from draft to merge?
PR author	How big should a PR be? What goes in the description? What does self-review catch?
Reviewer	How fast to respond? In what order to read a PR? When to approve with comments?
Writing comments	How to label severity? How do bad and good comments differ? How to handle disagreement?
Anti-patterns, metrics	What does broken review look like? What to measure without breaking review? Which exceptions are reasonable?
Common mistakes	Which comments, PR descriptions and code bugs often slip through, and which comment should catch them?

Decision summary

Question	Default	Reason
Standard for approval	The PR definitely improves the code, even if not perfect	Google: there is no perfect code, only better code
What to look at first	Design, correctness → security, data → tests → readability → style	Design flaws found late are the most expensive
Style, formatting	Prettier, ESLint, CI handle it; humans don’t comment	Machines check faster than people
PR size	One purpose; ~100 lines is reasonable, ~1,000 lines is usually too big	Reference numbers from Google’s Small CLs
Response time	At most one business day	Most complaints about review disappear when review gets faster
Optional comments	Label nit: / suggestion (non-blocking):	The author knows what must be fixed
Prolonged disagreement	Call after 2 comment rounds (this cluster’s convention), record the conclusion in the PR	Long threads don’t converge

Summary

Key takeaways

• Approve when the PR definitely improves the code; don’t wait for perfection.
• Order: correctness and design → security, data → tests → readability → style; hand style to machines.
• The author determines most of the review’s quality: small PRs, separate refactors, a description with why/tests/risks/rollback, self-review first.
• Reviewers respond within one business day, read the design first, and label the severity of every comment.
• Disagreement: data and conventions first, a call after two rounds, record the conclusion in the PR, escalation is the last step.
• Measure the process (latency, size, rounds), not people.

Next: Review priorities.