These Junior Developers SUCK! They Just Don't Understand My Code!

Transcript is auto-generated and may contain errors.

Hey folks, I'm just headed to the office here on Wednesday morning. We're going to go to experience dev subreddit and the topic is about getting juniors to review PRs and uh making that more effective. So the context that this poster had was that um they're talking about some challenges where there's more junior people on the team and getting them to be effective with reviewing poll requests. and they said that like it's like uh you know they're not talking about their team like negatively or anything like that. They actually say like I adore working with them, but they're saying it's kind of problematic like it's turning into things taking ages to get reviewed. And um they had to I guess go back and edit their post to put a disclaimer in. I didn't read through the comments but people must have been saying well must be that your code is too complicated.

That kind of thing. And um they're like look it's not we're not talking about like code complexity. It's more like um it's almost like uh and I don't have a ton of experience in frontend work but they were saying like the more junior developers like know some React concepts but they don't know like some more like straight up like just working with JavaScript concepts. And so what ends up happening is you have people on the team that it's almost like they don't have enough technical depth to uh to start picking things apart. And like this this happens to me even so I've been programming for over two decades and there's like when I'm put onto C++ reviews there's stuff like I don't program in C++. I have before. I've written code in C++. I've reviewed lots of C++ code. um com compared to like how I if I'm programming anything, it's not in C++.

It is not my my strength. I don't spend enough time in it to be considered a strength. So, there's stuff that if I'm seeing it in C++, I might go like I don't I don't know or like I don't have a good uh perspective on that. Like it might be something that if I'm reading the way that my brain will approach it is like I can rationalize what's going on and like checks out like checks out enough that I can I think I can follow along with this. But there's some stuff in like I'll give you a very very brief example literally from last night was reviewing a poll request uh from one of my principles pretty straightforward change and um I happened to look at part of it and the code was like accessing there's like a property and it was accessing a a

backing field but what was happening was it must have been like a copy paste error or something and the the backing field was being recreated on every property access and like so I don't know enough about the domain like I've not had to do that type of change before that he was doing u but because I know about C programming C a lot and I understand what's going on with like a property in a backing field like that I'm going it seems pretty suspicious to me that we would be doing that like if usually you have a property and you're accessing a like some state that's been created before and you're reusing it, not recreating it every time. Usually, if you needed something like that, you would have a method instead. Property is kind of just like syntactic sugar for this, but you would use a method to kind of indicate like we are creating a new thing, not getting something that exists because it's not getting something that exists, it's making a new one.

So I have enough context just from working in C to understand and like and say like hey like you know I noticed this like just double-checking and sure enough it was a an accident like he actually in a previous iteration I guess like in his comment back to me he was like oh crap like I I uh made a note to go fix that and thought I did but seems like I you know pushed it back up without actually um you know fixing that part specifically. So he's a good catch, right? Small little thing, but just because I have enough knowledge in C, I'm able to catch something like that in something like C++ that uh that that style, that type of thing might have gone completely unnoticed by me. So I guess like when we have these types of scenarios on teams, because this person's asking like how do we make this better?

This is the kind of thing like again I guess it a lot of the time it almost goes ignores or ignored or unnoticed combining too many words into one and like this is part of software engineering in teams right it's not purely about just writing code and you know shipping features this is the type of thing where you got to slow down to be able to go faster and that probably means in this case you got to spend time with the more junior people and help educate them on this stuff. And like you could argue, well then the solution is just to bring on people with more experience, but like where did those people learn, right? Like there has to be some learning built in. There has to be knowledge transfer. And it sounds like to me that right now based on what this person's saying is there's a gap in in skill on the team.

