Are Junior Developers REALLY The Problem Here?

Transcript is auto-generated and may contain errors.

All right, folks. It turns out junior developers suck at coding. Okay, maybe not. Maybe maybe not in all cases, but we're going to experience devs subreddit to talk about this topic where someone is spending what they feel like is a little bit too much time trying to coach and mentor more junior person on their team and it seems like they're kind of hitting their limits and they're going, I'm not really sure what to do now. Um, and I wanted to talk through this cuz I think that it's relevant. I think that there's a bunch of different angles to look at here. And uh, before too many people get pissed off and start writing in the comments, I'm already thinking of the title for this one because apparently it's doing pretty well to to get people to click. But I don't think that junior developers suck at coding.

I don't think that's just a statement we can make. And I hope that if you are a junior and you've made it this far in the video that at least you'll give me a moment to talk through this because ultimately my goal is to help as many software developers as possible and that means helping juniors get into the software engineering roles and understand how to do better in their career. So uh no I don't think juniors suck at programming. In fact I think a lot of the time we uh suck at helping juniors. So, I want to talk about this and see what we can do uh in terms of balancing things out because don't get me wrong, uh it can be an awful lot of work, but that's the reality of it, right? It's going to be different in some cases. Some people are very self-sufficient as juniors.

Some need a lot more help and like it's situational. So, sometimes, in fact, a lot of the time, people really suck at trying to understand that and make sure that they can guide people what I would say is like an effective way. and they end up using more of like a cookie cutter approach whether you're a manager or you're a you know a more senior developer or you just happen to be a little bit more senior than the person that's being onboarded that you're trying to help. Um it's a it's a skill. I'm certainly not perfect at it. I just have a lot of years of trying to navigate it. So can draw on different experiences. But the reality is like it's not going to be a cookie cutter approach that you can use the same exact thing with everyone. I think there's some common things to look at and I think that we can kind of navigate that together.

But uh I was reading some of the comments. I don't always do this. Sometimes I do cuz I'm curious. Today I was a little I feel like a little disappointed. Um and when I say that it's not because like you know what's right and what's wrong. It's not really for me to decide, but a little disappointed in that like people weren't having uh I guess like what I would hope to be a little bit more empathy and you know people being like sounds like the juniors got to go on a pip get them like talk to your manager. They should probably get fired if they don't have the skills and it's like okay like uh hold your horses. Um I don't think that we can jump right to that. So, um, to kick things off, this is going to be an expectation of probably most software developers at some point where they do have to help mentor more junior people.

And that's a spectrum on its own, right? That could be people that are brand new early in career that need mentorship. That could just be someone that is more junior than you that happens to be new to the team. All sorts of things. They could even be just mentoring your peers, right? They might, you know, be the same level as you. They could even be a higher level, but if they're coming in into an area that you have some expertise in, that could be an opportunity for you to kind of coach and mentor them through that. Uh coaching and mentoring can look different, right? Could be talking about technical things. It could be uh related to like uh how you've been coordinating working with partner teams or other individuals. Uh could be career suggestions especially for more junior people. Could be anything, right? This can come in all different shapes and sizes.

In this particular case, uh, this Redditor was talking about code. So, I think we're going to try to focus on that. But I just wanted to kind of open up that door to get you thinking that when, uh, we talk about mentorship that really can look, uh, you know, very different and take many different shapes. So, this individual is more senior. They have a junior. And what they were saying was that seems like the junior is producing a lot of AI code which they're not necessarily directly complaining about. They're saying it's uh you know company allows it. There's a he listed off some tools that are like totally cool to be used at work. So you know sounds like the junior's probably leaning into that. And at this point, I'm like, in my mind, I feel like if you're not at least trying to use AI tools in some capacity, I'm not saying necessarily for everything, it's a tool, figure out the right way, right place, and time to use it.

But if you're not incorporating that in some capacity into your workflows, I feel like there's a missed opportunity there regardless of your level. Just might change what you're doing. So, he's not saying like, "Oh, this junior's using AI, therefore the world is ending. I can't stand this." It's more like, "Hey, that's some background." And it seems like he's spending a lot of time not just like on domain knowledge, but like what feels like some pretty simple coding logic and like on repeat. So the poster mentioned that they're spending time doing that and some of the things that they suggested are like you know pointing them towards like free resources online to go learn. I've historically I've had you know early in career junior engineers especially like I do a lot of C programming.

