Code Review That Teaches

Most code review is gatekeeping disguised as collaboration. A senior engineer scans a PR, leaves a few "nit" comments about naming conventions, maybe spots a logic issue, approves or requests changes, and moves on. The author addresses the comments. The code merges. Nobody learned anything.

Code review has the potential to be the most effective knowledge-sharing mechanism on a team — a continuous, contextual exchange of expertise that happens alongside the real work. But it only fulfills that potential when reviewers approach it as teaching rather than judging.

What Code Review Actually Accomplishes

Knowledge Distribution

When you review code in a part of the codebase you don't usually work in, you learn how that area works. When you review someone else's approach to a problem, you see patterns you might not have considered. Code review is how teams prevent knowledge silos — the dangerous state where only one person understands a critical part of the system.

Standard Alignment

Teams develop conventions — naming patterns, architectural patterns, error handling approaches. Code review is where these conventions are reinforced and evolved. Not through enforcement ("you broke the rule") but through conversation ("here's why we do it this way, and here's when we might do it differently").

Better Design

The best design feedback happens during code review, when the implementation is concrete enough to evaluate but not so finished that changing direction is painful. "Have you considered using a strategy pattern here?" during review is more useful than the same suggestion during a design meeting when the problem is abstract.

Reviewing for Teaching

Explain the Why

The least useful review comment: "Use a map instead of a for loop."

The most useful review comment: "Consider using a map here — it communicates that you're transforming each element without side effects, which makes the intent clearer and prevents accidental mutations."

The first tells the author what to change. The second teaches them the principle that applies to this change and every future similar situation. The first creates compliance. The second creates understanding.

Ask Questions Before Making Statements

"Why did you choose to fetch the data here instead of in the parent component?"

This question might have one of several answers:

• "I didn't think about it — good catch, I'll move it up" (genuine improvement)

• "The parent component re-renders too frequently, so fetching here avoids unnecessary calls" (you just learned something)

• "The data is only needed in this component and I wanted to keep the dependency local" (reasonable design decision you might have made differently)

If you'd said "move the fetch to the parent component" without asking, you'd have either gotten compliance without learning or an argument without context. Questions invite explanation. Statements invite defense.

Distinguish Opinions from Requirements

Not all review feedback has the same weight. Mixing them is how code reviews become frustrating.

Requirements: "This SQL query concatenates user input — it needs parameterized queries to prevent SQL injection." Non-negotiable. Security, correctness, or reliability issues.

Suggestions: "This could be cleaner with a switch statement instead of if/else, but either works." The code is fine. You see an alternative that you'd prefer.

Nitpicks: "I'd name this variable userCount instead of count." Entirely stylistic. The code is readable either way.

Label them. "Nit: consider renaming..." or "Suggestion: this could also..." or "Blocking: this needs..." The author knows which feedback requires action and which is optional. Without labels, every comment feels like a requirement, and the author either addresses everything (even trivial nitpicks) or pushes back on everything (even valid concerns).

Praise What Works

Code review doesn't have to be exclusively about problems. When someone uses a clean pattern, writes an excellent test, or handles an edge case thoughtfully — say so.

"This error handling is really thorough. I like that you covered the timeout case — that's often missed."

Positive feedback is underused in code review and disproportionately effective. It reinforces good patterns (so they repeat) and makes the rest of the feedback easier to receive (people are more receptive to critique when they're also recognized for what they did well).

Receiving Reviews

Assume Good Intent

The reviewer isn't attacking you. They're trying to improve the code and share perspective. Even when the feedback feels blunt or wrong, start by assuming they have a valid reason and try to understand it.

Don't Take It Personally

The code is being reviewed, not you. A suggestion to restructure a function is a suggestion about the code, not a judgment about your abilities. This is easier said than felt, but it's the essential mindset for productive code review.

Explain Your Reasoning

If a reviewer suggests a change and you disagree, explain why. "I considered that approach but chose this one because of X constraint." This turns the review into a design discussion rather than a disagreement. Often, the reviewer didn't have context you have — and providing it resolves the conflict.

Accept That Different Isn't Wrong

If a reviewer suggests an alternative approach that's equally valid — just different from yours — consider accepting it. Not because they're right and you're wrong, but because code review is a collaboration and incorporating others' perspectives builds shared ownership.

If both approaches are truly equivalent, it doesn't matter which one wins. What matters is that the team is aligned and the conversation was productive.

Team-Level Review Practices

Everyone reviews. Not just senior engineers. Junior engineers reviewing senior code learn patterns and develop judgment. Their questions often reveal assumptions the author made that aren't obvious.

Timely reviews. A PR waiting 3 days for review blocks the author and creates context-switching when the review finally happens. Target same-day reviews for small PRs, next-day for larger ones.

Small PRs. The most effective review practice isn't a review practice at all — it's a PR practice. Small, focused PRs (under 400 lines) get meaningful review. Large PRs get skimmed.

Automate what can be automated. Linting, formatting, type checking — these should be CI checks, not review comments. Don't waste human review time on things a computer can enforce.

Key Takeaway

Code review teaches when reviewers explain the why behind suggestions, ask questions before making statements, distinguish requirements from opinions, and recognize what's done well. Reviewers and authors both benefit when the process is a conversation rather than an inspection. Label feedback by weight, keep PRs small, review promptly, and automate the mechanical checks so human review focuses on design, correctness, and knowledge sharing.