Code review is one of the most consequential daily interactions in software development, and it’s rarely taught explicitly. Most developers learn by osmosis — they absorb the norms of whatever team they first join, good or bad, and replicate them. The result is that some teams have code review cultures that make everyone better, and others have cultures that make people reluctant to submit PRs or defensive when they do. The difference almost always comes down to a small set of behaviors that are learnable once you name them.

What Good Code Review Actually Accomplishes

---

Before getting into mechanics, it’s worth naming what code review is actually for — because the answer shapes everything about how you should do it.

Code review catches bugs. That’s real, but it’s not the primary value. The primary value is knowledge transfer. When a reviewer understands why a change was made, they can maintain it. When an author explains their reasoning in the PR description, the team’s shared mental model of the system improves. When a reviewer asks “why this approach over X?”, both people learn something.

Reviews that only look for bugs miss most of the value. Reviews that engage with design, naming, and reasoning create a team that gets collectively smarter over time.

Giving Feedback — The Reviewer’s Responsibilities

---

Be specific about the problem, not just that there is one

“This doesn’t look right” is useless. “This query runs inside a loop and will produce N+1 calls at scale — consider preloading user.orders before this block” is actionable. Specific feedback gets acted on. Vague feedback creates anxiety and guessing.

Distinguish between required changes and suggestions

Not every comment is a blocker. Some things you’d genuinely do differently but are acceptable as written. Some are bugs that must be fixed. Confusing the two creates friction — the author doesn’t know what they must do versus what you’re just musing about.

Use explicit prefixes that your team agrees on:

• nit: — minor style preference, take it or leave it
• suggestion: — worth considering but not blocking
• question: — I’m trying to understand, not necessarily saying this is wrong
• blocking: — must address before merge

This makes the review legible and reduces the back-and-forth of “did you need me to fix that or were you just noting it?”

Explain why, not just what

“Extract this into a method” is less helpful than “extract this into a method — this block is doing two things (validation and transformation) and naming the method makes both clearer and easier to test independently.” The why teaches. The what is just a task.

Lead with what works

A review that opens with ten problems and no acknowledgment of what the PR does right puts the author on the defensive immediately. Note what’s good — a clever solution, a well-named variable, a test that covers an edge case you hadn’t thought of — before diving into changes needed. This isn’t flattery; it’s context that helps the author calibrate which problems are serious and which are minor.

Receiving Feedback — The Author’s Responsibilities

---

Write a description that does the reviewer’s job

The PR description is where you earn goodwill before the review starts. Explain: what does this change do? Why was it done this way? What alternatives did you consider? Are there specific areas you’d like attention on?

A blank description or “fixes bug” tells the reviewer nothing. They’ll spend 20% of their review time trying to understand context you already have. Give it to them upfront.

Don’t take feedback on code personally

This sounds obvious. It isn’t. When you’ve spent three days on a feature and someone’s first comment is about a naming issue, it stings. The review is about the code, not about you. Separate the two explicitly in your mind, because conflating them leads to defensiveness that makes you worse at receiving the feedback that actually matters.

Push back when you disagree — but with reasoning

“I disagree” is not a response. “I considered this approach, but went with the current one because of X — does that change your view?” is. You’re not obligated to accept every suggestion. You are obligated to engage with it seriously and explain your reasoning if you’re declining.

Good reviewers expect and welcome pushback with reasoning. It’s a signal that you thought carefully about the design, not that you’re being difficult.

Pro-Tip: If a code review comment requires more than three exchanges to resolve, get on a call. Async text is a terrible medium for nuanced technical disagreements — the tone is ambiguous, the context is compressed, and both parties spend more energy than the issue warrants. Five minutes of conversation resolves in real time what might spiral into a day of back-and-forth text.

The PR Size Problem

---

The biggest practical factor in review quality is PR size. A PR with 50 lines of changes gets a careful review. A PR with 500 lines gets a skim and a few comments on the parts the reviewer happened to notice.

This isn’t laziness — it’s cognitive limits. Reviewers can hold a limited amount of context. Large PRs exceed that limit, which means bugs and design issues get missed.

If you’re working on a large feature, break it into reviewable chunks: infrastructure first, then behavior, then polish. Each PR should do one thing well enough that a reviewer can hold the full intent in their head.

Team Norms Matter More Than Individual Skill

---

The best code review culture isn’t a function of having great individual reviewers. It’s a function of shared, explicit expectations. Teams that define what makes a PR ready for review, what kinds of comments are blocking vs. optional, and how to handle disagreements have dramatically better review experiences than teams that rely on implicit norms.

If your team doesn’t have explicit code review guidelines, writing them is an afternoon well spent. Not a 20-page document — a one-page list of agreements that the team actually made together. “We use nit: for style preferences,” “PRs should be under 400 lines,” “descriptions must explain why, not just what” — simple rules that prevent the most common friction.

Conclusion

---

Code review is a skill, and like most skills it improves with deliberate attention. The technical part — reading code, spotting bugs, suggesting improvements — is only half of it. The communication part — being specific, separating blocking from non-blocking, receiving feedback without defensiveness, knowing when to escalate to a conversation — is the other half and often the harder one. Teams that get both right have review cultures where people actually want to submit code for review. That’s the goal.

FAQs

---

Q1: How long should a code review take?
Depends on PR size and complexity. A 50-line focused change: 15–30 minutes. A 200-line feature PR: 45–60 minutes. If a review is taking longer, the PR is probably too large. Most teams benefit from a norm that reviews happen within one business day — longer creates flow-killing delays.

Q2: Should I review code in areas I’m not familiar with?
Yes, but with appropriate humility. “I’m not familiar with the authentication layer, but this variable name is confusing to me as a reader” is a valid comment. Ask questions rather than making authoritative statements about areas you don’t own. Fresh eyes catch different things than domain experts.

Q3: Is it okay to merge your own PR if no one reviews it?
Depends on team norms and PR stakes. For tiny changes — typo fixes, minor config updates — self-merging is often fine. For anything that affects behavior or interfaces, wait for review. If review latency is a recurring problem, that’s a process issue to raise explicitly rather than work around by self-merging.

Q4: How do you handle a reviewer who’s consistently harsh or discouraging?
Name it directly and specifically with that person, privately. “When you comment without explaining why, I find it hard to improve — can we try X approach instead?” Most harsh reviewing is habit, not malice. If it continues after being named, escalate to your manager. A review culture that discourages submission is a team health issue, not a personal quirk.

Q5: Should tests always be included in the same PR as the feature?
Generally yes — tests and implementation reviewed together let the reviewer verify that the tests actually cover the behavior being added. The exception is pure refactors (behavior unchanged, tests already exist) or exploratory spikes that aren’t production-bound. Default to tests-in-same-PR; deviate with explicit justification.