They might say like, "Hey, I don't know C#." Like they'll ask like, "Can you recommend resources for me to go learn?" And it's kind of funny because like I have like that's what I do is like aside from this channel, I have other channels where literally I make C content to teach people, but like I don't think that that is like I don't think that that should be the the core of your learning if that makes sense. And I'm saying that as a content creator, I literally like make YouTube videos. I sell courses on like how to learn C. I don't think that that should be the foundation core part of your learning. I think the foundation and core should be you spending time writing code in that language. I make tutorials because if you're stuck on something or you want to see a different way to do things, like walk through the tutorial, right?

You can see how I've approached it. It's just a different, you know, way to to think through things. But I don't think that that's the best. Personally, I don't think that's the best way that people will, you know, learn and understand how uh to navigate programming. And I would say the same thing about courses, right? Like some people it helps them because they have sort of like this uh what's the right word for this? They're like there's a commitment like you spent money and you're like okay so like I spent the money I gotta like I gotta get my money's worth out of this thing. So that way they feel like okay like I got to go spend time on the course. I I've already spent the money. Accountability I think is the word I want. I've talked about this before when I was doing more like bodybuilding.

It was like I still hired a coach not because I was like, "Oh, he's going to show me the craziest things I had no idea about," but more like I have accountability to this person and that's going to be like what really keeps me going. So, this engineer who's suggesting these things, I don't think that they're terrible ideas. I just don't think that they're going to be the thing that helps. Now, what's challenging in situations like this, um, there's a bit of a pattern for this topic and some of the other things I've made videos about where you'll hear me say like unfortunately it probably means slowing down to speed up. And what I mean by that is like when you try to solve this type of problem or this this situation, right? Like you're trying to make it better.

One of the things that people want to do is they're like, "Okay, well, how do I minimize the time that I'm spending on this, right?" Like that's ultimately the thing that's bothering you is like uh and at least from this person's example, it's not like, "Oh, this person sucks. I hate them." It's like, "It's just taking too much of my time, man. Like, I got other stuff to do and this is really chewing into it. I'm trying my best to help." Now, if you're trying to get some of your time back, it seems like the answer is like, well, how do I answer the question the fastest? But the problem, like the more you move in that direction is the more of a dependency that person has on you.

So I think personally you want to shift as much as you can into like like basically teaching people how to go problem solve on their own which I'm not I'm not trying to say like there that's the answer it's so easy that's not easy but I think that moving in that direction is the thing that helps the most right and if you think about it right if you are more a senior and you're like a that's going to be a pain in the though, like that. How am I going to do that? That's going to be even more work. I already don't have time. Think about this, right? Um, you've probably heard from junior developers that they're like a lot like a lot of junior developers, especially working remotely, they're like, I don't want to reach out to the more senior person. I feel like I'm bothering them, right?

Like I'm getting stuck and like I know they said it's okay to reach out for help, but like I just feel bad I'm bothering them and it's all wait like I don't want to. And you can if you talk to more junior developers, you'll hear this kind of pattern coming up. Again, I'm making generalizations here. There's always exceptions. And so really, they're already kind of feeling like, I don't want to be in a position where I have to come to you to get questions answered. They don't want that. It's awkward. They're like, I I think I'm bothering you. Like, I just want to be able I want to be able to do this. So I'm I'm saying this because as senior developers I'm trying to remind you like they don't the more junior people don't want to create that dependency on you.

So if you are trying to just minimize the amount of time in the short term unfortunately it does create more and more of a dependency because you're not you're unfortunately not teaching them how to come up with the answer. You're you're giving them an answer. they get unblocked and they can continue. But if they're not able to pick up on those patterns just from you showing them the answer, and I feel like unfortunately a lot of us are not great at that, maybe as we become more senior and we've seen a lot of patterns, we can start applying things in similar ways more effectively. But I know for me, like personally, I've been programming for over 20 years and I've been in my career like including my internships like 15 years now. I don't learn that way. Like if you tell me things, I'm like, "Okay, I might it might stick.

