Code review is someone else reading your changes before they hit production. It catches bugs, shares context, and keeps style consistent. Done well, it feels like pairing async. Done badly, it feels like nitpicking or politics.
Authors: keep PRs small and focused. One feature or fix per PR when possible. Write a description that explains why, not just what — link the ticket, note trade-offs, flag areas you are unsure about. Self-review first; you will spot half the issues before anyone else looks.
Reviewers: ask questions before issuing commands. "Could we extract this?" beats "rewrite this." Distinguish blockers from suggestions. Approve when you would be comfortable maintaining the code, not when it is perfect. Speed matters — stale PRs rot.
Look for correctness first, then clarity, then style. Automated linters and formatters should handle tabs versus spaces. Focus human attention on logic, security, edge cases, and missing tests. If the same comment appears every PR, automate it.
AI assistants can summarize diffs and suggest fixes, but humans still own merges. Use Copilot comments as hints, not gospel. Security-sensitive paths deserve extra eyes regardless of what a bot said.
Culture tip: praise good work publicly in the PR. "Nice test coverage here" costs nothing and builds trust. Review is teaching — seniors explain patterns, juniors learn faster than reading docs alone. The goal is better software and a team that improves together, not winning arguments.