These Junior Developers SUCK! They Just Don't Understand My Code!
You've been there. You submit a pull request, and it sits there for days. The junior developers on your team don't seem to catch the issues. They're not providing meaningful feedback. Things are taking ages to get reviewed, and you're frustrated.
But here's the thing: avoiding junior developers in code reviews doesn't fix the problem. It just kicks the can down the road.
Disclaimer: Yes! This was written by AI based on all of the content discussed in the video above, by yours truly, Nick Cosentino, while filming on Code Commute. I have ensured that it represents my thoughts and perspectives.
The Real Problem: Skill Gaps, Not Complexity
I came across a post on the ExperiencedDevs subreddit where someone was struggling with exactly this. They weren't complaining about their team—they actually said they adore working with them. But there's a real problem: junior developers know React concepts, but they don't have deep JavaScript knowledge. They don't have enough technical depth to effectively review code.
This isn't about code complexity. It's about knowledge gaps.
And honestly? This happens to everyone. I've been programming for over two decades, and when I'm reviewing C++ code, there's stuff I just don't know. I've written C++ before. I've reviewed C++ code. But it's not my strength. I don't spend enough time in it.
So when I see something in C++, my brain might rationalize it: "Yeah, that checks out. I can follow along with this." But I might miss subtle issues that someone with deep C++ experience would catch immediately.
A Real Example: The Backing Field Bug
During a recent code review, I was reviewing a pull request from one of my principal engineers. Pretty straightforward change. But I happened to look at part of it, and something seemed off.
The code was accessing a property, and it was accessing a backing field. But what was happening was the backing field was being recreated on every property access. That's suspicious. Usually, you have a property that accesses state that's been created before—you're reusing it, not recreating it every time.
I don't know enough about the specific domain he was working in. I haven't had to do that type of change before. But because I know C# programming well, I understand properties and backing fields. I was able to catch something that might have gone unnoticed otherwise.
It turned out to be a copy-paste error. He had made a note to fix it in a previous iteration, thought he did, but pushed it back up without actually fixing that part. Good catch, right? Small thing, but important.
Slow Down to Speed Up
This is part of software engineering in teams. It's not purely about writing code and shipping features. You have to slow down to be able to go faster.
That probably means spending time with the more junior people and helping educate them. You could argue, "Well, then the solution is just to bring on people with more experience." But where did those people learn? There has to be some learning built in. There has to be knowledge transfer.
If you have a skill gap on your team, that's okay. But the gap doesn't get better magically. And it doesn't get better if you avoid it.
The Avoidance Trap
One of the common mistakes I see—and I'm not suggesting the Reddit poster is doing this, I'm speaking generally—is that when people see a bottleneck, they ask: "How do we avoid it?"
That's a short-term solution. "The juniors are slowing me down, so what if I get more senior people to review? What if I stop putting juniors on reviews? Maybe there's someone from a different team who knows JavaScript better."
That might not be a terrible idea for getting other perspectives. But what that doesn't fix is the fact that you have juniors on the team who don't know this stuff well. They will not get that skill set if you keep avoiding them.
The On-Call Parallel
I've seen this exact pattern across two teams I've managed at Microsoft over the past 5 years. In both cases, I was hired onto teams that had headcount to grow. So you end up with a split: really experienced people (principal or senior engineers who've been around for years) and really new people (brand new to the area, maybe brand new to their careers).
When live site incidents happen, who puts out the fire? The person with all the experience. The expert. Crisis averted. Day saved.
Then the next fire comes up. "I'm new, I don't know how to do it." So the experts jump in again. The fires get put out, but over time, it starts to feel overwhelming.
Juniors feel like: "I don't know what the hell I'm doing, even though I've been on call a few times."
Seniors feel like: "I don't have time to do the work that's really important for my level because I'm constantly putting out fires."
If we avoid the discomfort of getting juniors to focus on challenging things, they don't get better at it.
What Actually Works
When it comes to on-call stuff, we need juniors to struggle through it a little bit. Not saying you leave them in the deep end, but you don't want to jump in and solve all the problems for them either. Point them in the right direction. Make sure they're not stuck. Say: "Go investigate. Go this way. If you get stuck, come back. Let me know how far you got."
Then recalibrate and send them off again. Time-box it.
You need to slow down to speed up. Take the time to let people who need to skill up go through the paces. They have to spend time looking up information, understanding it, troubleshooting. You can give guidance. You can put together TSGs (troubleshooting guides) for live site incidents. But they need to go through it. They need to be the ones driving.
This is very similar to when we talk to aspiring software developers. "I want to break into tech. I've been reading articles, following tutorials." Yeah, but how much code were you writing? Were you building projects? Were you doing things? Or were you just watching?
You don't learn as effectively when you're not doing. It doesn't solidify as effectively when you're not hands-on.
Practical Solutions for Code Reviews
So, back to pull requests and code reviews. If you feel like there are knowledge and skill gaps on your team with the more junior folks, don't hide from it. Don't be silent about it. Pay attention to that feeling—it's a real thing.
But don't avoid it. That means it's going to feel slower because now you've got to wait until they take the time to understand it. You might need to carve out extra time, have some sessions to go over stuff.
Here's what we're trying for on-call improvements, and it applies to code reviews too:
Knowledge sharing sessions: Have subject matter experts walk through things. Record them. People can ask questions. If you're having an issue, you can pull up one of these tech talks—like an internal YouTube video.
Better documentation: Write better TSGs and documentation. But documentation alone isn't enough.
Hands-on deep dives: Take a real scenario or incident, have a subject matter expert walk through: "Here's how I debug this. Here's how I diagnose it. Here's how I dig deeper. Here's how I got to the root cause."
But here's what I don't love about that: it's still one person presenting. People need to go through the motions themselves.
I want to volunteer myself for one of these sessions where I go drive. It's going to be awkward and embarrassing, and I'm going to look stupid. That's okay. I want to go through a live site incident where the subject matter expert can observe. As I'm getting stuck, they can say: "No, that's not the right thing to do." Then I can say: "Well, here's what I'm getting from the documentation."
That's good feedback for the subject matter experts on their documentation. It's good for me because I get to practice. But the reason it doesn't scale is because other people have to do it too.
For Your JavaScript/Code Review Situation
For the person having issues with junior people working through different JavaScript things, maybe schedule some talks. Go through these things more in depth. Explain them. See if you can get people in those sessions to write some simple code that mirrors some of that, so they can step through it. They can actually be hands-on with it.
Yeah, that sucks because that's a lot of extra time and effort. I get it. But that's the kind of thing that needs to happen to speed up long term. That's addressing the root cause.
The Meta Point
This is the kind of stuff in software engineering that we often neglect: building up the team around you.
Your goal is to get your code checked in, get this feature delivered, get this bug fix delivered. I get it. That is your goal. But the whole team's got to come along for the ride.
Don't get into an avoidance mode. You kind of have to slow down unfortunately. Find ways to educate. Get people to get hands-on and go through stuff.
I have real lived experiences over the past 5 years at Microsoft where we've had these situations where we have to slow down to be able to speed up long term. This isn't unique to Microsoft. It's not unique to code reviews. This is a situation where you have skill or knowledge gaps.
So don't avoid it.
Key Takeaways
Skill gaps don't fix themselves: If junior developers don't have the technical depth to review code effectively, avoiding them won't solve the problem.
Slow down to speed up: Invest time in education and hands-on practice. It feels slower in the short term but pays off long term.
Avoidance is a trap: Getting senior people to review instead of juniors might solve the immediate problem, but it doesn't help juniors grow.
Hands-on learning is essential: People don't learn effectively just by watching or reading. They need to do, to struggle, to practice.
Build up your team: This is the kind of software engineering work we often neglect, but it's critical for long-term success.
If you're dealing with this situation, don't hide from it. Don't be silent about it. Pay attention to that feeling. But don't avoid it—address the root cause by investing in your team's growth.