How code review actually works (and how to not take it personally)

Your first code review will sting. The reviewer will leave more comments than you expected, some will feel pedantic, and at least one will make you wonder if you should've gone to law school. This guide is the unwritten rule book, what reviewers are actually evaluating, how to respond like a professional, and how to disagree without burning the relationship.

What code review is for

Most juniors think code review is a "is this code correct?" check. It's not, mostly. By the time it reaches review, the code probably runs and the tests probably pass. The reviewer's actual goals, in priority order:

1. Catch bugs the author missed. Especially edge cases, race conditions, and security issues.
2. Verify the change matches the team's conventions. Naming, error handling, file organization.
3. Spread knowledge. Now another engineer knows this part of the code exists.
4. Mentor. Especially for junior PRs, reviewers know they're shaping how you'll work for the next year.
5. Gate quality. Some reviewers are harsher than others; the team's standard is what stays in main.

You'll get review comments at all five levels. The pedantic-feeling comments are usually about #2 (conventions), and even though they feel like nitpicks, they're how the codebase stays consistent across 50 engineers over 5 years.

The signal reviewers are reading

When a senior engineer reviews a PR, they're forming an impression of you in roughly 30 seconds. The signals that matter:

Did you read your own diff?

Before requesting review, every senior expects you to have walked through your own diff line by line. They can tell when you didn't, there's a leftover console.log, a debug comment, an unused import. Catching these yourself takes 60 seconds and dramatically improves the impression.

Did you write a real PR description?

"Fixes the bug" is a bad PR description. A good one explains:

• What changed (one line).
• Why (the user-visible problem or the ticket link).
• How a reviewer can verify it manually.
• Anything risky or surprising, "I had to refactor X to do this; here's why."

See our guide on writing pull requests for the full template.

Is the diff small enough to review?

The single biggest predictor of review quality is PR size. PRs under 200 lines get thoughtful, careful reviews. PRs over 800 lines get rubber-stamped or sit unreviewed for days because nobody has the energy.

If your change is large, split it. Refactor first as a separate PR, then add the new feature. The total work isn't more, but the reviews you get back will be 5x more useful.

The five types of review comments

Every review comment falls into one of five categories. Knowing which type you're getting tells you how to respond.

1. Bug

"This will crash if the array is empty." "You're not handling the case where the API returns 404."

Response: fix it. Always. Even if you think the case can't happen, the reviewer is trying to harden your code, defensive code that handles "impossible" cases catches real bugs in production.

2. Code quality / convention

"We use const here, not let." "This function is too long; can you split it?" "Move this helper to utils/ with the others."

Response: apply, even if you disagree. Convention follows team consistency, not personal preference. Save the disagreement for design discussions, not PR comments.

3. Architecture / design

"Why did you put this in the controller instead of a service?" "This couples the user model to billing, should we add an interface?"

Response: this is the most important type. Take it seriously. Either explain your thinking or ask the reviewer to elaborate, then probably refactor. Architecture comments often catch problems that would cost weeks to fix later.

4. Question

"Why does this need to be async?" "What happens if both flags are true?"

Response: answer in the thread. Don't argue, don't get defensive, they genuinely don't know and want to learn. Sometimes "why" questions reveal a hidden assumption you should make explicit in code or a comment.

5. Nit

Often prefixed: "nit:", meaning "this is small and you can ignore it." "nit: missing trailing comma." "nit: this name could be more specific."

Response: if a reviewer marks it as a nit, you can apply it or skip it. Most teams treat nits as optional. But many small fixes add up, applying nits consistently makes you read as detail-oriented.

How to respond to feedback (the script)

The mechanical loop for handling a review:

1. Read every comment first, before responding to any. If you reply one-by-one, you'll miss patterns.
2. Sort by type. Bugs and architecture first, conventions second, nits last.
3. For each comment, do one of four things:
   • Apply it. Reply with a short "Done" or 👍 reaction.
   • Apply it differently than they suggested. Reply explaining what you did.
   • Disagree, with reasoning. (See below.)
   • Ask for clarification. ("I'm not sure I follow, do you mean X or Y?")
4. Make all the changes in one or two commits. Don't push 12 small commits per review round; squash them or aggregate by theme.
5. Re-request review with a brief comment summarizing what you addressed. ("Thanks, applied all the convention nits, refactored the auth check per your suggestion. Question on the caching comment in thread.")