And that's that's okay, right? But like the gap in skill doesn't just get better magically. And it doesn't get better if you like avoid it. And I'm not suggesting that this person is avoiding it. I think that they're actually taking some of the right steps to go like, "Okay, I observe this. This is something that I think has to change, but I'm not exactly sure how. Like what do I do about it?" But I think this is the kind of thing where it's like slow down to go fast, right? So, I think one of the I'm going to like overgeneralize here, but one of the common mistakes I see with this kind of thing, again, not suggesting this person is doing this. I'm just speaking in general. One of the common mistakes I see is that when people see a scenario like this and they go, "Okay, well, this is becoming a bottleneck.

It's slowing down." They go, "How do we avoid it?" because that's a more of a short-term kind of thing like there I feel a pain well how do we avoid this pain right like okay so you might I'm just making this up but like in this case it might be okay well the juniors are slowing me down when I need them to review this stuff so like what if I get more senior people to review like what if I stop putting the juniors on and I can go like maybe there's even a person from a different team that because they know JavaScript a lot better they'd be able to help review these types of things better. That might might not be a terrible idea in terms of getting other, you know, perspective and feedback. So, I'm not saying like, no, you aren't allowed to add other people, but what that's not going to fix or improve is the fact that you have juniors on the team that don't know this stuff well.

So, like I don't I don't think that the solution long term is to to avoid. And uh I'll give you like another sort of parallel to this because it's a theme, right? I'm not just talking about it from the perspective of pull requests and code reviews. I know that's the topic we're going through, but this avoidance type of thing is uh sometimes it's conscious, sometimes it's not. And I think it comes up an awful lot in other areas. is I want to give you another one which is like uh and I've seen this literally across two teams that I've managed at Microsoft over the past 5 years and I'm saying that because it's not like oh it's one person's fault or this is just a rare case. I'm trying to give you this sort of like anecdotal evidence that this is uh unfortunately more common and a little bit more complex than it seems.

So in both cases that I want to talk through right now, I've had uh a pretty big split on teams between like really experienced people in the domain. So like principal level engineers or senior level engineers that have been in the team for a while and then really really new people. And that's because in both cases I was hired onto teams where uh they basically had headcount. So they could grow the team. They could bring on a manager, me in this case. And so they bring people on and hire a manager in at the same time to be able to kind of uh you know grow the entire uh team or in my case like feature crew or feature crews which are just like sub teams. So what happens is you have a lot of fresh eyes, inexperienced people in the area. Some of them might be brand new in their career, but certainly they're new to the area.

And then you have people that have been on the team for years who like, you know, they've been around the codebase for a long time. It's a live service. It's a platform. They're familiar with like some of the the quirks and like the legacy code and oh yeah, like this thing happens. you know, we don't like it, but like we know how to work around it. Like it's kind of a known uh like there be dragons kind of thing. So there's just like a lot of history and knowledge and like these things are really complex. Okay. So in these situations, what happens is like when we have stuff like live site incidents or people are on call, what ends up happening is that if you put someone who's brand new to this stuff at the front of that, they're like, "Well, I don't I don't know how to fix that.

I don't know. I don't have the history." But it's like a it's a fire that has to get put out, right? So like, how do we put the fire out? Well, who's the person who has all that experience? It's it's going to be one of the seniors or the principal engineers that have been around for years. So then you get those people to put out the fire, right? They're they're the experts. Get them to put it out. Okay, cool. Crisis averted. You know, day has been saved. Excellent. And then the next fire comes up. Uh well, I'm just I'm new. I don't know how to do it. Like it's a fire. It's got to get put out. And then you have people that jump in to put out the fire. And what happens is that the fires get put out. But over time, it starts to feel overwhelming.

And it feels overwhelming for a lot of people, but you have juniors that feel like, I don't know what the hell I'm doing. And like, I still don't know what the hell I'm doing even though I've had to be on call a few times. And then you have the more senior people who are like, I don't have time to do the that's like really important for what I need to be doing at my level because I'm constantly putting out fires, but like I need to put out the fires cuz the more junior people don't know. It's a very similar type of thing the from what we were talking about earlier, right? Before was code reviews and pull requests. I'm talking about putting out fires for live site stuff. But what's common across both of these is that if we avoid the discomfort of getting juniors to focus on things that are going to be challenging for them, they don't get better at it.

