How Do I Deal With Junior Developers Who Just Won't Listen?

How Do I Deal With Junior Developers Who Just Won't Listen?

• 236 views
vlogvloggervloggingmercedesmercedes AMGMercedes AMG GTAMG GTbig techsoftware engineeringsoftware engineercar vlogvlogssoftware developmentsoftware engineersmicrosoftprogrammingtips for developerscareer in techfaangwork vlogdevleaderdev leadernick cosentinoengineering managerleadershipmsftsoftware developercode commutecodecommutecommuteredditreddit storiesreddit storyask redditaskredditaskreddit storiesredditorlinkedin

From ExperiencedDevs subreddit, this Redditor wanted to know what to do about those pesky junior developers who just won't listen to him! Let's see if we can explore this a bit further.

📄 Auto-Generated Transcript

Transcript is auto-generated and may contain errors.

Hey folks, I'm just leaving work. We're going to go to experienced devs subreddit for a topic today. And this one was really about dealing the way they frame it is like dealing with junior engineers that uh basically um keep treating the senior person. They say they have like 12 years of experience like everything that they're suggesting is just theoretical. So, they're kind of fighting everything that the senior person is saying and like kind of being a pain in the ass. And so, this person's like, "How do I deal with this? Cuz it seems like the only way that I can really do it is like I have to like like lay down the law and just say, "Look, I'm the senior. Like, shut up." Uh, which I don't think that they, you know, I don't think they want to do that, but they're feeling like they're they're frustrated, right?

like it feels like it's a huge roadblock, which I thought was kind of interesting cuz I feel like I hear this the other way a lot where you have almost like the opposite experience where like juniors are trying to do something and then you have like, you know, some senior person on the team who's gatekeeping all the changes or whatever. Um, like I feel like that's a more common scenario. Um, but I don't know. I don't have data to prove that. That's what I hear about more. So, this kind of interesting and um I was reading through the comments a little bit to get some ideas to see what people are kind of chatting through. Um one of the top comments was like someone giving a personal experience where they said they had a great team lead that that actually like wasn't pushy about this kind of stuff.

So, like if they were talking through stuff, they'd kind of give their recommendation, but like but like they weren't enforcing anything. It's like go go go do your thing. And then the person said inevitably cuz they're talking about themselves. Like inevitably when I would, you know, my solution didn't work and I had to go back to the team lead, they wouldn't like rub it in or anything, you know, just kind of like, hey, yeah, sure. And like kind of would bring up the original points and say like, you know, here's here's what I think you should do. And kind of just reiterate. um which someone responded to and I like I agree with the response to this because the way that's framed up in that comment sounds nice and like if you can have that experience I actually think that's great but I I don't

think that it's something that I could like outright just recommend because I think it depends a lot on the people and there was like one of the responses to that comment was was basically that like, hey, this works really well when you have two people that work like this, but when you don't, like what are you expecting is going to happen, right? Like, um, it kind of requires that you have a team lead that's good. It kind of requires that you have a, you know, a more junior person that is going to kind of, uh, go back to the team lead and talk things through and and that exper like that interaction is going to look okay. like kind of a lot of assumptions that have to line up. But I I do agree that that would be a nice um sort of interaction and outcome.

And some of the other thoughts that I saw in the thread were really like people saying like hey like like people kind of got to learn the hard way. And I I do like part of me agrees with that. like I know from my own experience there's stuff where people can tell me and like it might make sense or whatever but the stuff that I learn most effectively is like yeah when I make mistakes like I learn from those much more effectively or even if it's not even a mistake right let's uh good example for me in recent times is like uh when I have to go on call for my team right um the team has done tremendous job especially over the last few months like making sure that we have like on call resources that are up to date like there's tech talks

you can watch like walkthroughs like so much good stuff they're doing but personally I know this about myself like I could watch that I could read that and it won't even touch compared to me like living it and having to go solve the incident and step through the stuff like it it's just a completely different um you level of learning for me uh to the point where it almost it almost feels useless for me to go watch videos and read documentation ahead of time because it just won't stick. That's the thing I think is like it's not enough um iteration or exposure to the information, but if I'm going on call and I have to go solve an incident, like that's where I'm like I'm hands on like it's getting like burned into my skull. But um yeah, I think like it's tricky because I do think that for the most part we we kind of learn the hard way.

