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 - 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 - 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 - 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.