So that means when it comes to on call stuff, we need the juniors to struggle through it a little bit. Just a little. Not saying like you leave them in the deep end and you say tough luck, but like what you don't want to do is every single thing unless it's truly a fire like an oh kind of situation. You don't want to jump in and solve all the problems for them. You want to point them in the right direction, make sure that they're not stuck and say, "Go investigate. Go this way. And if you get stuck, come back. Let me know how far you got." And then you recalibrate them and you send them off again. Right? You need to time box this kind of stuff. I'm making it sound a little bit more like trivial than it is because it's not I'm not saying it's trivial or else I would have fixed this problem across two of my teams instantly.

It's not it's a non-trivial thing. But you need to be able to slow down to speed up. You need to take the time to let the people who need to skill up to go through, you know, go through the paces. They have to spend time looking up the information, understanding it. They have to spend the time troubleshooting. Like you can give them guidance. You can put together like uh TSGs for live sight incidents and stuff like that and it helps, but they need to go through it. they need to be the ones driving on those things because if they're not, that experience doesn't get built up. It's a very very very similar thing to when we're talking to even aspiring software developers, right? You have people that are like, I want I'm trying I want to break into the tech industry. How do I get in?

Like I've been reading all of these articles. I've been following all these tutorials. Yeah. But how much how much code were you writing? Were you building projects? Were you doing things? Or were you just kind of like watching? It's not that you can't learn from watching and reading, but you don't learn as effectively. It doesn't solidify as effectively when you're not doing. So to bring it all back to poll requests and code reviews, I would say if you feel like there are some uh knowledge and skill gaps on the team with the with the more junior folks like I would I would encourage you like uh that feeling like don't um don't hide from it if you're like crap like man this is feeling like it's a painoint like don't don't be silent about it. Don't say oh I guess we're screwed and like that's it.

Like I would I would pay attention to that. That's that's a real thing if you're feeling that way. But what's next? Like my suggestion is not to avoid because the avoiding thing and just saying, "Okay, well the juniors suck. I got to go find someone else to help with this." It doesn't fix the problem. It's a very short-term thing for your poll request in your code review. But the actual underlying thing that you need addressed is that you have juniors on the team that don't have that skill set yet. They will not get that skill set if you keep avoiding them. And again, I'm not saying this to this person that wrote this Reddit post. I I realize I'm getting a little bit passionate as I'm speaking about this. It's not aimed at them. This is more just like general, right?

So, like we don't want to avoid, but that means it's going to feel even slower cuz it's not like now you got to wait uh until they take the time to go understand it. you probably what you might need to do is carve out some extra time, have some sessions to go over stuff. This is where like I don't have a a good prescription for this kind of thing because I think it's going to be different for everyone. Um, one thing I I'm going to go back to the on call stuff cuz this is a very relevant thing for me even though the topic is poll requests, but for like on call improvements, like one of the things that we're trying is having more um like knowledge sharing sessions so we can have some of the subject matter experts walk through things. They're recorded. People can ask questions and stuff like that.

And that way, like if you're having an issue with something, you can go pull up one of these tech talks. It's kind of just like an internal YouTube video or like a live stream, right? And then you can go watch read um you know, read through the chat, see the notes and stuff and and have a better understanding of what's going on. So, that's one thing we're doing. Another thing we're doing is we're writing better documentation in our TSGs. But personally, I think the most effective thing that we could do, and we have a version of this, but I'd like to see another version. The version that we have in place is we do um a less frequent sort of like deeper dive to go walk through scenarios. So, it's kind of like take a scenario that's similar to something that happened or take a real incident that we had to go through and you have one of the subject matter experts walk through like here is how I go debug this.