So like how can you how can you be helpful as a more senior person in a situation like this because the goal is like is you don't want to get to the point where this person's at where they're like I'm so frustrated that I I feel like I can't make progress with these people. Um give me one sec. I just want to switch lanes here and I have to look forwards and backwards at the same time. Come on, buddy. You got to speed up if you're switching lanes. Okay. Um, yeah. Like how do we how do we do a good job with the more junior people so that uh we can balance like basically teaching them and then not being frustrated all the time and making sure that the software that gets built is good. I think there's something to be said about not forcing people to do things right.

Um, I think when we get into this mode of like I need to be the gatekeeper, um, like kind of again this person who wrote the the Reddit post is like they feel like they're getting to that point where it seems like it's the only way. And you know, you can tell just by the framing of that. They're like, I don't want to do this, but it feels like that's the only way it's going to be effective. I I don't think that you want to get to that point. So, in my mind, it's like how do you battle between uh trying to be helpful, trying to have room for other people to bring up ideas and like how much effort you put into that. And it's certainly not easy.

So, I think the way that this person kind of talked about how they were explaining some things is like it seemed like they were saying, "Hey, like here's here's the recommendation and like I can back that up with like evidence from my um like my career." And I might I don't mean to misrepresent this. I truthfully I just kind of skimmed through. So, if that's not exactly how they were framing it, I apologize. But, um, it seemed like that was the the general framing is like, you know, trying to explain things. So, I would say what the reason or say what the thing is, this is the way forward and like I have the experience to back it up. And like I think if that's how it's being limited, there's um there's some some room there, right?

I I can I'm trying to think back to when I was uh a little bit earlier in my career and I I worked with someone that would say like like no no no like this is the path we're going to take and I I realized like we're kind of getting one side of this story. This is what always happens with Reddit. we're getting one side of the story, but in my lived experience, I had someone that would say like, "Hey, no, this is the path forward." And then they would, again, they would defend it by saying like, "No, like I've seen this before. Here's how we do it." And what was unfortunate was that a lot of the time, like those those decisions wouldn't necessarily work out well. So what would happen is like it wasn't building a positive reinforcement loop. It was like no no like we do it this way.

I've seen it before. We go do it. And you know initially like we're more junior. We're like okay like I I guess we have to go do it this way. And then something would come up and it doesn't pan out. We're like okay like not great. And then this pattern would repeat. And I'm not saying like this was like every day this kind of thing was happening, but you see enough examples of this where you're like, look, we got to start as the more junior people, we have to start speaking up about this because clearly I've seen this before is not is not sufficient. So like that kind of experience wasn't good where you just have someone telling you no, like no, we do it this way and then the defense for it or the support is I've seen this before or I've read about this.

Like I think what ends up getting missed in that conversation and what it feels like is missing from the Reddit post and again don't mean to misrepresent this person is like I would want to invite conversation both ways because I highly doubt a junior is just blatantly doing the opposite where they're like you suggest that well no it's wrong like we're doing it this way and like and then that's it. Like it's a stalemate. So I think I would try to invite conversation around it so that people could explore it because I think you get two at least two things come out of this. One is that when you have people with a different perspective than you have if you're the more senior person, you might actually catch something that you weren't thinking about. So they can raise awareness for you and you're like, "Oh, I didn't think about it that way." This might seem like it's a rare thing to you or it never happens, but like it happens.

And this is just one of the many reasons why hearing different perspective, at least hearing it, is beneficial. Doesn't mean that just because it's a different perspective, you have to go take it and do it. But it might tell you something that you weren't thinking of. it might actually help you understand where they're coming from. So, they're explaining to you something one way and they're like, "I think we should do it this way. Here's why." And you're going, "Oh, I see why you're prioritizing that over, you know, something else." Like, I see where you're coming from now. It's actually not correct, but I can see like now where that misunderstanding is coming from. So, I think it's important you listen so that you can learn about the different perspective. It gives the opportunity for the person who is more junior to be able to speak up and ask questions.

