Code Reviews That Grow Engineers: Turning Pull Requests Into a Learning Engine

Most teams treat code review as a quality gate: a final checkpoint where someone looks for bugs before code reaches the main branch. That's valuable, but it's only half of what reviews can do.

Done well, code review is one of the most effective mentoring tools a software team has. It happens every day, it's grounded in real work, and it spreads knowledge across the whole team. Done badly, it becomes a bottleneck, a source of friction, and a reason talented people stop enjoying their work.

Here's how I approach code reviews so they improve both the code and the engineers writing it.

Be Clear About What Reviews Are For

Before discussing technique, a team should agree on purpose. In my view, good code reviews aim to:

1. Catch defects and risks such as logic errors, security issues, and performance traps.
2. Keep the codebase consistent and maintainable for the next person who reads it.
3. Share knowledge so no part of the system is understood by only one person.
4. Grow engineers by exposing them to different approaches and reasoning.

What reviews are not for: enforcing personal style preferences, demonstrating seniority, or redesigning a feature after it's been built.

Automate Everything a Machine Can Check

Humans are expensive reviewers of formatting and simple rules. Every comment about spacing or naming conventions is attention not spent on design and correctness. In .NET, a few tools remove most of this noise:

• An .editorconfig file with agreed conventions.
• Roslyn analyzers (built-in .NET analyzers, plus others your team agrees on).
• dotnet format running in CI.
• Treating important warnings as errors.

<!-- Directory.Build.props -->
<PropertyGroup>
  <Nullable>enable</Nullable>
  <AnalysisLevel>latest-recommended</AnalysisLevel>
  <EnforceCodeStyleInBuild>true</EnforceCodeStyleInBuild>
  <TreatWarningsAsErrors>true</TreatWarningsAsErrors>
</PropertyGroup>

# In your CI pipeline
- run: dotnet format --verify-no-changes
- run: dotnet build --configuration Release
- run: dotnet test --no-build --configuration Release

Once the pipeline handles style and basic correctness, reviewers can focus on what really needs a human.

Keep Pull Requests Small

The single biggest improvement most teams can make is reducing pull request size. A 50-line change gets a thoughtful review. A 2,000-line change gets skimmed and approved with "LGTM."

I encourage engineers to:

• Split work into reviewable increments: refactoring in one PR, new behaviour in the next.
• Use feature flags so incomplete features can be merged safely.
• Write a clear description: what changed, why, how it was tested, and where the reviewer should focus.

A good PR description is itself a skill worth developing. It forces the author to explain their reasoning, and that often reveals gaps before anyone else does.

Review the Right Things, in the Right Order

When I review, I work from the big picture down:

1. Does this solve the right problem? Is the approach sound?
2. Design: are responsibilities in the right place? Does it fit the architecture?
3. Correctness and edge cases: null handling, concurrency, error paths, cancellation.
4. Security and performance: input validation, authorisation, N+1 queries, unbounded loops.
5. Tests: do they cover the important behaviour, and would they catch a regression?
6. Readability: naming, clarity, and comments where intent isn't obvious.

Here's the kind of issue worth a human comment because analyzers won't always catch it:

// Loads every order into memory before filtering
var recent = (await db.Orders.ToListAsync(ct))
    .Where(o => o.CreatedAt > cutoff)
    .ToList();

// Filters in the database and returns only what's needed
var recent = await db.Orders
    .Where(o => o.CreatedAt > cutoff)
    .Select(o => new OrderSummary(o.Id, o.Total))
    .ToListAsync(ct);

A comment explaining why the second version is better ("this pushes filtering to SQL and avoids materialising the whole table") teaches something that will be applied to dozens of future queries.

Write Comments That Teach

The difference between a review that frustrates and one that grows someone often comes down to wording. Some habits I recommend:

• Explain the reasoning, not just the instruction. "Use AsNoTracking() here" is a rule; "this is a read-only query, so AsNoTracking() avoids change-tracking overhead" is a lesson.
• Ask questions when you're unsure. "What happens if this list is empty?" invites thinking and sometimes reveals the author already handled it.
• Label the weight of each comment. Prefixes like blocking, suggestion, nit, and question tell the author what must change and what's optional. Conventions such as "Conventional Comments" formalise this.
• Comment on the code, not the person. "This method is doing a lot" lands very differently from "you made this too complicated."
• Point out what's good. Recognising a clean abstraction or a thorough test reinforces the behaviour you want to see more of.

Make Reviews Two-Way

Reviews shouldn't flow only from senior to junior. Junior engineers learn enormously by reviewing senior engineers' code, and they often spot unclear naming or missing documentation precisely because they lack context. I encourage everyone on the team to review, and I make a point of thanking people when they catch something in my own pull requests.

For complex or contentious changes, move the conversation to a call or a pairing session. Ten minutes of discussion can replace a thread of twenty comments and avoids misunderstandings that text tends to amplify.

Set Team Norms for Speed

A review that sits for three days blocks work and encourages bigger PRs, which then take even longer to review. Agree on norms such as:

• A target turnaround time for a first response (for example, within one working day).
• Small PRs are reviewed first.
• The author is responsible for driving the PR to completion; reviewers are responsible for timely, clear feedback.
• Disagreements that can't be resolved quickly are escalated to a design discussion, not fought out in comments.

Use Reviews to Spot Coaching Opportunities

As a lead, reviews give me a real-time view of where each engineer is in their growth. If someone repeatedly struggles with async patterns, testing, or EF Core performance, that's a signal to offer pairing, a short knowledge-sharing session, or a targeted learning resource. Recurring comments across the team are a sign that a guideline, analyzer rule, or template is missing.

Final Thoughts

Code review is far more than a gate before merging. It's a daily opportunity to share knowledge, raise standards, and help every engineer get better. Automate the trivial, keep changes small, review from the big picture down, and write comments that explain why. Do that consistently, and your pull requests become one of the most powerful learning tools your team has.