Receiving a Review Without Taking It Personally
Eleven comments on your first PR feels like an attack. It's the opposite — silence is how teams treat code they've given up on.
The vocabulary
- nit: — minor, take it or leave it. Not a demand.
- Blocking / changes requested — a status, not a mood. Fix, reply, re-request.
- "Why not X?" — usually a real question, not a rhetorical one. Answer it as one.
What to do with each comment
Agree → fix it and reply "done". Disagree → say why once, with a reason about the code: "kept the conditional wait because the modal renders async on slow builds". Unclear → ask. The one wrong move is silence.
When pushing back is right
When you know something the reviewer doesn't — you tested the alternative, there's a constraint they can't see. Push back on the code's behalf, never your own. "I tried getByRole here; it's ambiguous because there are two buttons" ends the thread in one message.
Grounded in how code review runs on real teams
All lessons in Working Like an Engineer: Git, PRs & Code Review
- The Loop: Branch, Commit, PR, Merge
- Your First Merge Conflict
- Reading Code You Didn't Write
- Receiving a Review Without Taking It Personally
- Giving a Review as the Quality Person
- Commits and PRs an Interviewer Will Read