Reviewing for Nine Senior Engineers

I lead nine senior engineers. That single fact changes what code review is for.

On a mixed team, review is partly instruction. On a team of seniors, nobody is making mistakes born of ignorance — everyone writes correct code. What they can't all see is the same picture of the system. That's what review is for at this level, and it's why I still read everything.

Consistency erodes first

Nine strong engineers, left alone, produce nine slightly different reasonable approaches to the same problem — each defensible in isolation, and together a codebase where "how do we do X here" is answered with "depends who wrote it."

That cost stays invisible for a long time, then becomes the dominant cost of the project: onboarding slows because there's no pattern to learn, refactoring gets risky because nothing generalizes, estimates degrade because the work depends on which corner you land in.

Consistency isn't aesthetics. It's what makes a codebase learnable by someone who didn't write it. And the reviewer is the only person positioned to protect it — authors see their change; a reviewer who reads everything sees the drift.

Why I comment on everything

If I only flag significant issues, I'm making an invisible judgment call on every small one — and what authors experience is inconsistency: the same pattern flagged in one PR and ignored in the next. Unpredictable standards get ignored.

Commenting on everything makes the bar legible. Within months it converges: people internalize the standard, the comments stop being needed, and reviews get shorter without the bar moving.

The critical part is weighting. Not everything is a blocker, and pretending otherwise exhausts everyone. I separate explicitly: must change, suggestion, note for next time. An author who can't tell those apart will either fight all of them or comply with all of them — both bad.

What I'm reading for

• Does this belong here? Boundaries erode one reasonable exception at a time.
• Does something like it already exist? On a large project, duplication is more common than defects and more expensive over a year.
• What breaks that isn't in this diff? Shared types, state, components. The author tested their change; the question is what else touches it.
• Will this be modifiable in six months? Not "is it clever" — can the next person change it safely.
• Is the complexity earned? Seniors make the opposite mistake to juniors: over-abstraction. A configurable system with one caller is cost without benefit.

Notably absent: style, formatting, naming. If a human is spending attention there, the tooling has failed.

The bottleneck problem

Reviewing everything risks making you the constraint. Two rules manage it.

Fast beats brief. A thorough review within hours is fine. A short review two days later blocks nine people and teaches them to batch work into bigger, harder-to-review PRs.

Thoroughness should self-liquidate. If I'm making the same comment to the same person in month six, I've failed — that comment should have become a convention, a documented decision, or a lint rule. Repeated review feedback is a signal that something belongs in automation.

What review is actually for

Not catching bugs — tests and types do that more reliably than I do.

Review is where individually strong engineers become a team building one coherent system instead of nine good ones. It's the mechanism by which architectural intent survives contact with a delivery schedule.

That's worth reading every pull request for.