Different Roles, Different Review Goals

Code Review, Communication, Quality

Why Code Review Means Something Different to Everyone — And Why That’s a Strength

This article is part of my code review series. It focuses on why code review means something different to everyone — and why that’s a strength.

Code review isn’t a uniform task. How you approach it depends on your experience level, your role in the team, and your familiarity with the system. That’s not a problem — it’s a feature.

As a lead or architect, I’ve seen how developers at different levels focus on different things during a review. I try to foster a culture where all of those perspectives are welcome — because it’s the discussion that drives long-term quality, not just a checklist.

A Note on Labels

I use terms like junior and senior loosely — to refer to less or more experienced developers. But these labels often fall short. Experience is only part of the equation. Mindset, curiosity, and communication skills play a major role in determining how effectively someone contributes during a review.

Junior Developers: Focus on Understanding — and Offer Fresh Perspective

Juniors often find code reviews intimidating. They’re unsure what to say, or worry they’ll say something wrong.

But that uncertainty? It’s exactly what makes their feedback valuable.

If a piece of code is hard to understand, it often means one of two things:

It’s an opportunity to explain and share knowledge, or
It’s a sign that the author should reconsider the code’s clarity

If a junior doesn’t “get it,” odds are someone else won’t either.
Even without deep experience, juniors can spot things that don’t feel right — and that often leads to meaningful discussions.

There’s another angle that’s often overlooked:

Juniors are frequently more up to date with new tools, frameworks, or patterns.

While experienced developers tend to rely on proven approaches, newer team members may bring in fresh insights. Some of these may be trends — but others can lead to real improvements.

I’ve worked on several projects where a comment from a junior didn’t just improve the PR — it changed the way I work. You’re never too senior to learn something new.

What I encourage:

Ask questions like:
“What’s the purpose of this function?”
“Could we use [X] here instead?”
Don’t assume your lack of experience means your ideas lack value.
And as reviewers — stay open to learning, no matter how senior you are.

Senior Developers & Leads: Focus on Structure and Risk

More experienced developers often focus on:

Poor abstractions
Risky patterns
Missed edge cases
Performance or security concerns

But that doesn’t mean they should only give top-down feedback.
Their role should be to support maintainability, coach where needed, and help set expectations — not to control the outcome.

What I encourage:

Offer rationale with every suggestion:
“This might be harder to test later because…”
Lead by example — but leave room for other perspectives.
Use review as a teaching opportunity, not just a gatekeeping step.

Architects & Tech Leads: Focus on Alignment and Fit

FrFrom an architectural point of view, reviews are about system impact and long-term coherence:

Does this change follow our guiding principles?
Is this the right place in the system to solve this problem?
Are we unintentionally introducing coupling or duplication?

Often, I’ll focus less on specific implementation details and more on:

Clear boundaries and ownership
Whether the change fits existing abstractions or policies
Whether the design still works when put into practice

But even at this level, I still ask questions.

It’s a conversation, not a veto.

A Review Is Not a Judgement — It’s a Dialogue

Code is personal. People put effort into it. That’s why one of My key points for code reviews is:

It’s a conversation about the code, not the coder.

That’s also why I prefer questions over accusations — and why I welcome disagreement. If everyone always agrees, you’re probably missing something.

When someone asks, “Why this way?” — that’s the start of a discussion.
When someone says, “This feels wrong,” — that’s the start of an investigation.

Not every comment needs to lead to a change. But the dialogue improves the team’s shared understanding — and that has long-term value far beyond this PR.

Closing Thoughts

Different roles bring different review priorities — and that’s what makes code review effective.
It’s not just a final check. It’s how a team learns, aligns, and matures together.

Encourage questions. Embrace discussion. And remember: if someone — junior or senior — doesn’t understand your code, it might not be their fault.
It might be your opportunity.