So like I think that's good from a team culture point of view. The when you get to a point of like you know kind of asserting authority even if it's not like blatant but you're like no here's the path forward and like seen it before so like move on. It's kind It's almost like dismissive that like we don't need you to think about making decisions and like I don't think that's a good spot to be in. So, a lot of me wants to lean in the direction of like open up the conversation, but I want to get to in a moment. I want to get to this idea that like I can understand that might feel tiring. Totally. I get that. Um, and especially if you have people that are more junior or I guess it doesn't even matter if they're more junior, but for this conversation, that's what the framing is.

So, especially if they're more junior and um, and it almost feels like they're already stuck in their ways cuz you're sitting there going like, man, like I have more experience than you. You haven't even done this before and you're not even willing to budge on it. Like, what the heck, man? Um, but I personally lean more into like the I would rather have more conversation than less. Um, from a I don't know like a team cohesiveness kind of point of view. Um, building up like psychological safety. Like I just really want to encourage people to be able to speak up and talk as much as possible. Um I think what like if you go the other way and you start shutting people down so that you can't have that discussion um I I think that over time what happens like is that kind of spreads into different parts of the team culture and um then you start getting people isolated.

You have a you have a group of individuals rather than like like a team working together. So, this person's not going to zipper merge. Okay. You got to If you're not going to let me zipper merge, you got to let me get behind you, dummy. One or the other. You can't be stupid both ways. You got to pick your stupid. Um, okay. Let me let me emerge onto the highway here. Uh behind Dum Dum in front of me and uh I'm gonna try to shift gears to kind of looking at it the other way. Like how do you temper that um you know sort of the push back or like the conversation that's not going to end now cuz just an endless debate. Um just give me a sec. I don't trust people that uh can't understand how to merge on the highways. They're basically hitting the brakes to switch lanes.

You don't want to be doing that. If you've never driven a vehicle before, let me let me explain. Oh, another person. Come on, buddy. There's so much room in front of you. You don't need to break. We're going to fly in just a second here. Ready? Great. It's important that you get away from the really stupid people that um make it very dangerous to get on the highway and we've done it. So, okay. Um, I've been saying so far that I encourage a lot of conversation. Um, and that way people can ask questions, they can explore because I want I personally want that. Like that's one of the top things I want in a team culture is that people feel comfortable speaking up. But I realize that probably doesn't sound helpful u for the people that are like, "Look, man, I got to deal with these people.

They don't they don't believe anything I'm saying." Um even through those conversations though the um I think what can be a skill that you can work on is not trying to say I've like basically I've seen this before therefore we should do it. It's um like you can leverage the experience but I think it's important to explore like with the person so that you can arrive at a similar conclusion. I feel like just as an example, if your only sort of defense for why something is the right path is like I've seen it before, like that doesn't that doesn't actually teach someone about why that's a valuable option. That teaches them that you're just trying to assert your opinion and that they just need to believe you, which maybe they should, right? Like maybe from your perspective, you're like this is literally the same thing. Like that's why it's frustrating, right?

Like this person person should just believe what I have to say. But I think that you go through this conversation and it's like try to resist. Oh, it's like I've seen this before. It's the same thing. Well, why why was that the right thing to do before? Like go back and explain like why that process made sense. Don't use it as the ammunition to say like I've done it before therefore it's like okay let's break it down. So like you are proposing that we refactor the code this way. Okay and your argument for that is this. Okay cool let's go through this thought exercise and then like walk through it instead of being like no like here's an example and like just using that as the only only thing to support it. I think you can use it as supporting evidence, but I don't think that it should form the basis of your argument, right?

