Google Engineering Practices
Google's internal guidance on code review, published free, covering both how to review and how to get your own change reviewed. The clearest available answer to what a code review is actually for.
Guide
Other
About 2 hours
Intermediate
Free
What it is
Two documents. One for reviewers on what to look for and how to give feedback, and one for authors on how to write a change list, describe it, and respond to comments.
The principle worth adopting
That a reviewer should approve a change once it definitely improves the codebase, even if it is not perfect. That single rule resolves most review conflict, because it replaces an unwinnable argument about ideal code with a decidable question about direction.
The part authors need
The section on responding to review comments, particularly on handling feedback you disagree with. Reviews turn hostile in a predictable way, and most of it comes from tone and from people defending a decision instead of explaining it.
Why it transfers
None of it depends on Google's scale or tooling. It works on a team of three.
Best for: anyone who reviews code or has code reviewed, which is everyone, and especially teams whose reviews have become a source of friction.
Ready to start?
Opens on Google in a new tab.
Stuck on something specific?
Writing only gets you so far. If you want an answer to your situation rather than the general case, book a session and we will work through it together. Every session is free; a few slots open each week.
Follow along
New writing, resources and project ideas land here first.