Might need to hear it a couple times. I need to do something with it." Once I do something with it, it really starts solidifying my understanding. So, I highly recommend in situations like this, especially if you're coaching people through logic, like I don't think there's anything wrong with taking some time. And I I say this not like you have infinite time. That's not my point. But, uh I don't think there it's like the wrong thing to do to spend time and like walk people through some stuff that might feel like very, you know, primitive or you might expect that people know this. The reality is that like I don't know I I know people I went to university with for 5 years. We had a 5-year program and they had internships and I guarantee you when they graduated after that I guarantee you some of these people would even tell you I did not know how to program or they didn't feel comfortable doing it.

One of literally one of my friends, one of my classmates, literally was very very good at math. If I were to ask him today, he would tell you not when he graduated, not a programmer. And he had to really go like try to study and memorize like lead code style questions and got a job out of university, but he was like, I don't like I don't consider myself a programmer. So we have these expectations of people. They are very new in their career. Of course, we would like to make sure it would be ideal if people came in and they already knew everything, but it's just not the reality. And if you have like if you're really concerned about that, perhaps go talk to people that are doing hiring. Like if that's your biggest concern, right? If that's like you have a stream of people coming in and it's like holy like we're spending so much time going over basics, we need to adjust for this.

If that's literally slowing your organization down and causing way too much trouble, go talk to people doing recruiting and figure out how to make that better. But the reality is, I think for most places, there's going to be some people coming in that just need a little bit more help. So, I don't think there's anything wrong with doing some sessions where you're like stepping through some basic stuff with people. Record them. If there's other people that are new, do it in group sessions, right? You can kind of spread the impact of doing that across multiple things. Uh this is especially the case if you have several junior developers and you're like, I'm going to literally run out of time and never be able to do my own work again from helping them. instead of being in that situation like try to do some group sessions and get some time back.

To give you an example, when I was an engineering manager on the previous team I was on, I had a bunch of people that started that didn't know C. Some of them were new in career. Some of them, you know, had worked at previous companies but not in C. And I said, "Great. Once a week, like I'll pick random topics unless you have suggestions for us to go through." Like if even if there's parts in the codebase. I'm like, I don't know the code. I'm I was also new to the team. Like, I don't know the code, but we can go talk through it because like I work in C a lot. I can do that for you. I will spend the time. We'll record it. So, then we built up a little library of some of these videos. And it just became a thing we did with the team, right?

But that's that doesn't scale very well. It doesn't scale very well because like I can walk through those things. I can explain concepts and stuff and like that's fine. But I think what this individual is talking about is like there's some struggling not with just like syntax, but it sounds like their ability to debug and like problem solve and like really understand how code is flowing is a challenge. And I think the best way to get better at that is just to spend more time doing it. So, I think you can mix in like doing some learning sessions, but ultimately what I highly recommend you do is find ways to basically point someone in a direction and let them get stuck. Time box it, but they need to spend time getting stuck. for these conversations. I always share a uh a previous example from last company I worked at.

We had an intern and uh they're very smart, but they had this challenge where they they always gravitated towards like I'm going to ask a question and we would all fall into this trap of like we would just give them the answer. But I started to realize like they actually have um I don't know if I don't want to say it was like a difficulty like they didn't know how but at least they weren't necessarily practicing problem solving. They would get a challenge in front of them whether that was picking up some new work or you know some code or something whatever it was. anytime they hit a challenge and we were in the office at this time. I can remember them like kind of turning in their chair to like look over and be like like I have a question right and started picking up that like this person was not solving their own problems.

And so my number one cue with this kind of thing to push back on people again it's not to be a dick to them. It's not to be like, "You're screwed. I'm not helping you." It's that if you help them too much by giving them answers, you're not helping them long term. So, what I was doing with this individual was like this number one cue for me is, "Well, what have you tried so far?" Right? And this alone, I I realize it sounds like a gross oversimplification, but this alone was enough that on repeat they changed how they approached this because like I said, we were in person what would happen is I could see over time out of the corner of my eye, they would turn in their chair because they were about to ask me for help on something and they knew I would like they knew I was going to say, "Well, what have you tried?

