How Senior Engineers Approach Code Review

Pull requests are the highest-leverage communication channel on an engineering team. Most people treat them like a bug filter. The best engineers I have worked with treat them like architecture sessions.

I have been on both sides of this for sixteen years. Teams where PRs were rubber-stamped in thirty seconds. Teams where a PR sat for two weeks while the author lost context and the merge became a nightmare. The good teams had one thing in common: they took code review seriously without turning it into a bureaucratic gate.

What code review actually does

The surface job is catching bugs before they hit production. That is real, but it is the smallest return.

The larger returns:

Knowledge distribution. Every PR is a transfer of understanding. The reviewer learns how a feature was implemented, where the edge cases live, why certain trade-offs were made. Over months, this is how a team stops having single points of knowledge. No one says "ask Sarah, that is her module."

Design pressure. Knowing someone will read your code changes how you write it. You name things more carefully. You add the test you were about to skip. You think twice about the shortcut that would take three minutes to understand. This effect is invisible in metrics but very real.

Collective ownership. When the team reviews together, the codebase belongs to everyone. The senior who wrote a module three years ago can step back without everything falling over. New engineers can navigate and contribute without a dedicated guide.

What changes at senior level

Junior and mid-level engineers tend to review for correctness: does this code do what it says? Senior engineers review for something different.

Consequences. What does this change do to the system six months from now? Does it introduce coupling that will be painful to unpick? Does it establish a pattern that everyone will copy? Does it handle the edge case that only appears at 10x the current load?

Intent. Not "does this code work?" but "is this the right thing to build?" A senior who ships a perfect implementation of the wrong thing has not added value.

Signal. A PR full of defensive null checks is telling you something about confidence in the data model. A PR that touches ten unrelated files is telling you something about the design. Good seniors read those signals, not just the diff.

How to review well

Read the description before the code. A diff without context is noise. Understand what the author was trying to do before you evaluate how they did it.

Focus on structure, not style. Linters handle formatting. Your job is to question architecture, data flow, error handling at the system boundary, and edge cases that only appear in production. If you are spending review time on semicolons, something is wrong with your tooling.

Ask questions instead of issuing verdicts. "What happens if this list is empty and the upstream service is also down?" lands very differently from "you forgot to handle the empty list." One invites thinking. The other creates defensiveness.

Keep PRs under 400 lines. Attention is not infinite. Beyond 400 lines, you are signing your name to something you have not fully understood. If a PR is too large, send it back with a specific suggestion for how to split it.

Same-day turnaround. A PR that sits for three days loses context and blocks momentum. Build the habit of reviewing in the morning, or batch reviews to a fixed window. Consistency matters more than speed.

How to make your PR easy to review

Write a real description. What changed, why, what you considered and rejected, a link to the ticket. Four sentences is enough. Zero sentences is not.

One concern per PR. Do not mix a refactor with a feature with a bug fix. They have different risk profiles and different reviewers. Separate them.

Self-review your diff first. Before you hit "request review," look at your own changes as if someone else wrote them. You will catch half the issues yourself.

Add context to non-obvious decisions. If you made a trade-off, say so in the description or as a comment. "I chose X over Y because Z" saves the reviewer from asking and saves you from defending a decision in isolation.

Anti-patterns that kill review culture

The rubber stamp. Approving without reading, to keep the queue clear. This is a false economy. The bugs you stamp through cost ten times as much to fix in production.

The scope creep. Leaving comments about things unrelated to the PR. "While I was here, this other function bothers me." File a ticket. Do not block a ship for unrelated observations.

The nit avalanche. Forty comments about variable names on a PR that fixed a critical bug. Automate style feedback with a linter and save your human review time for what actually matters. If you are not sure which linter to use, read why I replaced ESLint with oxlint: same idea, let the machine handle the mechanical stuff.

The silent approval. Approving with no comment at all means the author learns nothing, the codebase gets no shared context, and you have treated review as a checkbox. Leave at least one observation, even if it is positive.

The real trade-off

Code review slows individual velocity. That is the cost. The benefit is faster team velocity: fewer bugs, distributed knowledge, better design, stronger collective ownership. The math works out, but only if reviews are fast, focused, and treated as a conversation rather than a gate.

A review that takes longer than the code took to write is a signal. Either the PR is too large, the reviewer is not familiar enough with the codebase, or the review process has accumulated too many rules. Fix the constraint; do not accept it.

The coding principles behind good review decisions are worth reading alongside this. They are the foundation that makes code reviewable in the first place.

If you are working toward staff or principal, how you handle code review is one of the clearest signals of engineering maturity. It is not about being thorough. It is about being effective with limited attention. That distinction is what separates senior engineers from architects.

I write about this kind of thinking every week in the Monday BY Gazar newsletter. If you want to talk through what is blocking your next level, book a free intro call.