A junior engineer does code review to find bugs. A mid-level engineer does code review to ensure the code works, is readable, and follows standards. A Staff Engineer does code review to develop the team.

The difference is in objective, not rigor. That objective changes what you prioritize in comments, how you write them, and what you let pass.

What a Staff Engineer's review should NOT be

The anti-patterns that weaken senior reviews:

Style nitpicking: if you have a linter, let the linter complain. Comments like "spacing here" or "I prefer semicolons" are noise. Automate what can be automated, and use your time for what can't.

Rewriting code in the review: comments like "I'd do it like this: [20 lines of code]" rarely teach. They impose. The person learns to become you, not to think for themselves.

Approving without reading: automatic "LGTM" doesn't serve the team. If you don't have time to review, say so. Don't pretend to review.

Blocking for preferences, not principles: there's a difference between "this violates our error handling standard" (principle with documented reason) and "I prefer Promises over async/await" (personal preference). Reviews that block for preferences create friction without value.

What transfers knowledge

The most effective comment format is a question or an explanation with context:

// Weak:
// "Use memoization here"

// Strong:
// "This component re-renders on every parent state change, even when
// the `items` prop doesn't change. useMemo on this calculation or
// React.memo on the component would prevent unnecessary re-renders
// on large lists.
// Internal reference: we discussed this when we had performance issues
// on the orders screen: issue #847."

The strong version explains why, connects to impact, and links to historical context. The person doesn't only learn to fix it. They learn to reason through it.

How to categorize comments

A practice that reduces misunderstandings: making the weight of each comment explicit.

  • Blocker: must be fixed before merge. Security, correctness, API contract violation. Be specific about the risk.
  • Suggestion: you recommend it but don't block. "I suggest extracting this to a helper, it'd be more testable, but I understand if you prefer to keep it inline for now."
  • Nitpick: opinion without weight. "Nit: I prefer the name `fetchUser` over `getUser` for consistency, but no need to change." The author knows they can ignore it.
  • Curiosity/question: you're learning, not criticizing. "Why did you choose Map here instead of a plain object? Curious to understand the reasoning."

The comment few people write: the specific compliment

Code review isn't only about problems. When you see particularly well-done code (an elegant abstraction, a careful test, a simple solution to a complex problem), say so explicitly:

// "Really liked this approach: using a discriminated union here makes it
// impossible to represent invalid state. I'm going to use this same idea
// in the payments module I'm working on."

Specific compliments do two things: reinforce the behavior you want to see more of, and create an environment where review isn't a gauntlet to survive.

Async vs. sync reviews

Review comments don't scale well for complex discussions. If a comment thread has reached 4+ replies, it should be a conversation, synchronous or via voice note. Document decisions from those conversations in the PR.

For large architectural changes, do the review before the code is written. An RFC or design doc that can be commented on while it's cheap to change.

What a Staff Engineer lets pass (intentionally)

Part of maturity in reviews is knowing what not to comment on. Code that isn't ideal but works, is maintainable, and doesn't violate principles. Let it pass. You have context the author doesn't, but the author also has context you don't.

Not every PR needs to result in the code you would have written. Sometimes the goal is for the team to ship, learn from the process, and improve on the next one. Blocking PRs at a standard higher than necessary is a velocity cost that isn't always worth it.