What Should You Focus On When Advancing As A Software Engineer?

Transcript is auto-generated and may contain errors.

Hey folks, I'm just heading into CrossFit here after our long weekend. Um, going to go to a submitted question. This one was about advice on skills to look at when going to or trying to focus on that next level. Um, now the way this question's asked in the comments is essentially uh pretty open-ended. It's not on anything specific, but they had said say from going from junior to mid-level software engineer and then like mid-level to more senior software engineer. And so, just as a reminder, uh if you have questions, leave them below in the comments. You can go to codekamed.com and submit anonymously as well. This question or similar has been asked uh multiple times on the channel. Um, so if what I'm about to talk through is not like, you know, enough, uh, you can either ask again with more specific, you know, detail or you can check out other videos on the channel because, like I said, it's, uh, it's been asked in different flavors.

And I think I think that it's, you know, going to be, uh, something that gets asked over and over. And I think that's good because people are thinking about it. So we think about this kind of thing. Um, I think it's important to to kind of bring it back to expectations, which is a a common thing on this channel. So, sorry, there's something going on with my car. I think there's I think there's so much ice on the car this morning that something's rattling and it's a sound I haven't heard in this car before. So, give me one sec. It kind of just sounds like there's like two surfaces kind of kneading together and making a like a sound I just haven't really heard before. Um, we have to think about expectations, right? And so, regardless of all the things I'm about to say in this video, got to bring it back to uh conversations with your manager, okay?

because at the end of the day that is going to be the individual that is uh you know providing the ability for you to get promoted unless you're switching into different companies um which I mean is another way to uh get promoted right when you're kind of moving between places. that if you're at a current place and you're trying to, you know, you like where you work and you're trying to get promoted, uh, definitely level setting expectations with your manager is the most important part because I might be saying things and your manager is like, "Sure, yeah, that's fine, but like I actually need Billy to go focus on X and that's going to be the thing that I really want um to see done before I can be confident in his promotion or you know, that kind of thing." So, when we think about

that um and then we think about at different roles there's going or different levels of roles there's going to be different expectations for those I do think it's important to think about expectations in the current role and then what's what is in the next level I keep saying role instead of level my apologies um so if you are a junior working towards midle one of the things that for my experience working with juniors by the way context I've been an engineering ing manager for for over 13 years. Uh just as a heads up. So uh when I'm working with juniors, one of the things that I am looking for is like building momentum that you can start to build some independence. Okay. So that is like that's not to say okay like I want to give work to someone and they never ask questions or they they never consult with their team.

That's that's not what I'm saying. Um there is a a sort of a a difference between being independent and or having autonomy versus you know asking for help and collaborating just to be clear. So my goal is not to say hey look you know after I'm just making up a timeline after a year of being a uh you know in this level as a junior I expect that you're never asking for help. It's it's not that. it's that you're able to start taking on more ambiguous things and making progress on them or at least asking the questions to start solving them. Right? A lot of the time in the very beginning with early and career folks and and junior engineers, one of the things that we try to do to set them up for success is give them things that are mostly understood.

So the ambiguity is much lower so that we can say, "Hey, look, you know, you can talk to probably any person on the team and we'd all be pretty much aligned with what we want to see done with this." And you know, someone can probably point you to the spot or a couple of spots in the code that need to be looked at. Um, so you know, it's mostly well understood, not ambiguous, and the the scope of work is not crazy. So we want you to be able to work through this thing that is well understood so that you can deliver on it and you can start to get some momentum with these types of things and the expectation is of course in the beginning like you will probably have no idea what to do and that's totally cool right if you think about someone

working in an environment for the first time they might might even say like I don't even know how to get the code cloned down right is it multi repository, how do I build this thing um locally? What is what is the process even like for code reviews and builds and deployments? How do we ship our software? Like so many things to go through. So, of course, you're going to have questions in the beginning, but as you're building momentum, working on what is going on here, man. as you're building momentum. Sorry, there's a lot of a lot of dumb going on right now. Uh, as you're building momentum, working through these types of things, you are gaining that domain knowledge, you're understanding the system better, and you're you're building momentum on these types of work items. Okay? So, when we're thinking about going from junior to more mid-level, my perspective on this is it's about building up momentum, confidence, and autonomy.

