Code reviews are one of the highest-leverage practices in software development: they catch bugs, improve quality and spread knowledge through a team. They are also one of the easiest practices to do badly. Done right, reviews strengthen both the code and the people; done wrong, they produce friction, resentment and rubber stamps.
Before you submit
A good review starts before the reviewer arrives. Review your own code first, catch the obvious mistakes, and make sure the change is either self-descriptive or documented. Sending unpolished work to a reviewer outsources work that was yours.
Giving reviews
The practices that hold up:
- Be respectful. Constructive beats critical, every time.
- Be specific. "This could be better" helps nobody; a concrete suggestion does.
- Critique the code, not the coder. The moment feedback feels personal, learning stops.
- Limit scope. Small, frequent reviews find more and hurt less than giant ones.
- Stay consistent. Feedback should follow team standards, not reviewer mood.
Framing matters too — acknowledging what is good in a change is not politeness theatre; it tells the author what to keep doing, while the constructive middle ("this function is long, consider breaking it up") tells them what to change.
And ask questions rather than issuing verdicts. "What led you to this approach?" often surfaces context the reviewer lacked — or leads the author to a better solution on their own. Reviews are conversations, not gatekeeping.
Receiving reviews
Receiving feedback is a skill of its own. Don't take it personally — it is about the code. Stay open to suggestions, even when your first instinct is to defend the design. And when a comment is unclear, ask; guessing at a reviewer's intent wastes a round trip.
Let tools do the boring part
Linters, automated tests and quality gates should catch formatting issues, obvious bugs and style violations before a human ever looks. Every mechanical comment a tool makes is attention freed up for the things humans are actually good at: design, clarity, edge cases and intent.
Respectful, specific, small and well-tooled — that is most of it. It sounds simple, and it is; the difficulty is doing it consistently. Teams that manage it don't just get better code out of reviews. They become better teams.