Code review is one of the highest-leverage practices in software — it catches defects, spreads knowledge across a team, and keeps a codebase coherent. It is also frequently where teams generate friction, delay and resentment. The difference is not tooling; it is a set of habits on both sides of the review, and most of them are about people as much as code.
Good review culture is learned, and it starts with remembering that the goal is better software and a stronger team, not proving who is cleverer.
For the reviewer: be kind and specific
Review the code, not the coder. Comment on the pull request, not the person: "this loop re-queries inside the iteration, which will be slow at scale" lands very differently from "why did you write it this way?" Distinguish clearly between blocking issues (real bugs, security problems) and preferences (style, naming you'd choose differently), and label the latter as optional so the author knows what actually must change.
Ask questions where you are unsure rather than issuing verdicts — the author often has context you lack. And praise genuinely good work; a review that is only criticism trains people to dread the process and hide their changes.
For the author: make review easy
Half of review quality is set before anyone reviews. Keep pull requests small and focused — a five-hundred-line change gets a rubber stamp; a fifty-line one gets real scrutiny. Write a description that explains what changed and why, so the reviewer starts with context instead of reverse-engineering intent. Review your own diff first and clean up the obvious before asking others to spend their time.
When you receive feedback, assume good faith and separate your ego from your code. Not every comment needs a change, but every comment deserves a considered reply — even "good point, but here's the constraint that led to this" keeps the conversation collaborative.
Keeping reviews fast
The silent killer of review culture is latency. A change that waits a day for review blocks the author, invites giant batched pull requests, and grinds delivery to a crawl. Teams that review well treat open reviews as a priority, aiming to respond in hours not days, and use automation — formatters, linters, tests in continuous integration — to handle the mechanical nitpicks so humans discuss things that matter.
Let the machines argue about semicolons and indentation; save human attention for logic, design and edge cases. A team that reviews small changes quickly, kindly and specifically ships faster and builds better software than one that either skips review or turns it into a slow, adversarial gate.