These Junior Devs Just Don't Get It!

Dev Leader Weekly 110

Dev Leader

Sep 20, 2025

TL; DR:

Stop the blame game
Timebox efforts and invite curiosity on reviews
Check out the livestream (or watch the recording) on Monday, September 22nd, at 7:00 PM Pacific!

Empowering Junior Developers on Reviews

If you have juniors on your team, you may have run into this:

Pull requests piling up
Reviews slowing down
... and everyone quietly frustrated

Is it just because your code is too complex? Maybe not. Should we point the finger at the junior developers and blame them?

Definitely not.

If you have junior developers on the team, it's entirely possible they just haven't learned about a lot of the things that are showing up in your pull requests. Nobody's fault. No blame. No finger pointing.

This is where leadership and patience REALLY pay dividends. If you slow down now to teach, you’ll go much faster later. I’ve seen this across multiple teams I’ve led at Microsoft and in my earlier startup days.

Let’s unpack why reviews can stall and how you can turn them into one of the most powerful growth loops for juniors. You can check it out on Code Commute as well.

And for those that haven't figured it out yet: The title of this issue is based on the Code Commute video I did, which is based on a Reddit post. We aren't here to tear junior developers down, we're here to make the entire engineering team better.

Why Juniors Might Be Struggling With Reviews

The problem you're running into with junior developers on your team might look something like this:

They understand framework patterns (React, ASP.NET, etc...) but miss raw language fundamentals.
They read files line by line instead of reasoning through program flow.
They don’t know the local quirks of the codebase (you know, the legacy stuff you aren't so proud of).
They’re afraid to ask what feels like “obvious” questions. Silence replaces curiosity.

The result? Reviews take forever. PR authors get frustrated. Juniors feel like they aren't adding value in the review process. Nobody wins.

Actionable Tip: Don't avoid putting junior developers on reviews. Name the gap out loud (in your own words, of course): “I know this looks overwhelming. That’s normal. Let’s focus on just one or two things per review until you build confidence.”

Let them know it's okay to ask questions. Let them know it's okay to not understand everything they're seeing. Invite them to be curious.

This will be a big theme for this entire discussion.

Pair Up, Step Back

This can work really well, especially if you are a team with junior developers working remotely. I'd recommend pairing for the start of a code review to set some context for the other developers who might need a bit more help to make sense of things. Here’s what that could look like:

The PR author explains the mental model and walks through the change.
Have the other developer(s) repeat back what they think some of the code blocks will do.
Together, you agree on two focus areas to look at in the review.

Remember for #2 it's not a goal to cross-examine people and put them on the spot -- it's an opportunity to invite people to try understanding, and getting some quick feedback so folks can be aligned.

After this, you stop. The junior developers can go off and finish the review async. It's a quick set of steps you can take to help them build confidence, align expectations, and saves hours of wandering if they're not even sure what they're supposed to be looking at.

Teach the Questions, Not Just the Answers

When junior developers feel stuck or lost on reviews, it's not strictly a matter of not understanding the code. This could be part of it, but it’s also often because they don’t know what to look for or what to ask about.

Give them a starter checklist:

What is the single responsibility of this change?
Where does state live, and who owns it?
What are the inputs and outputs at each boundary?
What could go wrong, and how would we know?
What parts of this change do I not understand at all?

This shifts their role from guessing to having some concrete things to consider. Some of these things are prompts that they can try to answer for themselves. If they can't figure it out or they aren't sure, it's a question they can add to the code review.

Curiosity is the muscle that grows into judgment. Asking curious questions can help them practice going through and trying to understand the code, and over time, they'll build up more confidence so they can start making recommendations.

Actionable Tip Get your junior developers a basic list of questions/prompts to have when they start reading code on code reviews. Have each of them come up with one (or more!) to add to their list. Follow up with them and see if it's helping spark curiosity for them when it comes to reviewing code.

Timebox and Escalate

Timeboxing is a great skill for everyone to practice, but it's especially helpful for junior developers. They may not have experience that provides a base level of expectations, so when they get stuck or feel like they're not making progress:

Have they spent long enough on their own to figure it out?
... Or did they spin their wheels for too long and should have asked for clarity sooner?

Set some expectations for them! If they're just getting started and there's extra capacity for them to read code to ramp up, you might do things more asynchronously. Don't put them on a path that will block reviews, but let them know they should spend up to X amount of time walking through code changes to understand them. If they have questions but other folks have already signed off on the review, make some time and space for them to follow up.

Find that balance that works well on your team -- and let them know this sort of thing will evolve over time as they gain more experience and more confidence.

The On-Call Analogy

I’ve seen this same pattern outside reviews. In live site incidents, the instinct is to shove the junior aside so a senior can put out the fire. It works in the moment, but it prevents learning. The next fire looks the same. And the seniors are forever chained to the pager.

It's a perpetual tax that keeps on growing for the more senior developers. They perpetuate the single point of failure because others aren't getting skilled up in those areas.

Reviews are no different. Don’t rip the keyboard away from them! Don't exclude them and only share reviews with the other senior dev who will sign off right away.

Get the junior developers set up with review tools (whatever it is you use for reviewing code), get them to set a timer when they're ready to start, and be ready to support them when they have questions.

If you invest here, you’ll see the compounding effect:

After a month*, juniors catch small but real issues.
After a quarter*, they restate flows and ask about trade-offs.
After a year*, they’re not “junior” anymore. They’re reviewers who strengthen the codebase and lighten the load.

(* your mileage may vary, but you get the idea)

This doesn’t happen if you route around them. It happens because you made space for them to learn inside the real work.

Final Thought

Code reviews aren’t just about shipping safer code. They’re about building better engineers.

If you treat them only as gates, you’ll resent the slowdown. If you treat them as classrooms, you’ll end up with a stronger team that ships faster than you imagined. It might feel a bit slower in the beginning, but if you set others up to learn and encourage their curiosity, you can support them through this growth.

The choice is yours: avoidance and short-term speed, or teaching and long-term acceleration. In my experience, teaching always wins.

We all started somewhere. Help make the next wave of developers even better.

Dev Leader Weekly