Okay? And part of that is going to be the ability to take on more ambiguous work. Cuz if you're thinking ahead, right, you're thinking, I want to be able to get to the point where I am midlevel or senior and beyond. One of the things that happens like if I'm thinking about uh you know assigning work to to more senior people on my team uh at the highest level for me I'm thinking like hey look there's going to be problems where I have literally no no idea where we're going to get started on this right it could be that like someone has put a request in front of me or a challenge we have to work through or whatever and I'm like okay I can understand as a from a business perspective why this is important, etc. But I'm like on the technical side of things, I'm like I I don't even know where we're going to begin with such a such an effort.

And this like I have people on my teams where I know that I can go engage them and talk uh talk to them about this kind of stuff and they are able to handle such ambiguous tasks on the technical side, right? They they know what things to ask about. They understand the codebase, the architecture, um the direction that our services and stuff are are heading in. So they can start chipping away at this enormous problem to start getting different technical aspects pulled together. But they're only able to do that because they built up so much experience through all these other things. So there's like I'm trying to explain this because there's a obviously a big discrepancy between where you would be as a junior or where I would expect you to be to to moving in that direction. But it's about moving in that direction, right?

Ultimately, it's uh I'm not saying to go to junior from junior to midle that all of a sudden now you're expected to do that. Certainly not. But there's going to be more things that are ambiguous that you should be able to to start working through or at least you can start asking the right questions. So my advice in particular in this is like you know stay the course of like trying to build that momentum with some of your work items. And uh that's also going to mean that um you know always be curious but do reach out for help and try to try to take the opportunity to learn about what you're getting helped with and not just get unstuck so you can move on, right? It's not just about how do I how do I get this thing done faster? Not not necessarily the goal.

uh that's sort of a side effect that will happen if you focus on uh on like learning the domain better. So when you have someone who is more senior helping you out whether that's technically whether that's explaining um maybe not just code but like why we do things certain ways or whatever else um really trying to learn and understand that and take that in will help you become more effective in the next work. It's not every single time you ask for help like, "Hey man, like you click the buttons for me and then I'll just be done this faster. Cool." Like not not the goal. So junior to mid-level in my opinion is a lot more about um building momentum, starting to build that confidence up, and then the ability to take on uh slightly more ambiguous asks. Okay. So, I'm going to take the next little bit of this drive to talk about going from mid-level to senior.

And uh the thing that's still going to hold true is what I said uh already about when I'm thinking about my my most senior engineers that I have on the team. Uh the goal is to be able to work towards like we have these very ambiguous asks or really big challenges. how can we start breaking them down to understand how we would make progress on them, right? Like the most senior people on my team are able to do that. They're able to understand what other teams might need to be involved. Um they can talk about potential interactions with those teams. Um they also know that like the ask is not for them to go solve everything on their own, right? Like part of that is this understanding that like you know we have teams within an organization and hey like that team is responsible for X this one's responsible for Y.

Uh based on what I'm seeing here we're really going to want to make sure we're partnering with those teams. Um and of course like in my role as an engineering manager these things are are coming into play but my my most senior engineers are able to uh do a lot of that as well. they also understand the technical aspects uh better than you know than anyone else will. So if you're going from mid-le senior that direction right moving in that direction is still a focus. There's going to be bigger things that you've uh than you've worked on before. They're going to be even more ambiguous. You might be um doing more design work, right? when you are uh junior working towards mid-level.

I'm not saying you won't do any design work and obviously I'm not in a position where I manage all of you listening to this, but uh odds are someone who's a little bit more senior than you might be doing more of the design work for certain areas and you're helping with the implementation of it. And so going from mid-level to senior, you're getting some of those opportunities or getting them more frequently. And um you might even find yourself in a position where uh there's you know projects that you are leading right it might be smaller but you get to design something own it end to end I think that is uh something that I'm often looking for is that you understand the different part and understand and can execute on the different life cycle phases of a larger feature area which means um doing some type of design work up front getting sign off on that from your team, right?

Being able to communicate that to different stakeholders, getting the feedback, updating your design, basically getting people aligned on a direction forward and then starting work on the implementation depending on the scope of that. That might mean that I'm, you know, getting someone else uh more maybe more junior even to help out with you. uh or you know you're going to carry it out and I'll have someone more senior who can um you know that you can check in with to make sure that uh if you have any you know technical questions you feel like you have some some close technical support but you're owning that implementation end to end and delivering on it so that at the end of that you can say like from start to finish this is something that I had full responsibility over so when I have mid-level engineers that are

