# Code Review Etiquette

Nobody teaches you this part. School teaches you to write code; it doesn't teach you what to say when a
teammate's pull request has a bug, or how to not feel sick when a senior engineer leaves twelve comments on
your first PR. Code review is where a lot of new developers get their first real taste of workplace friction
- and most of them figure out the etiquette the hard way, by getting it wrong once.

Writing the code is the straightforward part. The hard part is that every comment you write lands on a person, and every
comment you receive feels like it's about you even when it isn't. This guide covers both sides: how to leave
feedback that gets read instead of resented, and how to receive feedback without your stomach dropping every
time a review comes back with changes requested.

## The phases

1. **[Reviewing Someone Else's Code Without Being a Jerk](01-reviewing-without-being-a-jerk.md)** - why text
   reads harsher than you meant it, phrasing feedback as questions instead of commands, and how to tell a
   style nitpick from a real bug from an architecture concern.
2. **[Receiving Feedback Without Getting Defensive](02-receiving-feedback-without-defensiveness.md)** - the
   code is not you, healthy pushback versus defensiveness, and what to do when you think the reviewer is
   wrong.
3. **[The Etiquette Nobody Tells You](03-the-etiquette-nobody-tells-you.md)** - reasonable response times,
   approving with comments versus blocking, and what LGTM culture gets wrong.

Read them in order if you're new to this. If you just got a rough review and need to steady yourself before
responding, start with Phase 2.