What Code Review Is Really For

In our early days review meant nitpicking: bad names here, shorter code there. People submitted nervously, and review became adversarial. Only after we changed the focus did it start working.

Ask the right questions first

Does this code solve the actual problem? A misread requirement matters far more than style.

Are the edges covered? Nulls, concurrency, permissions, retries are where production incidents come from.

Can the next person understand it? Six-months-later you counts as the next person.

What review should not be

Debating indentation and brackets. Formatting belongs to tools, not people.

Demanding the author rewrite it in the reviewer's style. If it is correct and readable, stylistic differences can stay.

Attacking competence in public comments. Be strict about code, respectful to people.

The goal of review is not code the reviewer likes, but code that stands up in someone else's eyes.