Code review is one of the few practices every engineering team shares, and one of the easiest to get wrong. Done well, reviews catch bugs before production, keep the codebase consistent and quietly teach everyone on the team. Done badly, they become a bottleneck, a source of nitpicking, or a rubber stamp nobody reads.

As a senior engineer you set the tone for reviews, both through the reviews you write and the way you respond to feedback on your own code. Here's how to make them work.

Why Code Reviews Matter

A good review process does four things at once:

  1. Finds defects early, when they're cheapest to fix.
  2. Spreads knowledge, so more than one person understands each part of the system.
  3. Keeps the codebase consistent in structure, naming and patterns.
  4. Grows developers. For junior engineers especially, reviews are one of the main ways they learn how the team works.

Keeping all four in mind stops reviews from shrinking into "does it compile and look tidy".

Step 1: Make Pull Requests Easy to Review

Good reviews start with the author. Ask your team to follow a few simple rules:

  • Keep PRs small. Aim for a few hundred lines of meaningful change at most. Large PRs get skimmed, not reviewed.
  • One purpose per PR. Don't mix a refactor, a bug fix and a new feature.
  • Explain the why. The description should say what problem this solves, how, and how it was tested.
  • Point out the risky parts. "Please look closely at the retry logic in payments.ts" saves the reviewer time.

A simple template in the repository helps:

## What and why
<!-- What does this change do, and why is it needed? -->

## How
<!-- Key implementation decisions and trade-offs -->

## Testing
<!-- How was this tested? Screenshots for UI changes -->

## Risks / things to check
<!-- Anything the reviewer should look at closely -->

Step 2: Review in the Right Order

Start broad and finish narrow. Reviewing typos before checking whether the approach makes sense wastes everyone's time.

Funnel of five review questions from the right problem down to readability
Work from the top down, and stop early if the problem or approach is wrong.
  1. Does it solve the right problem? Re-read the ticket or requirement first.
  2. Is the approach sound? Architecture, data model, API design, edge cases, failure modes.
  3. Is it correct? Logic, error handling, concurrency, security, performance hot spots.
  4. Is it tested? Do the tests cover the important paths, including failures?
  5. Is it readable and maintainable? Naming, structure, duplication, comments where the code isn't obvious.

If step 1 or 2 has a problem, say so early and stop there; there's no point polishing code that will be rewritten.

Tip

Let tools handle formatting and style. A linter and formatter in CI (ESLint, Prettier and so on) remove a whole category of comments, so human reviewers can focus on what tools can't judge.

Step 3: Label Your Comments

Not every comment carries the same weight, and authors can't read your mind. Prefixing comments makes the intent clear:

Prefix Meaning
blocking: Must be fixed before merging (a bug, a security issue, broken behavior)
suggestion: A better approach worth considering; the author decides
question: You don't understand something; may or may not lead to a change
nit: Minor style or naming preference; fine to ignore
praise: Something done well, worth calling out

This alone removes a lot of friction. Authors stop treating every nit as a demand, and reviewers stop arguing over things that don't matter.

Step 4: Write Comments That Teach

The difference between a frustrating review and a helpful one is usually tone and context, not content. Compare:

"This is wrong."

with:

"blocking: if fetchUser throws here, the transaction stays open and holds the lock. Could we wrap it in try/finally and roll back on error?"

Good review comments:

  • Explain the reason, not just the change.
  • Suggest a concrete fix or ask a guiding question.
  • Talk about the code, not the person. "This function does X" rather than "you did X".
  • Recognize good work. A quick "nice, this is much cleaner" makes critical feedback easier to hear.

Note

For junior developers, a guiding question ("What happens if the list is empty?") often teaches more than handing over the answer. Save direct fixes for when time is tight.

Step 5: Keep Reviews Fast

Slow reviews are one of the biggest hidden costs in a team. A PR waiting two days blocks the author, invites merge conflicts and encourages bigger, riskier PRs next time.

Agree on a team expectation, such as a first response within half a working day, and make it easy to meet:

  • Review in batches a few times a day rather than whenever a notification arrives.
  • If you can't do a full review soon, say so and suggest someone else.
  • For large changes, pair on the review over a call instead of trading dozens of comments.
  • Approve with minor comments when the remaining issues are nits the author can fix without another round.

Step 6: Be a Good Author Too

Senior engineers model how to receive feedback as much as how to give it:

  • Assume good intent. The reviewer is trying to help the code, not attack you.
  • Respond to every comment, even if only "done" or "good point, will follow up in a separate PR".
  • Push back with reasons when you disagree, and accept that sometimes the team's convention wins.
  • Move long debates to a call. Three rounds of back-and-forth in comments is a sign a five-minute conversation would be faster.

Code Review Checklist

Before approving, ask yourself:

  • Does this solve the actual problem described in the ticket?
  • Is the approach reasonable, and are trade-offs explained?
  • Are edge cases and failures handled (empty input, timeouts, retries, permissions)?
  • Are there tests for the important paths?
  • Is anything security-sensitive (auth, input validation, secrets, data exposure)?
  • Will someone new to this code understand it in six months?
  • Are my comments labeled, explained and respectful?

Summary

Great code reviews are fast, focused on what matters, and written to teach. Make PRs small and well described, review the approach before the details, label comments by importance, and keep turnaround short. Over time, the team writes better code before review even starts, and that's the real goal.