Code Review Is Not About You

I left a twenty-comment code review once.

I was proud of it.

Thorough. Detailed. Every edge case. Every naming inconsistency. Every place I would have done it differently.

The engineer on the other side had been coding for three months.

I told myself I was raising the bar. Setting standards. Protecting quality. Showing what good engineering culture looked like.

It was not.

I was performing expertise at the expense of someone who was still learning to trust themselves.

Technically Correct Can Still Be Wrong

This is the part that took me too long to learn:

A review can be technically correct and still be a bad review.

Every comment may be defensible. Every suggestion may improve the code. Every nit may match the team's conventions.

And the review can still fail because it teaches the wrong thing.

It can teach the author that nothing they write is good enough. It can teach them to fear reviews. It can teach them to optimize for avoiding comments instead of understanding tradeoffs. It can turn a learning moment into a confidence tax.

That does not mean lowering the bar.

It means understanding what the bar is for.

Code Review Is a Teaching Moment Disguised as a Quality Gate

Teams often talk about review as a quality gate.

That is true, but incomplete.

Code review is also one of the highest-frequency teaching systems in an engineering organization.

Every comment says something:

• This matters.
• This does not matter.
• I trust your judgment here.
• I do not trust your judgment here.
• This is a team standard.
• This is just my personal preference.
• This risk is worth stopping for.
• This imperfection is acceptable.

Reviewers are always teaching, whether they intend to or not.

The question is whether they are teaching well.

Restraint Is a Senior Skill

The best reviews I have ever received were not the longest.

They had three comments. Maybe four.

The reviewer had clearly looked at everything, chosen what actually mattered, and left the rest alone.

That restraint is a skill.

Most engineers never develop it because nobody tells them the review is not about proving they saw everything. It is not about showing how much better the code could be if they had written it. It is not about turning every difference in style into a correction.

It is about improving the change, the codebase, and the engineer.

Sometimes that means commenting.

Sometimes that means letting something go.

Separate Risk, Standards, and Preference

A useful review distinguishes three categories.

Risk

This can break production, create security exposure, corrupt data, hurt users, or make future changes meaningfully dangerous.

Risk comments should be direct and blocking.

"This retry can double-charge if the provider times out after authorization. We need idempotency before merging."

Standards

This violates an agreed team convention or architectural boundary.

Standards comments can be blocking if the standard matters.

"This bypasses the repository layer. We have kept all writes behind that boundary to preserve audit behavior."

Preference

This is how you would have done it.

Preference comments should be rare, optional, or framed as suggestions.

"Non-blocking: I might name this differently because it reads like a command rather than a result."

Many bad reviews happen because reviewers treat preference like risk.

That burns trust.

Ask Better Questions

Questions are often more useful than declarations, especially when reviewing developing engineers.

Instead of:

"This will not scale."

Try:

"What happens to this query when the table has 10 million rows?"

Instead of:

"Bad abstraction."

Try:

"What other caller do we expect to share this abstraction? If there is not one yet, would keeping it local be simpler?"

Instead of:

"This test is useless."

Try:

"What failure would this test catch that the existing integration test would miss?"

Good questions teach thinking. They also leave space for the author to surprise you.

Praise Specifically

Review silence often means approval, but silence does not teach much.

When you see good work, name it.

"This error path is clear."

"Good separation between validation and persistence."

"The test data setup makes the scenario easy to follow."

"This is a simpler approach than the one I expected."

Specific praise is not fluff. It reinforces what right looks like.

If engineers only hear from reviewers when something is wrong, review becomes a threat signal.

Review the Thinking, Not Just the Diff

The most valuable review conversations are often not line-level.

They ask:

• Why this approach?
• What alternatives did you reject?
• What risk are you most worried about?
• What would make this design wrong?
• How will we know in production?

Those questions help engineers develop judgment.

They also create better artifacts because the team learns to explain decisions, not just produce code.

This is especially important in AI-assisted development. When code is easier to generate, the reasoning behind the code matters more.

For Authors: Help the Reviewer Review Well

Review quality is not only the reviewer's job.

Authors can make reviews better by providing context:

• What problem does this solve?
• What tradeoff did you make?
• What are you uncertain about?
• What kind of feedback do you want?
• What should the reviewer ignore because it is generated or mechanical?

A good pull request description reduces random reviewing. It directs attention to the parts that matter.

That is another form of engineering visibility. You are making your thinking legible.

The Review Is Not About You

This is the line I wish I had learned earlier:

The review is not about you.

It is not about proving your expertise. It is not about rewriting the code in your style. It is not about winning taste arguments. It is not about making the author feel the full weight of everything you know.

It is about helping the team ship safer work and helping the person on the other side become stronger.

Sometimes the most senior thing you can do in a review is leave fewer comments.

Choose what matters.

Explain why it matters.

Let the rest go.

---

Technical leverage is not only what you build. It is how you raise the quality of the people and systems around you. The Engineering Visibility Score assessment can help you see whether that leverage is visible enough for your next level.