A pull request lands in the queue at 5:47 p.m. Four hundred lines, three files, a new endpoint, and a migration. The careful reviewer opens it, flags an unhandled null, asks for a missing test, points out that a variable name could be clearer, and hits approve.
The senior reviewer opens the same PR and asks a different question: why is this endpoint here at all, and what breaks in six months when the next person tries to extend it?
Both reviewers are useful. Only one of them is shaping the codebase. The distance between those two comments is most of what separates a senior engineer from a careful one, and it shows up in a handful of decisions every reviewer makes, on every PR, whether they notice or not.
Decide What the Review Is Actually For
The first decision happens before you read a single line. What is this review for? Careful reviewers answer, almost by reflex, that reviews catch bugs. Seniors answer differently, because the evidence has been pointing elsewhere for years.
A Microsoft study of how developers use code review found that while defect-finding is the stated motivation, the real payoff shows up in knowledge transfer, team awareness, and surfacing alternatives the author hadn't considered.
That reframing changes the comments you leave. If review is a bug hunt, you look for what's wrong. If review is how the team learns the codebase together, you look for what's unclear, what's undocumented, and what the next engineer will misread at 2 a.m. during an incident. Both matter, but only the second one compounds.
If you want a fuller picture of what separates the strongest practitioners from the rest, this guide on how to be a better software development professional is a good companion read.
Decide How Much Code You'll Actually Read
The second decision is scope. Careful reviewers try to read everything. Seniors know that past a certain size, reading turns into skimming with a straight face.
SmartBear's summary of the Cisco code review study put the practical ceiling at 200 to 400 lines per sitting; beyond that, defect detection drops sharply. This has two consequences most reviewers ignore.
- Push back on the PR size. An oversized PR isn't a review request; it's a rubber-stamp request. Ask the author to split it. That single comment does more for the codebase than any inline nit.
- Timebox the sitting. If you've been in a diff for an hour, your next comment is worse than your first. Close the tab, come back, or hand it to a second reviewer for the parts you didn't get to.
Decide Whether to Block or Approve With Notes
This is the decision that most exposes the difference. A careful reviewer treats every comment as a condition of merge. Nothing goes in until every thread is resolved. It feels rigorous.
In practice, it slows the team to a crawl, teaches authors to write smaller and safer changes that avoid the reviewer, and turns review into a gate rather than a conversation.
Seniors sort their comments as they write them. Blocking issues are the ones where merging would make the code worse: a real correctness bug, a security hole, a design choice that will cost the team later. Everything else, the naming preference, the alternative approach, the thing you'd have done differently, goes in as a note the author can take or leave.
If the change leaves the code healthier than it found it, approve it. Perfection isn't the bar; direction is.
Decide How You Talk to People Who Don't Read Code
Reviews aren't the only place this shows up. The same instinct, is this comment about the line, or about the system, is what separates the engineer who can sit in a room with a product manager, a compliance lead, and a customer, and translate between them. Careful engineers describe what the code does. Seniors describe what the decision costs and what it buys, in the vocabulary the listener already uses.
That skill isn't a soft add-on to the technical work. It is the technical work, at the level where architecture and business meet. The engineer who can say "if we do it this way, the next integration takes a week; if we do it the other way, it takes a day but we owe ourselves a rewrite in a year" is the one who ends up in the room where the trade-off gets made.
Decide Which Habits You're Willing to Repeat for a Decade
Careers in software are built out of small habits that repeat thousands of times. Reading the diff before commenting. Writing the commit message as if a stranger will read it in three years, because one will.
Leaving the code slightly better than you found it, even on a bug fix. Asking why once more than feels comfortable. None of these are dramatic. All of them compound.
The reviewer who does these things for a year looks careful. The reviewer who does them for a decade is the one other engineers ask for on their hardest PRs, not because the comments are the sharpest, but because the judgment behind them has been sharpened on ten thousand small decisions nobody wrote down. That's the seniority worth aiming at, and it is built one comment at a time.
