Career & Craft
Code Reviews
Teammates reading each other's changes before merge to catch bugs, improve design and spread knowledge of the codebase. Good reviews focus on correctness, readability and edge cases — not style bikeshedding, which linters should handle. They are as much about mentoring and shared ownership as defect-catching, so keep pull requests small enough to review well.
Purpose
Code review is teammates reading each other's changes before merge — catching defects, questioning design, and spreading knowledge of the codebase so no area belongs to one head. It is simultaneously a quality gate, a teaching channel and the strongest force for shared ownership a team has.
When to Use It
Every merge to a shared branch, via pull requests: correctness and edge cases first, then readability and design fit. Reviews are also how juniors absorb the codebase's idioms and how seniors document their reasoning in the open.
Trade-offs
Reviews add latency, and their two failure modes mirror each other: rubber-stamping (all cost, no protection) and nit-storms over style that a formatter should own. Oversized pull requests cause both — past a few hundred lines, review quality collapses into approval theatre.
Implementation
Keep PRs small and single-purpose with a description that explains why. Automate style entirely (formatters, linters) so humans review substance. As a reviewer: ask questions rather than issue commands, distinguish blocking concerns from suggestions, and respond promptly — review latency is a team-wide tax. As an author: review your own diff first.