Because it's like the same I go I think back to like the example I was trying to give where I had someone that was just like basically I've seen this before. We're doing it this way. Is like no one is learning about why that's a valuable choice. No one's re-evaluating if it's a valuable choice. You have a single person that is like the decision maker and that we're just supposed to trust them. And like you might be right in this scenario, but there's going to be times where you're wrong. And that's totally cool. So like why not get that conversation flowing and then learn different ways to explain things to people. Right. So, part of me is going like I think that this is especially frustrating because you haven't found an effective way to communicate your logic to other people. And communication is not just like a single person's responsibility.

So maybe this person really is trying and they happen to have two more junior developers that are also really ineffective with communication and um I mean that's things can line up that way but I don't think that basically stopping communication improves it. So, I feel like it's one of those things that if you're having communication challenges, one of the most effective solutions is to do more communication is to like work on it, right? Like you you don't make that problem go away simply by trying to like stop it. Okay. Um, some of the things that I I liked though, uh, from what I saw in the comments in that example where it was like, you know, they they weren't forcing their opinion on me. They would like let me make a mistake and then inevitably inevitably I would go back to them. This is like there's some really nice parts to this.

One is like there's this is like built-in psychological safety, right? the more senior person's not like, "Oh man, told you you absolute dummy." Like, "You're so stupid. Should have listened to me, but nope, you're just a dumb junior." Like, no one's doing that. They're like, "Yeah, it's like, sure, didn't work. Cool." Like, you're back for my opinion. Here you go. Like, I will I'll reexlain some things to you. And but like, you're you're you're not belittling people for making mistakes. As soon as you start doing that, your culture goes to So don't So I really like that in their example they were they were showing that like that is a thing that can that can help reinforce like positive culture. So, um, the thing that I wanted to focus on from that though was I think that you can absolutely lean into that, especially for things that uh, what's the analogy here?

Like, um, I'm going to butcher this. I'm so sorry, but I heard like the analogy is like, uh, I would I would say like if it's going to paint you into a corner, don't do it. But um I think the other way that I've heard this phrased is like walking through doors that you can walk back through versus walking through a door that you can't go back through. So if someone's going to make a decision, right, and you're like, I don't think that's the right thing, right? Um, if that's not something that can't be like changed easily or, you know, if it's something that is high risk, like you might want to push back a lot more on that. And push back means like you should encourage, in my opinion, encourage the conversation more. Like clearly it's not getting through about why this is risky or not the right move.

We should keep talking so that it's understood. And then for the other things where they're like, I want to do this and you're like, I think that's a dumb idea, but you're like thinking through it and you're like, that's something like we could change that easily if that's not going to work and I don't think it's going to work. That could literally just be the cost of people learning, which is a hard kind of thing to think about when we're talking about building software in teams. But like we're people and people got to learn and people learn unfortunately the hard way a lot of the time. So, I think if you're doing this tradeoff analysis, cuz you're a software engineer, like is it a hill that you should die on, right? Um, I want to think if I have a good recent example of this. Um, okay.

I I don't know if I can get into it's going to be impossible to go explain this without specifics. Okay. Um, I'm trying to think about a scenario where we were going through a design for something and I had um maybe I could frame it this way. I had someone for a design. They were they started proposing something and in my mind I was like, "Oh shit." Like I don't think that this person's getting it at all. And in like the first thing I want to do, not that I'm the expert at solving this particular problem, but the first thing that I'm trying to do is like, well, I'm going to solve it. I'm going to solve it and then then it's okay cuz like then I can just tell them and they're not going to screw it up. So my brain turns on that way and I'm starting to do that in my head as they're explaining things and I keep kind of like going ah like I don't think that's right.

I don't think that's right. And then what ends up happening is like they're explaining their thought process, they get to a point and then instead of me going like, "Nope, that's not right. You should go do it this way." Um, there's a coaching technique that's really just like when we we actually had someone explain this at Microsoft, which is pretty rare cuz I feel like any management training is basically zero everywhere in the world. But um we had this course that we took and the guy would refer to it as just like being lazy, which is a funny way to remember it and it worked cuz I still remember it. But his point with being lazy was like don't solve the problem. Don't do the work. You ask people, you ask them questions. You be lazy. You sit back. You ask questions. And that's what I started doing in this case where it was like in my mind I'm like this this is not the right path.