so far. And the answer that they would have said was, "Well, nothing. They haven't tried anything yet." So, I could see over time that they would turn and then you could see like the light turn on and they're like, "Oh, like I got to go try something." Okay, so this is it's a simple thing. It's an easy cue. It might take some repetition, but the point is get people to try things first. work with them so that they understand to time box things. They don't want to spend like a week on like an if statement kind of Like that's ridiculous obviously, but like what's the right amount of time? I don't know. I don't know that. Figure it out. Work with people on this, but time box things and then get them to have tried things first. Okay, that's part one. Part two is when people need help and you can apply this kind of thing.

This is like a a thing in just in management in general, but you can apply it in all sorts of like mentoring situations is stop giving people answers. Just stop doing it. Now, okay, I'm I'm over generalizing because like yes, there are literally situations where it would be a waste of time to put someone through the problem solving. Like there's not a good lesson to learn. So like give them the answer if you have it. Like, hey, who's the best person I could reach out to that knows something about this? And you're like, hm, like I think you need to go problem solve this. No, just give them the person's name. But there's a lot of situations where it's like you might have in your mind an answer or a potential solution for something and instead of giving that person the answer, you ask them more questions.

You keep asking them questions and you can if you have a good idea in your mind where you think things should head, you can kind of steer them with your questions. And what will happen is you're teaching them to problem solve. they're going through and thinking about these things. This could be something that you do either synchronously on a call together, right? You spend 30 minutes, talk through things this way, keep asking them questions, getting them to kind of think through the next part. Could do it asynchronously. Okay, you've tried a couple things. Cool. You got stuck at this part. Okay, awesome. So, like have like uh what happened when you did this or what happened when you did that? What about this next thing? Cool. Okay, you don't know yet. Awesome. Okay, go take some time and go check into that. Let me know. Let me know what you come up with.

Right? Like push people to go do the things themselves, but put them in the right direction. Again, I don't I don't mean to make this sound like, oh, it's just so simple. It's not. And it's probably equally as hard for you as it feels like a pain in the ass for them. Because if you don't already do this kind of thing, if you're like most of us as software engineers, someone's like, "I have a problem." Your brain goes, "Okay, time to go solve problems." And your brain goes into like, you know, warp speed. Like, okay, give me the information. What's the context? What are the constraints? Like, boom, boom, boom, boom. Like, okay, I got three different solutions. Like, how can we navigate this? and you just want to start blasting out solutions at people because we love solving problems, but you're solving the wrong problem.

You're actually creating a different one long term, which is that people will take more like they'll take longer to be able to problem solve on their own. Okay? So this is my general approach to this kind of thing which is put people in a direction ask questions at them and then you can work with them your schedule as that individual as well to figure out how much of that's asynchronous what the time boxing looks like but ultimately that pattern I find works really well for coding for designing things for um for all sorts of stuff like investigating like doing uh data analysis. So that's my big recommendation there. Um there was I got to switch gears a little bit.

There was something else that was brought up that I feel like the way it was introduced was kind of like I feel like it wasn't trying to help uh help the person help the junior, but it was more to help the person kind of like if they're feeling kind of uh like they're in a sticky situation. And I think it's fair, but I wanted to maybe adjust the the verbiage a little bit. But um essentially they were like, "Hey, you know, if you're feeling like you're spending a lot of time on this stuff, you uh you probably want to talk to your manager." And I I don't know, like I kind of got the impression that it a little bit of that was to kind of like put the focus on the the more junior person, but I don't I don't really think that like you can, right?

you can make sure like depending on the severity of it, like I said, situational. I don't know the details here. If you really think that this person is like you've been working with them and you've been trying some of the stuff that I'm mentioning, you're just like, it's not going anywhere. There's literally there's going to be situations where people genuinely are not at the right skill level and you've tried coaching and you've tried a lot of things and it's not working. Like, absolutely. You don't just say, "Well, this bald guy on the internet said we just have to put all the time and effort in the world into helping them." That's not what I'm saying. I'm just saying I would absolutely lean into that first before going, "Ah, you know, this junior doesn't know something, so like we should probably just fire them." Um, so I I just wouldn't lean into that direction first.

