The goal of a Staff Engineer review is the team's growth. Finding bugs is the base of the work, and tooling already catches part of that before a PR opens. What separates this review from an ordinary one is what you write in the comment and what you choose to let pass.

Four anti-patterns that weaken a review

Style nitpicks. Spacing, quotes, import order: you have a linter and CI complaining on every push. The Google Engineering Practices standard for reviewers ranks style and automated convention below correctness and design. A style comment spends the author's attention on something a tool resolves alone.

Rewriting code in the comment. "I'd do it like this:" followed by twenty lines imposes your solution and teaches the person to copy. A comment with the problem and the constraint leads the author to produce their own solution.

Approving without reading. A thirty-second LGTM protects the deadline and moves the risk to production. Saying "I can't review this week" is more honest and faster for whoever is waiting.

Blocking on taste. "This violates our error-handling standard" is a principle with a reason recorded somewhere in the team. "I prefer Promises to async/await" is preference. The same Google document separates the two and asks a blocking comment to name a concrete risk or a violated agreement.

The comment that transfers reasoning

A short comment forces the author to guess the reason. A comment with context returns the reason along with the request, and whoever reads the PR next learns the reasoning too.

// weak
"use memoization here"

// strong
"This component re-renders on every parent state change, even when the
`items` prop stays the same. useMemo on this calculation avoids re-renders
on large lists. Context: we discussed this in issue #847, orders screen."

The strong version delivers cause, effect, and history. The Google comment guide asks for exactly that: explain why and suggest a path instead of pointing at the defect and leaving.

Explicit weight for each comment

  • Blocker: stops the merge. Security, correctness, a broken API contract. Name the risk in the sentence.
  • Suggestion: recommends and does not hold. "Extracting this into a helper makes it easier to test, though inline works too."
  • Nit: a light opinion, prefixed with nit:, the convention Google adopted. The author skips it without discussion.
  • Question: you want the decision behind the code. "Why Map here instead of a plain object? I want the same criteria in the billing module."

Putting the category at the start of the sentence removes most misunderstandings. An author who reads "nit:" knows a reply is optional.

Praise that names what worked

When the code carries a good choice, say which choice it is. "Liked it" teaches the next reader nothing; "the discriminated union here makes invalid state unrepresentable, I'll use the same idea in the payments module" teaches two engineers at once.

// "The discriminated union here makes invalid state unrepresentable.
// I'll use the same idea in the payments module."

Specific feedback in both directions turns the PR queue into something other than a gauntlet.

When a thread passes four replies

An async discussion with more than four replies costs more than the fifteen-minute call that settles it. Call the person, align, then write the decision into the PR for whoever arrives later. Chapter 9 of Software Engineering at Google treats review as engineering conversation and recommends a small CL precisely so the discussion fits in text.

Architecture comes before code. A short design doc, commentable while changing is cheap, prevents the eight-hundred-line PR nobody reviews.

What you let pass on purpose

Code that works, stays maintainable, and breaks no principle gets your approval even when it differs from what you would have written. You hold context the author lacks; the author holds context you lack. Blocking PRs above the necessary standard charges the team speed and pays little back.

The Google guide on what to look for lists design, functionality, complexity, tests, names, and comments in that order. Bugs live in functionality; developing the team lives in the comment you write.

References