I started to try and solve it in my head and then as the conversation's kind of going back and forth, I'm like, "Okay, so let me ask questions about this." So, I'm trying and I'm doing this in a way that's not just like uh condescending. So, I'm finding a way to like poke holes in their design without being like, "Oh, I bet you didn't think about this, dummy." Um, it's more like, "Cool. Okay. So, let me understand, you know, you're proposing this and the benefit that it's going to offer is X, Y, and Z. Okay. Um, cool. Like, let's walk through this scenario like what happens here, right? Like, walk me through like what this would look like. And then what ends up happening is that I ask questions and kind of guide people down a path and I'm thinking about a scenario, but this has happened in different scenarios as well.

and they kind of get to this point where they're like, "Oh, like Yeah, like that doesn't work." So, cool. Okay. Well, what what things can you think of? And in some situations, what happens is they're so anchored to this idea that they've come up with that in my mind, I'm like that it's just not going to work. Uh, and that's because I have some of the experience. I have seen things like this before. I have seen alternatives that do the exact thing. And so, they keep trying and iterating and I go, "Cool. Okay. So like seems like trying a couple things here but we're still kind of stuck on this. So I'm like what like if we back up from this like is there is there another direction that we could look? So basically getting them to like explore their problem space with their solution and then if they're reaching points where shit's not working I'm letting them figure out like oh crap maybe we need to go explore in a different way.

Then what happens is in some situations it's like well the reason they arrived at that solution is because like either they didn't understand some of the other solutions that exist they don't even know they exist or something else right but I had situations where people number one weren't aware of things and number two did not understand how they functioned even the things that they they did figure out. Um, so in the situation where people didn't know that other stuff existed, I kind of got them to go back to like like fundamentally like what's the problem you're trying to solve in this case. Okay. And you need it to work like this. Okay. So they're explaining it to me. Great. Okay. And then what I tried doing was like, okay, so you explored this other technology in your proposal, but like kind of we saw that there's some limitations there.

That's fine. Um like do we have like is there something else that like addresses this particular point like uh I don't want to explain it and like kind of talk about the scenario exactly but the point was like if I can address part of the problem space because I'm there isn't a solution that does exactly what they want end to end but I'm like there's literally technology that does this part there's technology that does this other part and there's this technology that does this third part. All you need to do is put them together and like you're done. But what was happening was that they weren't aware of those technologies and in some cases they weren't aware uh if they knew the technology, they weren't aware that it could do that function. So I tried walking them through the parts and saying, "Is there something we have that's similar to that?" And they were like, "Well, yeah, this other thing." And I'm like, "Okay.

is that like do you think maybe that could work here? There's different ways to do this where it doesn't sound so obvious, but the point is that by asking a lot of questions back to them and just letting people kind of fumble through it, that actually helped a lot. Now, what you might not like about that is that that takes time and that's going to feel painful, especially if you're already at the point where you're frustrated with people. Because if you've already reached that point, having a like productive conversation feels terrible because you're like, I don't want to do this. I don't want to spend any more time with this person. So, it's why it's really good to get ahead of this stuff. But I would encourage you if you have reached this point, like I I don't think less conversations are the helpful thing. I think more is helpful.

and letting people explore their problem space. If you get to the point where you're trying to like attack the things they're saying, it's not going to be received well. And like you know this, like you're not a stupid person. You don't need me to tell you that. But like odds are if you're trying to defend a point of view and you're getting frustrated, it's going to seem like very easy to be like, "Oh, I'm jumping at that and attacking it." Instead, try to encourage people to like to elaborate and to go and explain without making it sound like you're setting them up to fail the question because this happens a lot by the way uh even unintentionally especially when you have uh language barriers or cultural differences.

I've see this so much like question asking um people can be very curious or they're trying to be helpful with their question and what happens is the receiver of that question goes this person like I see what they're doing they're trying to set me up so that I give an answer and like they're basically trying to to make me look like an idiot. I cannot tell you how many times I've seen this happen where someone was like, "I don't know why this person's frustrated with me or I don't know why they reacted a certain way. I'm just trying to like just trying to understand where they're getting stuck or I'm just trying to help and the person took that as like, you know, they're being challenged like they don't know what they're talking about and it sucks. sucks for both people, but it's like it's a super common communication thing that I've observed.

