Being a Good Reviewee
Most code review advice is directed at reviewers. But the author has responsibilities too. A PR that is hard to review will get poor reviews — not because the reviewer is lazy, but because the cognitive load is too high.
Keep PRs Small
The single most impactful thing an author can do is keep their pull requests small. A PR with 50 lines of changes gets a thorough review. A PR with 800 lines gets a skim and a rubber stamp. This is not laziness on the reviewer's part — it is a cognitive reality. Humans cannot hold 800 lines of context in working memory simultaneously.
A useful heuristic: if your PR touches more than three files or takes more than 20 minutes to review, consider splitting it. Feature flags and trunk-based development patterns make this easier by allowing incomplete features to be merged safely behind a flag.
Write a Useful PR Description
The PR description is your cover letter. It should answer:
- What changed and why (not just "fixed bug" — explain the root cause)
- How to test it
- Any trade-offs or known limitations
- Links to the relevant ticket or spec
A reviewer who understands the context before reading a single line of code will give dramatically better feedback than one who has to reverse-engineer your intent from the diff.
Respond to Every Comment
Even if you disagree, acknowledge every comment. "Done," "Fixed in latest commit," or "I kept the original approach because X — let me know if you'd like to discuss" are all valid responses. Leaving comments unacknowledged is the fastest way to frustrate a reviewer and slow down your own merge.
Do Not Take Feedback Personally
This is easier said than done, especially early in a career. A useful reframe: the reviewer is not criticizing you — they are criticizing a snapshot of code that existed at a point in time. The code is not you. Separating your identity from your output is a professional skill that compounds over time.