Do You Suck At This Critical Software Engineering Skill?

what's the most common topic that I speak to Junior Engineers that I manage and Engineers that I Mentor I'll give you one hint despite that I like to show people how to program it actually is far less specific than how you might go write code in this video I'll speak to this critical topic and how I help people navigate it by the end of it you should have some ideas about how you can implement this for yourself now press pause on the video for just a second in the comments I want to hear from you what you think the most common topic is that I speak to Junior Engineers about awesome and by the end of this video let's go back and see how many of you are accurate alright so the most common topic that I speak to Junior Engineers about is actually problem solving and hold on before you go trying to leave this video because you think you heard the answer already you're going to want to stay right to the end because I can explain to you how you can take advantage of some of these ideas and apply them for yourself alright when it comes to problem solving in my opinion this is a lot more relevant now that we have so many more people working remotely now this isn't just because people are working remotely it's just the effects of it are compounded from what I've observed the challenge that a lot of Junior Engineers face when they're thinking about problem solving is really how much should they be doing on their own and how should they go about reaching out for help when they need it and that might sound really simple on the service but it can tell you in practice from working with a lot of people it's not that trivial to help explain this I want to use a little bit of a visual Spectrum analogy so on one hand we're going to have people that constantly lean into trying to ask questions early and this way they can keep getting unblocked and moving along very rapidly on the other hand we're going to have people that try to solve everything on their own they don't reach out for help very frequently and this ends up meaning they're spending a lot of time on their own problem solving now neither of these two ends of the spectrum are wrong by any means but in my opinion there's a really good hybrid that you can take that's right in the middle first I want to focus on the side of the spectrum that ends up reaching out for help very early and very often first of all if you're working on a team and you find that you're very comfortable being able to reach out for help early and often that's great because I think you're probably be surrounded by people that are really helpful and want to see you succeed however there could be a little bit of risk with this and if you're the person that's on the other side of giving the advice this is actually something you're going to want to listen into as well when we think about problem solving and constantly reaching out to ask questions when we lean into this a little bit too much what we're actually doing is just getting answers and not actually thinking through how we go to solve problems so when you're first tasked with something that you don't totally understand and you don't know the answer to the immediate reaction should not be well I'm just going to go ask someone that I think has the answer of course while there might be more senior people on the team that do have the answer and they can give it to you very fast if you don't take the time to at least think about this on your own you're never going to be really practicing how to problem solve now for some of you you might be thinking well if I go reach out for help aren't I going to get the answer to the question I have sooner and be able to move on to other things faster and yes in theory this is probably true but the reality is that it's not really scalable if you think about it in reality you're just proxying the work to someone else so that they can answer it and then you're just going to implement the solution for it in the long run this is not going to build up your problem solving skills and in my opinion what will end up happening is that you're going to find that your growth as a software engineer is actually slower than you might expect now let's jump over to the complete opposite side of the spectrum for people that focus on just trying to solve every problem on their own and don't reach out for help from my experience I've seen this happen for a handful of different reasons one of these reasons is not understanding the priority and the time constraints around the work that's been assigned so to give you an example if you had to go solve a bug that's been reported and go Implement a solution for it if you didn't properly understand the timeline for that bug to be delivered and the priority of that bug you might end up spending way more time just reading through code trying to find things and the reality might be that the expectation of that bug being fixed on time is not being met however from your perspective if you're the person that's falling into this category you might be thinking well I'm not bothering anyone and I'm learning on my own the other scenario that I often see and I would argue is probably one of the more common scenarios especially with remote work is that people don't want to bother other people unfortunately with all of my efforts so far I still haven't put into practice something that I found really works but at the end of this video I'm going to share with you a tip from another engineering manager that they said really worked well for people in this situation now how do we get to a happy middle ground between these two ends of the spectrum well one thing that I like to consider is that there's some types of problems that I don't actually think warrant spending a lot of time on and I would probably summarize these types of problems as not gaining net new knowledge for the team so one simple example of something like this might be that if you're cloning down code from a repository and then trying to build it locally on your machine if you're running into a ton of build errors it might be worth spending a little bit of time to try and dig around and understand what's actually happening but this isn't something that I would personally spend a lot of time on and the reason for that is that it probably shouldn't be happening in the first place and someone can get you unblocked quite fast again understanding why the build is broken is not necessarily net new knowledge for the team but it might be worthy spending a little bit of time just so that you can learn all right so if we have a category of problems that we shouldn't spend too much time on what about everything else how much time should we be dedicating to those before we go and ask people for help if we're still stuck well I've simplified my recommendation for this down to the following when you tried out a couple of options on your own before you reach out to someone I want you to think about being the person on the other side that you're going to be asking for help and I think looking at it through this lens can really help you shape what you should be trying to do first if someone came to you to ask for help and they said hey look I have this problem can you help me the first thing that you're probably going to say to them is well what have you tried so far and usually I see this Branch into two different paths the first path is that someone says well I've tried nothing because I didn't really understand what I had to do so for us this is an interesting indicator because if you don't even know how to go solve the problem you've been asked it might just be that you need to clarify the problem and I do think that this is something you can and should ask early so that you're not sitting there trying to think if you're answering the right thing because someone should be able to offer Clarity pretty quick so that you're not wasting time the other thing that I see happen is that people say well I haven't tried anything yet and again if we look at this through the lens of the person that's being asked the question we might say back well if you understand the context of the problems being asked and you haven't yet tried anything perhaps you want to go try a couple of things first then come back and ask the question and we can see how to proceed and this is my go-to tip for people that are trying to navigate this essentially try a couple of things first and if you're still stuck then go to someone ask for help and try to explain to them what you've tried so far so that they know number one you've put in an effort and number two as you're explaining how far you've got they can tell you if you're on the right track or if there's another option that you might need to consider so let's wrap all of this up before I share with you that extra tip that I heard from another engineering manager to summarize we don't want to be on either end of the spectrum when it comes to asking for help all the time or trying to solve the problem completely on your own instead there's a healthy balance where we can be asking for help on stuff that's not net new knowledge for the team team and otherwise trying some things out on our own before we go to ask for help of course the additional piece was asking for clarification if you don't even know how to get started on the problem you're trying to solve because you don't fully understand the problem in the first place now thanks so much for watching right to the end and I wanted to share with you what I heard from another engineering manager the challenge that she had mentioned was that she heard that a lot of people feel like they're constantly taking from other people when they're asking for help and in this situation these people feel like they have nothing to give back and instead because they keep taking they feel bad and want to stop asking for help and ultimately end up staying blocked and I get it that feels really crappy if you feel like you're constantly using people and you're not able to give anything positive back to them but with this engineering manager had recommended was that there's actually an opportunity for this person to capture the learnings that they're gaining from the other person and sharing this back with the rest of the team now the format that's used for this could look completely different from Team to team and scenario to scenario but this is an opportunity where that person can give back because the next person that's going to have a similar question does not have to go to another individual to go ask for help and in fact by preparing a solution that can be shared out to other people this individual now might become a person that could be approached if someone else has the question so I thought this was a really cool way to empower you the junior engineer to be able to give back to the rest of your team and hopefully help motivate you to keep asking questions so that you can keep providing more answers to the rest of your team as well again thanks so much for watching and if you're very new to programming and you want to learn how to build some programs from scratch this video right here might be really interesting for you to get started foreign