Code review is one of the highest-leverage quality practices available, but a poorly run review process creates friction without actually catching more bugs — a few practices genuinely move the needle.
What Actually Improves Review Quality
- Smaller PRs — a 50-line PR gets a genuinely thorough review; a 2,000-line PR gets a rubber stamp, because no reviewer can hold that much context meaningfully
- Automate the mechanical stuff — let linters and formatters catch style issues, so human review time goes to logic and design, not tabs vs spaces debates
- Review the diff with the PR description open — understanding why a change was made catches design issues a line-by-line read alone would miss
Giving Feedback That Lands
Less useful: "This is wrong."
More useful: "This will throw a null reference if <code>user</code> is deleted
between the check and the update - worth handling?"
Less useful: "Why did you do it this way?"
More useful: "Curious about the trade-off here vs approach X -
was there a specific reason you went this direction?"
Framing feedback as a specific, concrete scenario (rather than a vague judgment) makes it both easier to act on and far less likely to feel like a personal criticism — a genuinely important distinction for keeping code review psychologically safe on a team.