So, I think as much as possible when you're going through that those conversations, like try to be as transparent as you can be that you're being curious, and you should be curious. Uh even if you think that something I spat everywhere. My goodness. Even if you think that something's not going to work, like be curious about exploring it with the person. Um, I find that those conversations are super helpful. They take time, but people learn as they're going through stuff. Um, at the end of the day, you know, if you're the more senior person and someone's making a decision that's very risky and you need to kind of veto it, you got to do it, right? Someone's going to do something that's high risk, you got to stop them. Um, like I managed the uh the firewall for Office 365. If I had a team member that was going to do something that was going to jeopardize security, like if I need to stop them, I'm going to stop them.

Like if I'm on the review and I'm like, "Yep, that's not going to be okay." Even though other people might have missed it or whatever, they were like, "This is going to be the better option." If it's going to compromise security or I think it will, then I will veto it. Not because I'm trying to be an and not because I don't want to give them the opportunity to talk it through, but if I need to, it will get vetoed and then we'll discuss it and then we'll we'll make sure that everyone's learning from it because there's going to be something for me to learn as well. But anyway, I think that's my take on this topic.

Um, I can understand like when people are you're in this situation where like you're trying to be helpful but it just feels like you're being met with resistance and you're like you either feel like why do I even bother and you become like passive about it so you don't do anything or you're like more you're more passionate about it so you're like I I have to stop other people and you're it's like out of frustration. So, uh, both of those are kind of crappy spots to be in. So, I get it. I don't mean to make this conversation sound like it's a trivial thing to to go through cuz it's not. But this is the joy of software engineering, right? Everyone is too busy freaking out about AI and learning how to lead code and then we forget that the hardest part about software engineering is uh working with other people.

So, um, thank you so much for watching. If you have questions that you want answered, you can leave them below in the comments. Otherwise, you can go to code.com and submit questions anonymously, which is super cool. And then, if you're not aware, I have three other YouTube channels. So, I have devleader, which is where I have my car,net, and AI programming tutorials. You can go check that out. They're all edited down nicely for you to follow along with. There is dev leader path to tech where I do resume reviews and I'll have some other tips for interviewing and stuff like that. And then there is the dev leader podcast where I have a podcast and that's with other software engineers. I interview them about their career journeys and uh sort of one of the things or some of the things that they're very interested in talking about.

And on that channel, I also do a live stream every Monday at 700 p.m. Pacific where it's kind of like topics from Code Commute. In fact, most of the topics come from Code Commute and we can chat about them because there's actually a chat. It's an AMA style, so you can ask away. I usually come with the topic, but if you just want to ask questions about anything, just do it and I'm happy to chat back and forth with you. So, thank you so much for watching. I will see you in the next one.

Frequently Asked Questions

These Q&A summaries are AI-generated from the video transcript and may not reflect my exact wording. Watch the video for the full context.

How should a senior developer handle junior developers who resist their suggestions?
I believe it's important to invite open conversation rather than just asserting authority. I try to explain my recommendations with evidence from my experience, but I also encourage juniors to share their perspectives so we can explore ideas together. This approach helps build psychological safety and team cohesion, rather than shutting down communication which can lead to frustration and isolation.
What communication strategies do you recommend when dealing with disagreements on technical decisions?
I recommend asking questions and guiding the junior developer through their thought process instead of directly solving the problem for them. By being curious and encouraging them to elaborate, I help them explore their problem space and identify potential issues themselves. This method takes time and patience but leads to better understanding and learning for both parties.
When is it appropriate for a senior developer to veto a junior developer's decision?
If a junior developer is making a high-risk decision that could jeopardize the project, such as compromising security, I believe it's necessary to step in and veto that decision. However, I do this not to shut down conversation but to protect the team and project. After vetoing, I make sure to discuss the reasons openly so everyone can learn from the situation.