Reading the room in code review

Good code review is half engineering, half emotional intelligence. The reviewer who catches the bug AND leaves the author feeling respected is a different operator than one who just catches the bug. Most teams underestimate the second half.

What the social half looks like

• Distinguish between blockers, nits, and personal preference. Label them.
• Praise specific good choices, not just the diff overall.
• Phrase suggestions as questions when the author might have a reason you don't see.
• Pick up the phone (or DM) when comment count exceeds the value of comments.

Why it matters

Authors who feel reviewed harshly become authors who post smaller PRs less often. Reviewers who feel ignored stop reviewing carefully. Both directions degrade the code quality over a year more than any single reviewer's diligence improves it.

The diff is half the work. The room is the other half.