This Is Hard But We Can Fix It - Conversations With Senior Software Engineers

as a software developer I bet this is something that you've encountered at some point in your career so imagine that you're working on a project and you're responsible for some portion of the delivery of that project now in your team you are currently a junior member and there are more senior software Engineers on the team working with you so as you're navigating the parts that you're responsible for in the project you're also asking the more senior members of the team for input asking questions for clarity just so that you can make progress on the portion that you're responsible for now something that occurs while you're working on this project is that you're building up expertise that's very relevant to the portion that you're responsible for and then this situation happens you end up having a conversation with someone more senior on the team and right away they end up saying very confidently that something that you're assuming is incorrect or they have a different approach that's better for the thing that you're trying to do and because they're more senior you just end up swallowing your pride you take their word as the absolute truth because they're the more senior software engineer and you go ahead with the approach approach that they're suggesting I wanted to make this video because it's very relevant to a conversation that I had recently and I thought that it would be useful to explain how to navigate something like this when you're dealing with more senior software engineers and this is actually regardless of how Junior you are so you could be a senior level software engineer kind of speaking up to a principal level or staff or however the levels work at your company but it's really focused around this idea of being able to speak and navigate conversations with more senior members of the team so the example that I gave in the beginning of this video can play out in a bunch of different ways and obviously certain things could be more extreme in some cases you might have interactions that seem like they're a little bit aggressive or someone's frustrated with you you know being the more Junior person they could actually be not frustrated at all and they're just kind of saying nope dismissing your thoughts and just trying to move things along right so this can look a bunch of different ways this feedback and uh this guidance is supposed to be generic so I I just want you to consider that that I obviously can't apply this to every possible variation of it but just something to think through as you're navigating something like this I think it's important to acknowledge that we can't actually control the way that others interact with us we can only respond to it so if you have situations where there's more senior members of a software engineering team that you're working with being dismissive of ideas that's really unfortunate and I think that there are of course ways that you can have conversations with them to let them know how you're feeling I think that their manager should be able to help navigate that type of thing with them kind of Coach them to not have situations like that in the first place but as much as someone tries to focus on improving those other things in the end it's sort of outside of your control how other people behave and that means that ultimately it comes down to how we respond to these types of things so even if you have someone on your team that you're working with and you end up building a better relationship such that they don't end up dismissing ing your ideas a lot on a future team or new team members or whatever there could be situations where this comes up again so I think yes of course we want to find ways to be preventative that might not necessarily be up to you but yes you can speak with people to try and improve that but the reality is and the point that I'm trying to get across here is that I think as much as we want to do that there's also this idea of trying to be prepared for conversations like this in the future and how you can respond to that most of the time I don't think that people do this type of thing where they're dismissing your ideas or just trying to you know move things along and ignoring what you're having to say as something that's malicious I honestly don't think that's the intent and I think for the most part people don't realize they're doing something like this and having a negative side effect on you especially as someone that's more Junior and what's even more challenging is that if we think through that scenario I was explaining in the beginning there are situations where as a more Junior developer or more Junior member of the team that you are gaining specific knowledge that might actually be counter to what someone more senior is having to say and you're faced with this bit of Roadblock where you're like well they're saying something I don't agree with it because I feel like I just learned about this other thing read the code saw how it was working whatever and it's really at odds with what they have to say but they're more senior I guess I just have to trust them and I think one of the best things that you can do in a scenario like this is ask questions and how we ask questions is actually the really important part here because you can do something where you're asking questions and it actually makes this feel even worse so to explain what I mean by that if you have someone more senior on the team that's saying hey like no like we're not doing that here's the path forward or that information's not correct here's here's the reality of the situation right and you have to kind of take this as the truth because they're more senior if you just ask them questions and it makes it sound like you're just challenging what they have to say odds are they're probably going to get more defensive this is kind of like a human nature thing where when you're questioning someone's like intelligence right they're like or questioning their factual information people automatically want to defend what they have to say because it's something they believed was true so while that might be a natural response there's something that we can do to change how people react to that and I think the way that we do that is by genuinely being curious so when you go to ask questions back to someone that's more senior so they're proposing something that's at odds with what you agree with you can say hey like that's actually pretty interesting could you explain why something is fast or could you explain why that part of the code base has been a challenge or can you explain and just dig into their reasoning right because a lot of the time this is challenging because they're not providing the reasoning it's sort of like here's something I know I'm more senior let's keep moving and the act of questioning and trying to seek to understand can get them to explain their thought process can start offering up where they actually believe they have some evidence and this can lead to some more very interesting conversations so in this particular case it might be something where this person actually uncovers some other details that you were totally unaware of right and then this kind of goes back to okay they're the more senior person they happen to have some extra information I wasn't aware of that perhaps they are right in which case cool no hard feelings you tried doing something you were learning and they had some extra information now you know it and you can both progress forward as part of this project the flip side to that is that the other side actually has the learning so as you're navigating this conversation seeking to understand and the more senior person gives you some data points you might actually be able to say hey I was looking at this and I actually uncovered that this code path isn't even used or we actually ran some tests and this is faster or whatever it happens to be right so you might have some data that you can bring to the table that is counter to what they're aware of and again the goal of this is not to be like haha you're wrong I'm right like I'm I know way better so like let's move along with my solution but it's really all about aligning expectations and making making sure people are on the same page so what should happen hopefully is that with some new information I would say most good software Engineers would say oh interesting okay let's re-evaluate and readjust it may not mean necessarily that they jump right into the solution that you're offering but they might reframe things and then go back to the drawing board with you with this new data to come up with a path forward and I think personally that's a huge win because now you've brought up to speed other people and you can work together on a better solution going forward now another way that this type of conversation can pan out is based around the phrase that's very dangerous but we've always done it this way right so if you have more senior people on the team saying well you know we can't do that or this doesn't make sense because we've just always done things this way that's a really interesting opportunity to shake things up and again when I say shake things up I don't mean actually going in with the purpose of being disruptive and causing havoc and chaos but I mean it's a good opportunity to actually change the way that people do things and of course like I was saying earlier people are going to want to resist this because change is something that people aren't comfortable with but you can use the same approach where you're asking questions to seek to understand and try to see if there's more things that you can uncover so if someone's leading with hey we've always done it this way and they kind of leave it at that ask why like oh well what was the reason that we introduced this in the first place start to uncover some of those reasons it's not a matter of questioning why a design is a certain way or why something was implemented and trying to say like oh well that's clearly wrong now but understanding the original intent and understanding the original set of information that people had to make that decision can actually lead to a conversation where people are considering Alternatives in the current state and this is pretty cool because I've seen conversations that have happened at work over the past couple of years multiple times where someone has said to a more senior software engineer something like this hey I was looking through the code and notice that I think that we should be able to go down this code path I think it's going to be more optimal and I think we could try implementing this type of design to make this work and the more senior software engineer goes oh well no you know we've tried something like that in the past it doesn't really work and uh we've kind of just always done it this way and it it seems to be fine and then the person starts to question a little little bit like oh could you explain like why we made that decision and from there after uncovering some things what happens is that the senior software engineer is actually the person that comes up with the idea like maybe it is time for change so as they're navigating it's almost like rubber ducking right if you've heard of that phrase in programming but as they're trying to explain things to you and be helpful and get you up to speed because you were genuinely trying to be curious and understand they come to the conclusion themselves that hey maybe this assumption that we've had for x amount of time doesn't hold true anymore maybe it is time to revisit this maybe it is time for change so to summarize the approach in this video when you're trying to speak to more senior software engineers and trying to navigate this situation where because they're more senior it kind of feels like they have the authority or the knowall in this situation that you're working through the idea that I'm proposing to you is to ask questions and seek to understand I feel like the worst case scenario that happens here is that you learn something and you happen to be incorrect and that's okay because you're learning and the best case situation is that the other side actually learns from you and you can move forward with the change that you're thinking about for the better of the project or the team and this of course can be extra powerful in those situations where you have people saying we've always done it this way because odds are something's been in place for potentially years and it's time time to actually rethink how that works so remember we can't control how other people behave that's okay but we can control how we respond to that and try to move conversations forward in a positive way so I hope you found that useful I think that collaboration and teamwork is incredibly important in software engineering so I hope that you can apply these type of Concepts going forward thanks so much for watching and we'll see you next time