Software Engineers - Your Job Isn't What You Think It Is!

as a software engineer your job is not to write code your job is actually to solve problems it's just that writing code is one of the tools that you have at your disposal that you end up using an awful lot and that might make you a little bit uncomfortable to hear that your job is not to write code but it's true it truly is problem solving if I had an engineer on my team and he or she said that they had a solution to a problem that didn't involve writing code I'd be very interested in hearing about that in fact if they had potential solutions that involved not doing much or any work at all even better and I think that this is hard for people to hear because as programmers software developers software Engineers whatever flavor of the term you want to use a lot of us spend time on the technical skills that allow us to write code more effectively and while there's nothing wrong with getting better at the technical skills there is something wrong with neglecting problem solving but that's not you you're here to watch this video and learn a little bit more about problem solving so with that said in this video we will cover some beginner are ideas around problem solving in software engineering and get a little bit more advanced from there and then talk about maybe what that looks like as a senior software engineer compared to someone that's a little bit more Junior okay so with Junior software Engineers whether that's someone who's coming fresh out of College University school or just kind of getting into their first programming related job I have this conversation an awful lot with people and it's because there's a pretty big discrepancy that I see between people getting started where they're effective or they're not and of course there's a lot of variables at play with people starting jobs past experience things like that the environment they're working in however one thing that seems to be pretty common to me is that when people have problem solving experience where they're naturally sort of aligned to solving problems I think that they end up performing a lot better right from the get-go because they're actually doing the thing they need to be doing I want to walk through an example that's going to kind of compare two different people starting off in their first program programming job and this is actually a pretty common thing I see so while it's going to be a made-up scenario the types of things I'll be talking about are actually things that I've observed so on one hand you'll have someone who starts off in their job doesn't matter if they're remote in person anything like that but what they end up doing is they get a set of things that they need to work through so their first work items whether that's solving bugs or you know implementing their first feature and what ends up happening is they either get blocked and they're sitting around waiting because they're not exactly sure what to do or they reach out for help right away and for this particular person if they're reaching out for help what they end up doing is kind of focusing on like what do I do so they'd reach out and say like hey I'm stuck what do I do and then one of the traps that a lot of us fall into is that as more experienced developers we say oh well it's you know just do this and we give them the answer that person goes off and then a little bit later they come back and say okay I'm stuck what do I do and if we keep repeating this if we're not being good senior software Engineers we keep giving them answers and what this is feeding into is that this person that you think that you're helping is actually not problem solving they're being resourceful and that they found someone who can give them answers they can almost like do the work for them but they're not actually focused on problem solving and I'm going to give you the counter example then kind of walk through like how you can kind of change this up from from both sides and the counter example here is say someone else it's started and when they're getting stuck what they end up doing is they explore a little bit right so they're looking around for different opportunities different options they can pursue and then they reach out because they're stuck and they say hey I'm stuck I've tried you know X Y and Z or Zed if you're from Canada and you know I've considered these options I'm actually not sure which one's better but here's what I've observed by exploring them you can tell right away when someone's done this they've actually done a little bit of work up front to start exploring and start looking at the problem now this doesn't automatically make someone an awesome Problem Solver but I think it's a really good first step because it's showing initiative that they're trying to get through the problem versus just end up at the solution and I might rephrase that a little bit so it's not about just ending up at the destination but actually trying to learn how you get there so to reflect on both of those the first example is someone who's basically in my opinion just kind of being resourceful they're kind of looking for the person who can give them the next answers so that they can take the next step and they don't actually practice like how do I get there they're just how do I find the person with the answer so that I can do the thing the second person that I was describing is actually focused on learning about what steps do I need to take to understand things to get to the destination in both cases asking questions is totally fine right there's nothing wrong with reaching out asking for help but I think there's something to be said about asking for help without actually doing anything up front so with that said if you are someone that's a lot newer to software development software engineering and you're thinking about okay I've just started my first job let's say or I'm about to if you're in a position where and it's going to happen it's totally normal so don't worry but if you're in a position where you're thinking okay like I've been given this task that I need to work through I feel like I need to ask questions I think the two different flavors of questions that you're going to be looking at are one clarifying questions because someone might have asked you you to do something and you actually need something clarified you can't actually approach solving the problem because you might not actually understand what problem you're trying to solve right you're not exactly sure what was being asked of you or you need some more information to take some extra steps so to me that's the first category of like clarifying questions and then the second flavor is really about you know what direction do I go in like what's the better option now both of these things will come up it's not like one of them is right and one of them is wrong you're going to need to ask for clarification that's totally normal but if you find yourself in this sort of second category of hey like I need to figure out which direction to head in I think that this is a really good opportunity to pause and say okay if I'm about to go ask for help what I would expect this person to say to me is what have you tried so far if you're expecting that someone's going to ask you that and you're pausing to think about it this is a really good opportunity for you to answer it for yourself so if you haven't tried anything yet right you know what problem you're trying to solve because it's not a clarifying question you're trying to ask you know what you're trying to solve but you haven't tried anything it's probably a good opportunity to try something it's probably a good opportunity to look at different options that you can consider and in my opinion the more that you try practicing this the more that it will feed into your problem solving ability because in order to answer that you'll actually have to do some analysis you'll have to try and understand the problem more and by going through the motions of that you might find that by the time you want to go ask someone for help on it just the act of trying to put that information together you answer it for yourself in fact I've had situations in my own personal experience where as I'm typing the question to someone literally writing it out on a keyboard I go never mind I backspace it and I go I know the answer just from typing it it seems unusual you probably don't believe me if you haven't experienced it but I promise you if you practice this that type of thing will come up more where you can answer your own questions and really it's just because you did the work up front now if you're someone that's more senior and you're working with people like this what I urge you to do is what I kind of just suggested a little bit earlier when people are coming to you with questions try to consider are they asking for clarification if so give them that clarifying information right just try to make sure that they understand so that they can go take those next steps and if they're asking the latter the second question that I was posing it's really a matter of like what direction what steps do I take that's something where you do want to push back on them gently of course saying like well what have you tried if you're finding that people are coming to you all the time and they haven't actually tried anything encourage them to try something first right make sure that they have a safe place so that they don't feel like you know there's no stupid questions people aren't going to be scolded for asking about it nothing like that you want people to feel comfortable but you do want to encourage people to explore and problem solve as well so if people come to you and they're saying hey like well what do I do what's the next step you might know it you know you might be able to copy and paste a line of code or type it in two seconds or something and you can have the problem solve right away but that's not actually teaching someone how to problem solve so I do encourage you to kind of push back to them and say well what have you tried and if it hasn't been anything yet say well why don't you go explore a couple of options first why don't you if it's the first time through like why don't you try something first go try that out come back let me know what you see and let's talk about what you found going through an exercise like that actually starts encouraging people to go problem solve on their own and again because you've made sure that it's not a clarifying question that they're asking up front they're not going to go back and just get stuck and be I don't even know like what I'm trying to do because they have that clarified already it's really about like what direction do I pick and if you've given them that safe place like go try something ideally that gives them enough confidence to go try something now of course I'm not suggesting this is like a perfect solution in all cases but this type of pattern this little framework is something that I encourage people to do so whether I'm coaching Junior Engineers on the side of like hey like how do I approach problem solving I'll give them that advice for more senior people I've had people say like hey like this person you know I'm spending a lot of time like I just have to keep giving them answers they keep coming to me I need to coach those individuals usually a little bit more senior right like here's how you What's the phrase like teach a man to fish or something right and then they can keep go fishing um teach a person Teach an engineer to problem solve and they can go solve their own problems kind of thing that's the approach you want to be trying to take it's not perfect but I think it works pretty well for my experience okay now I want to touch a little bit more on what problem solving looks like as you become a more senior software engineer now of course in one video I can't possibly cover all of the different topics of all the different types of problems you'll be solving as someone that's more senior but to clarify as you become more senior as a software engineer generally what's happening is your scope of impact is getting greater right so the work you're doing is going to have a bigger impact generally and the other part is that your area of influence your circle of influence is going to keep growing so as a new developer somewhere you might be working on smaller fixes smaller features kind of working just within the team maybe on your own and then as you become more senior you might start doing some cross-team activities the features that you're delivering are involving more stakeholders or higher impact so it's a general pattern that happens but but that means that the types of problems you're solving are going to shift as well now the first one that I'd like to talk through is very similar to what we already talked about in this video and that's teaching others to problem solve this is a really common theme that I have with people becoming more senior which is teach them things like you want to level up the people around you it's this concept of leadership without actually having a formal title to do so right you don't need to be a manager or like a dedicated team lead to have influence around the people around you and emulate behaviors that you want them to have so in this particular case we're talking about problem solving okay demonstrate to the people on your team like you know problem solve in public if you have problems that you're working through send out an email about you know the results of that or if it's not an email heavy culture I work in exchange area at Microsoft there's a lot of email so if it's not an email heavy area maybe send messages on teams and if you're not at Microsoft using teams slack whatever right like send information to others that are more Junior like here's how I walked through this problem here's how I approached it did my analysis give people examples and when they're coming to you asking for help you want to coach them through how they can problem solve as well so finding all of these opportunities where you can help others problem solve I think is critical I think that it's an easy trap to fall into where you're just giving other people answers to things it's uh I say a trap because often when you're feeling that pressure of like you know I have all these maybe more Junior people coming to me asking for help you want to just be like oh here's the answer go away here's the answer go away like I want to make sure I can keep doing my work but the problem with that is that it perpetuates it so you do want to keep teaching people how to problem solve and of course in general just how to be better Engineers so they can emulate your behavior and get better but what other types of problems might you be looking at as someone who's growing an influence an impact with the work you're doing one thing that comes to mind for me and this is applicable to all levels of engineering but there's a example that I want to walk through here is breaking down complex problems into smaller ones so if you have something that you're working through and the problem that's put in front of you the challenge you have to accomplish is quite complicated and it's large area of impact might be you know spanning multiple teams or multiple people to work on the complexity is great and as a more senior software engineer you want to think about taking all of that complexity and trying to break it down into smaller pieces I did mention that in general for software engineering you do want to practice this but it's really applicable here because if you're working together with other people or you have other stakeholders understanding how to break down complex problems into smaller pieces means that other individuals other stakeholders can be involved so to make up an example that sounds kind of silly maybe you have to go make an entire service to go do some function and that's going to be the task that this group is responsible for and if you were not good at breaking down complex things into smaller problems you might tell the stakeholders well yeah I'll just I'll code up the service and it'll be done and you know it'll it'll do the thing right I'm exaggerating a little bit but or a lot of it but if you had the ability to break down that complex problem like what's involved with that service what you know what other things are is it going to have to interact with like how can we have other people working on this in parallel you know there's three other people in the room that are going to be involved here like break down that complex thing into smaller pieces so if you can do that and make it more modular then other people can work on it you can break down things into different time Horizons like you have smaller problems to go solve I think this is super important for more senior software Engineers because without it you end up having these problems that are really difficult to work through they're ambiguous they're nebulous and the people that are responsible to stakeholders to try and get the results out of that you'll find that you have a lot of friction with them if not everyone is aligned about how that problem is going to be decomposed another great example about problem solving is a more senior software engineer I kind of hinted at the beginning of the video and that is if you can solve problems by avoiding doing work that can be really powerful in business we're always being pulled in many different directions and the more senior you become as a software engineer the more exposure you get to some of these business needs because you start looking at things more holistically and not just as individual features in and fixes so the more that you start to understand like the implications of deadlines timelines when things have to line up to be delivered to other partner teams or to customers the more that you realize like we don't have infinite time to go do all of this so as you're trying to solve problems if you can actually like the first example break them down into smaller pieces if you have opportunities where you can say hey look if we do this a certain way we don't actually have to do this other work that could be really powerful and being able to make progress and moving forward as software Engineers you free up time to go work on more important things and ultimately what that's going to do is allow you as a team to go deliver value to customers faster and one more type of problem solving that I want to talk about for more senior software Engineers is having this ability to kind of see beyond the current problem so what I mean by that is as you're solving the problems that you're being tasked with and using all the examples we kind of just work through you want to be thinking about well what could be next it doesn't mean that you need to over engineer everything to try and accommodate every possible solution going forward that's definitely Overkill but if you can be thinking about okay like I'm aware that the you know the vision of the current team is that we want to be moving in this direction I've heard we're scheduling this work coming up if you have these other insights that you can bring in and you know the vision that your team is heading in you can take this opportunity to say cool we can solve this problem and if we had say two or three options you might change which path you're going down if you have reason to believe that one of these paths will be better suited going forward now again that does not mean to go over engineer everything my point here is just trying to take some information about future state that you might be aware of from some other context and trying to incorporate that in your current problem solving and again if you can demonstrate that to more Junior folks on your team saying hey look like we know about this other business value that we're going to be pursuing that might be an opportunity for them to go hey like I should pay attention to this kind of stuff because it does seem to be valuable all right so we'll wrap it up there I know you're probably going well what about solving problems like this or that I know there's a million different types of problems that you're going to be solving and that just proves my point that as a software engineer you are a problem solver not a coder first so to summarize this video we talked a bit more Junior software Engineers being in a position where if they're asking for help they want to be thinking about first is it a clarifying question I'm trying to ask or am I trying to ask on which direction I should take you find yourself asking which direction should I take be ready to offer up the examples of what you tried so far and for more senior software Engineers the advice was you want to coach the Juniors through that don't just keep giving them answers push back a little bit teach them to problem solve that was the first big part the second part was breaking down complex problems into more manageable problems to solve that's going to be because you're going to be working on larger impact things with more people and you want to be able to have smaller problems that everyone can work through and the final thing we touched on was this idea about looking beyond the current problem when you're more senior and you have some of these additional contacts of information you can pull from so I hope you found that helpful I hope you enjoy problem solving because if you're a software engineer you're going to be doing an awful lot of it so thanks so much for watching and we'll see you next time