Following this script makes you read as senior even when you're not.

How to disagree without burning the bridge

Sometimes you're right and the reviewer is wrong. Or both options are valid and they prefer one and you prefer another. You can disagree, the trick is doing it in a way that doesn't make the reviewer feel attacked.

The structure that works:

1. Acknowledge their point first. ("Good point, that pattern is more flexible.")
2. State your reasoning specifically. ("In this case I think the simpler version is better because the abstraction would only have one user, and we'd be paying complexity cost for hypothetical future needs.")
3. Defer to their judgment if they push back. ("Happy to refactor if you feel strongly, your call.")

That last sentence is the key. Most code-review disagreements aren't worth fighting. The reviewer probably has more context. If they push back on your pushback, just do it their way and move on. Pick your battles for things that actually matter.

What "actually matters" means

Things worth pushing back on:

• The reviewer is asking you to introduce a real bug or remove an important check.
• The suggested approach has security implications they may not have noticed.
• The change would significantly delay your PR and the alternative is equivalent.
• The team has a different convention than the reviewer is suggesting.

Things not worth pushing back on:

• Stylistic preferences you don't strongly hold.
• Naming differences ("I prefer getUserById" vs "I prefer fetchUser").
• Where to put a helper function.
• Anything that takes < 10 minutes to apply.

The asymmetry: applying a small change costs 5 minutes. Arguing about it costs 30 minutes of back-and-forth and damages the relationship. The math is obvious.

The emotional reality of review

Code review hurts more than it should. Even seniors privately wince when they get a wall of comments. The fact that you'll feel defensive isn't a character flaw, it's normal.

What helps:

• Time. Your fifth PR feels less personal than your first.
• Reframing. Comments are about the code, not about you. Your code is not your identity.
• Reading other people's reviews. Your manager and peers are getting comments too. You're not uniquely bad, review just looks like a personal grade.
• Walking away before responding if a comment really stings. Read, take a 10-minute break, then write your reply. Never write an angry response in the moment.

How to be a great reviewer (when it's your turn)

Eventually you'll review someone else's code, sometimes within your first month. The principles:

1. Be specific. "This isn't great" is unhelpful. "This will return the wrong value when the input is empty" is actionable.
2. Ask, don't command, when you're uncertain. "Why did you choose this approach?" is better than "Don't do this."
3. Mark nits. Use the "nit:" prefix for small stuff so the author knows it's optional.
4. Praise the good parts. "Nice, this refactor is much cleaner." Costs nothing, builds trust.
5. Don't review when tired or frustrated. The mood leaks into the comments. Come back when you're rested.
6. Approve when it's ready, even if not perfect. Perfect is the enemy of shipped. If the code is good enough and there are no bugs, approve and move on. The author can fix nits in a follow-up.

Reviewers who follow these get more PRs sent to them and more thanks. Reviewers who don't get avoided.

The wrong feedback patterns to watch out for

Not all reviewers are good reviewers. If you encounter these patterns repeatedly, talk to your manager, it's a real problem worth surfacing:

• Style obsession over substance. If 80% of comments are formatting/naming and the actual logic isn't being engaged with, the reviewer is rubber-stamping with extra steps.
• Personal attacks. "This code is terrible" is unprofessional. "This approach has problem X" is fine.
• Inconsistent standards. Demanding things from you that aren't enforced on senior PRs is a real form of unfairness.
• Endless rounds. Some reviewers can't approve and keep finding new things in round 4. Talk to your manager about norms, usually you should be done in 2-3 rounds.

You don't need to suffer through bad review patterns silently. But also: be sure you've understood what's being asked before assuming the reviewer is being unreasonable.

The professional shift

For your first three months, your code will be reviewed line by line. By month six, your reviewers will have learned what to expect from you and will skim. By year one, you'll be reviewing junior PRs yourself.

The students who advance fastest are the ones who treat early review feedback as training data. Each comment is a free lesson from someone with more experience. Save useful feedback in a personal "lessons learned" doc, patterns will emerge, and addressing them proactively in future PRs is what separates "okay junior" from "fast-tracked junior."

Your reviewers are not your adversaries. They're your free tutors. Treat the relationship that way and you'll grow faster than feels possible.