But I do think that it's fair to go talk to your manager and say, "Hey, look, like you know, we have a junior on the team or a couple like new hires, whatever it is, and like just so you know, um that's taking up a lot of my time." You can ask them for their input on their strategies. Uh their like I think the most important part is like sort of clarifying the expectations, right? Devon, if you're listening to this, Devin, you know, level set expectations. Um, but I think that's a fair thing to bring up if you're spending way more time than you were hoping to like, hey, this is starting to interfere with some of my own work, like letting your manager know, hey, because maybe they need to step in. Maybe they tell you like, actually, I would much rather that you spend time with the juniors on this.

like that's more appreciated right now. Um it is okay if you know some of your work is slowing down a bit. Like I understand the circumstances and like long-term you know if we can kind of uh figure this out for coaching the juniors like that's I think that's a a better thing for team growth overall, right? Like have the conversation with your manager. I definitely think that's a good idea because what you don't want to do is like have this resentment with the junior people where you're like I'm trying my best to help, right? Like trying different strategies here and like it's chewing up a lot of time. And now you start like they reach out to you and you're like, oh my god, like Steve, why is Steve reaching out to me again? Oh man, I hate Steve. He's bothering me all the time. Because then you will turn into the the more senior person that's an to juniors.

Right? And it's because you're resenting them because you're not able to get your work done. So like try to have a conversation with your manager just so that you're on the same page. Your manager might say, "Hey, look, like I didn't I didn't think that I was under the impression that we brought this person on at a very different skill level. They can go take an approach." Like whatever it needs to be, but I think a conversation's helpful. My my point with like walking through this one was one, level set expectations I think is very important. And two, I um the way that I read the related comment just kind of felt like they were putting the the blame on the junior and like I just don't think that that's super fair. But I also don't have all the context. So that's how it goes. So anyway, I hope that's helpful.

So if you are, like I said, a junior developer and you made it all the way through this video, thank you so much for giving me the time and kind of looking past the the triggering comments in the beginning because my goal is that I just want to make sure that people have some different perspective to to do things in their software engineering career. I hope that it's helpful. If you hear what I'm saying and you're like, I hate everything this guy says. At least it's different perspective, right? Like that's at least a lesson because in your career, you're going to meet all sorts of people with different perspectives. And even when you don't agree with them or you don't like them, you can try to find truths from them because maybe you don't agree with everything I'm saying. And that's totally cool. It's not not my intention, but if you can extract pieces and you're like, "Hey, like hadn't thought about something that way, that's a win, right?

I'm happy if that's the case." So, thanks for giving me the time of day. And uh like I said earlier in the video, I have a bunch of other YouTube channels. So, um there's Dev Leader where I have my C and programming tutorials. There's Dev Leader Path to Tech. I do resume reviews there. They are not roasts. They're not making fun of people. Uh they are both, you know, um what you're doing well on it and also uh criticism, things that I think that you should try to improve and and why, right? But it's not a roast. I've had people ask like, "Rost my resume." I'm like, "Dude, I'm not making fun of your resume." Like, that's it's just not helpful. Uh I don't know. I don't even know if that would do better with views or not. But like that channel for me is kind of like, you know, it's free resume reviews.

If it helps you, then it helps you. And I've had a couple people say like, you know, re uh revised it, started applying again. Some people are landing jobs. I don't think that's because of me. I think that's just because they, you know, they did the right thing for them on their resume. I'm not taking credit for it. And then I also have a Dev Leader podcast. That one I do live streams every Monday at 7:00 p.m. Pacific. Uh so that's usually on a like a code commute topic. So, next week's will be uh well, depending when you're watching this, the one that I do this upcoming Monday is going to be on a junior developer topic because I had one video so far on this channel that was like 10x everything else reviews. So, we'll do that. And uh I also do uh software engineering interviews on that podcast channel.

So, um, if you're interested in hearing about other people's career journeys, what they're doing as software engineers, there's all sorts of different examples. I try to make sure that I'm getting people that have, you know, all sorts of variety of experiences. Some people they did go to college or university, some people as boot camp graduates, some people as career switchers. I just want to make sure that there's, you know, a variety of things because for you as the viewer, I want you to see that everyone's path is going to be different. There's going to be people with similar struggles to you. There's going to be people that had, you know, something that looks completely different and that might be uh kind of inspiring to you to be like, hey, it doesn't have to look a particular way. So, um yeah, I hope that you find those helpful as well.

So again, thanks so much for watching. I'm almost at the office, so I will see you in the next video.