Mastering Code Reviews | Article 6: The Force Multiplier — Mentoring Through PRs

As a seasoned Java engineer, I’ve realized that my time is the most expensive thing the company has. If I spend the next five years catching the same “N+1 query” or “Transaction” mistakes in every Pull Request, I have failed.

A junior dev uses the PR to get their code merged. A senior dev uses the PR to build better developers.

Here is how I use the code review as a “force multiplier” to scale my knowledge across the entire engineering org.

1. Don’t Just Give the Answer—Give the “Why”

If I see a dev using a parallelStream() for a simple database call, I don’t just say, “Don’t use parallelStream here.” That fixes the code, but it doesn’t fix the dev.

The Seasoned Move: I explain the cost. “I’d avoid parallelStream here because it uses the common ForkJoinPool. If this service gets hit with high traffic, you might starve the rest of the app for threads. Check out [this link] on how JVM thread pools work.”

2. The “Ask, Don’t Tell” Strategy

If you tell a dev what to do, they follow instructions. If you ask them a question, they learn to think.

Junior: “Change this to a Set.”
Senior: “I noticed we’re doing a lot of lookups in this list. What would happen to performance if the user had 10,000 items instead of 10? Is there a better data structure for this?”

3. Praise the “Senior” Moves

We are very quick to point out mistakes, but we rarely point out growth.
If I see a junior dev correctly handle a complex exception or write a particularly clean unit test, I leave a comment: “This error handling is great—it makes the service much more resilient. Nice work.”
This reinforces the exact “Senior-level” behaviors you want the team to repeat.

4. Create “Paved Roads” (Internal Documentation)

If I find myself explaining the same Java concept (like how @Transactional works in Spring) more than three times, I stop.

The Seasoned Move: I write a one-page “Internal Guide” or a “Best Practices” doc in our Wiki. From then on, my PR comment is just: “Hey, we have a specific pattern for this to avoid deadlocks. Check out the doc here: [Link].”

5. Know When to Take it Offline

If a PR has more than 15-20 comments, stop typing. The PR is no longer a “review”—it’s a “conflict.”

The Move: I’ll say: “Let’s jump on a quick Huddle/Zoom for 10 minutes to walk through this.” You can teach more in a 10-minute conversation than in 50 back-and-forth comments.

Why this matters

As a Staff or Principal Engineer, your value isn’t measured by how many lines you write, but by your leverage.

Scaling: If you teach five juniors to avoid N+1 queries, you’ve effectively multiplied your impact fivefold.
Efficiency: Mentorship reduces the “re-work” loop. Better code coming into the PR means faster approvals and less frustration.
Culture: It builds a “Learning Organization” where people aren’t afraid to make mistakes because they know they will get constructive guidance, not just criticism.

The Bottom Line

The mark of a truly seasoned engineer isn’t a “perfect” codebase. It’s a team that no longer needs you to tell them how to write one. When you use the PR as a mentorship platform, you aren’t just shipping code; you are shipping a stronger engineering culture.

In the final article, we will move from mentorship to the psychology of the review—learning how to separate the engineer from the logic.