going for senior like my expectation is that I have confidence that they have been able to demonstrate that um and because that's what I expect of my senior engineers right so the the whole idea is being able to prove it before you are given the promotion because with promotions what we don't do is say hm I hope this person could like let me take a chance and give them the title and then hope that they can do it. It's no. They've been demonstrating that they can and therefore they will get the promotion. We got to get around this truck, man. Come on. Oh, man. It's the only way to do that. Okay. Was basically stuck in the left lane and there was a huge truck beside me and then the person in front of me also decided to not only block me in but then take up their time merging over.

But we made it. Okay. So that's a big part is being able to own uh you know feature design end to end. This will look different um in different places, right? Like at I've made other videos about this, but um like at at Microsoft right now we at least on my team in particular we will have you know design docs and stuff up front where you're kind of working with the subject matter experts on your team to get sign off. We present those to the whole team so that people can learn about what's going on. Uh that's another opportunity for some feedback and you go implement. uh you are stake you are working with stakeholders that are your engineering uh peers on on your team and that could be not only like your they have like feature crews that are sub teams uh so not

only in your feature crew but maybe even some of the other engineers across the feature crews um uh product manager your engineering manager so we do that and uh I can recall you know being at a startup and we did almost none of uh you still get the collaboration but like uh in terms of like writing up design docs and stuff a lot of the time that just wasn't how we operated so can look very different. One of the other things that I think is critical in terms of my expectations of someone going into senior is uh and this this has many shapes uh and looks different ways but uh like some mentorship capabilities. So I expect out of my seniors that uh they have uh the ability to and they've demonstrated that they they do help people on the team.

That could be helping doesn't don't think about levels necessarily like oh like you have to you're you're babysitting the intern or something like that like no it's not um if you can help out the intern on the team that's awesome. If you can help out someone that's more junior than you awesome. If you have a peer that is uh working on something that you can help them with, awesome. You might even have situations where there's more senior people on the team that you are now building um in areas where you are becoming the subject matter expert and they're not. So you can help them if they have questions and guide through things. The point is that you are helping other people on the team become more effective, right?

you are showing that you have uh the ability to level up the team around you and that can look different uh so different in many different uh areas that could be you know something like writing okay well people are struggling with this I'm going to write better documentation in this area um I'm going to hold a knowledge sharing session I'm going to you know I'm I've been doing kind of like guided one-on-one walkthroughs where people are working in this area to catch them up on stuff. Like it could be anything. But being able to have that kind of impact with individuals on the team, this ultimately is going to mean that if I have a team of engineers, I can start leaning on uh people beyond my juniors to help other people on the team more. So I'm always encouraging people of all levels. you. Everyone has something beneficial to offer.

You might not realize it, but everyone does. And being able to lean into that to help those around you is extremely impactful. So that is an expectation I have of uh people moving into senior roles. So if we think about what senior looks like and again level set expectations with your manager on this for me that looks like the ability to uh to mentor and help others on the team more consistently. So you are demonstrating that you level up those around you. Okay, that's one part. Another part is being able to own larger features end to end through a design phase in the beginning and an actual implementation phase and and delivering on it. Uh, by the way, depending on where you work and what your product or service looks like, that doesn't just mean pressing submit and uh, code is checked in and you can walk away from it.

Uh, there's often a lot more that goes into it like uh, how it was validated, taking responsibility for it after it's been, you know, shipped or integrated, etc. And then what was the other thing? I thought there was one more thing I wanted to say there. I might have been trying to think about like ambiguity around things, but that's uh yeah, maybe that's the the other aspect when I'm talking about like owning features end to end. The type of work that you're able to to dive into has more ambiguity around it. So, it's more complex things. It's not just more things. It's not like, okay, well, I was able to do, you know, five tickets of sprint before. Now it's got to be 30. Like that's we just multiply it and get some senior scaling factor. Um not how it works. Okay. So it's about the type of work as well.

Hope that helps to start with. Like I said, there's other videos on the channel about this kind of stuff. I'm late for CrossFit. See you later.