Here's how I diagnose it. Here's how I, you know, have to dig deeper. Here's where I found a gap in some of like our documentation or um, you know, charts and and dashboards that we can look through. Uh, but here's how I figured that out. Here's how I took the next step and here's how I got to the root cause and the solution. So, it's a lot more in-depth and you go along with them. But the the thing that I don't love about that is that it's still like one person just kind of presenting because I think what needs to happen is that people need to go through the motions themselves. Now, if we could structure those conversations where it's like, "Hey everyone, go to this dashboard, click around, hey everyone, go do this." I think then that forcing them to drive and go through would be helpful.

But one of the things that I want to do is I want to and it doesn't it's not perfect by any means. I don't think it scales very well, but I would I want to volunteer myself for one of these sessions where I go drive. So, I want to and it's going to be awkward and embarrassing and like I'm going to look stupid and that's okay, but I want to go through like a live site incident where we have the subject matter expert who's able to like as I'm getting stuck and being like, I want to go look here. I want to look at this dashboard so I can take that information to go over here. I want them to like to be able to to observe and be like, well, no, that's not the right thing to do. And then I can be like, well, okay, like here's what I'm getting from the documentation.

So, it's good feedback for the subject matter experts on their documentation. It's uh good for me because I get to practice clicking through stuff. But the reason I'm saying it doesn't scale is because like the other people have to do it too still. So, I I think there's a lot of different things to try out, but I would encourage you like don't um you know, the meta point here is don't get into an avoidance mode. You kind of had to slow down unfortunately. Find ways to educate, get people to get hands-on and go through stuff. And that might mean for this person who's having some more uh you know issues with more junior people working through like some different JavaScript things like maybe schedule some talks. Go through some of these things more in depth. Go explain it. See if you can get people to in those sessions to write some simple code that's mirroring some of that so they can like they can step through it.

They can actually be hands-on with it. And like, yeah, that sucks because that's a lot of extra time and effort. I get it. But like, I think that's the kind of thing that needs to happen to speed up long term. Like that's addressing what the root cause is. Now, that might not be what the root cause is, but I'm I'm making an assumption here based on what this person's saying that there's like a skill or knowledge gap. So like work on that, right? This is what I said right near the beginning of this uh this talk was like this is the kind of stuff in software engineering that we often neglect cuz that's building up the team around you. Woo! Plastic on the road. Um, right. Like this person's goal and rightfully so as like I'm trying to get my checked in, trying to get this feature delivered or this bug fix delivered.

Like I get it. Like that is, you know, that is your goal. But the whole team's got to come along for the ride. So something to think about. Uh, I think I'm going to start repeating myself if I keep going any longer. But I hope that's helpful. That's my perspective on this kind of stuff and that's why I wanted to share with you that it's like I have some real lived experiences over the past 5 years at Microsoft. It's not unique to Microsoft but where we have these like situations where like we have to slow down to be able to speed up long term. So not unique to Microsoft, not unique to code reviews. This is I think kind of a situation where you have skill or knowledge gaps. So don't avoid it. So thanks for listening. Uh, if you have questions that you want answered, just leave them below in the comments or you can go to codemute.com.

There's a contact form. You can submit things anonymously. I'm happy to make a vlog entry and uh just kind of chat through it. And of course, I have other YouTube channels. So, if you want to learn C and go through some C programming tutorials and or learn about using AI tools to write software, you can check out Devleader. There's a dev leader path to tech where you can check out resumeé reviews or submit your own resume to be reviewed. And then uh the Devleer podcast which is another YouTube channel where I interview software engineers and of course I do a live stream there every Monday 7:00 p.m. Pacific and the topics are often pulled from code commute. So, for example, like if this uh particular video gets a lot of traction compared to the rest for the week, then I will do my newsletter article on that at weekly.devleer.ca followed by the live stream.

Uh you can check that out on the Devleer podcast. So, thanks so much for watching. I will see you next time. Take care.