What Is The Best Way To Get Up To Speed On A New Project As A Senior Developer?

Transcript is auto-generated and may contain errors.

All right, folks. This is a question from the comments. This is from Epic Technav. Thanks for coming back with another question. I appreciate you being here because you've had a lot of good questions. And this one says, "Question, best ways to get up to speed on new teams uh and projects as a senior dev." Excellent question. I think this is going to look different for many people. Um, but I'll give you some framing. uh I've I have talked about this before and I have compared even as an engineering manager coming to a new team like my approach my recommendation would be similar to what I do as an engineering manager but I would tailor it a little bit different so I'm going to talk through and then we'll kind of dissect and see how it might um how you might give more weight or more

importance or significance to some of these other pieces okay so first thing when I join a team uh as an engineering manager I don't try to change anything Step one, I am there to observe and to learn first. I would say similar thing as a engineer joining a team regardless of your level. Um, in fact, the more senior you are, the more I would try to be careful about not coming in and just like trying to change what everyone's doing. Um, the reason I think that is for a handful of reasons. One is that you don't have enough information to do that. So, you might have some ideas and you're like, "Oh, this would be perfect." You don't know enough yet. You simply don't. And that's okay. Don't do that. Number two is that people will resist. Even if you have a really, really, really good idea, people will resist change because you have not worked with them long enough.

They're not part of the uh the change. You're just coming in and imposing things. So, do not rush to go do that. Please, it's going to cause friction instead of being helpful. So, part one is going in observing and trying to learn. Okay. The other thing that I do as an engineering manager and I think can be very applicable still for you as a software engineer is that I need to spend time learning the people on the team. For me, this is the most important part as an engineering manager because if I'm going to be managing people, I need to spend time building up trust and respect from the beginning. It is the most important thing for me because if my team does not trust me or they don't have respect for me, it's going to be very difficult to lead them. And both of those things, trust and respect, are not things that I can command or that I can ask for.

I can't just say, "Hey, I'm I'm new to the team and like I am the principal engineering manager here, so that means you have to respect me." And I have a lot of experience, so just trust me. It just doesn't work. Don't do that. Um, so I need to be able to prove to people over time with consistency that I follow through on my actions. I need to show them that I care by listening to them, understanding them. And these things take time. So I start from the beginning early making sure that I am listening and learning about the people on the team. I do recommend that you do this as well. You may not have to invest as much time or go as deep on this kind of stuff. Um, right? Like for me, I need to create like really help create an environment where people feel like they not that they have to, not that they have to, but that they can come to me and talk about anything, right?

I am not a therapist, simply not. And I don't pretend to be. But if someone on the team that reports to me is having a really big problem and they're like, I don't know what to do. I I need them to feel comfortable at least that they can tell me. They don't have to, but if they're like, Nick, I need I need the day off. I I gota or something's going on like I don't I don't want to talk about it but like I need next week off or whatever. I just need them to be able to have enough transparency with me and they trust me to be able to do that kind of thing. If they can't then it starts looking like like I have to guess at what's going on or they're avoiding me.

Um, and I think as a software engineer, the reason that this is important is that when it comes time to start proposing change, right, or to get buy in on your designs or um, when you are approaching things like whether it's conflict or difference of opinions, that kind of stuff, you want to be building up the trust and respect early on. It's also going to help you really understand who's a subject matter expert where, which is going to be super helpful because that's going to bring us to this next part, which is like learning the system. I don't know if you can hear my wife. She's watching the CrossFit games. I don't have my door closed and she's um yelling at the TV. Not in like a bad way, but she's like very excited watching CrossFit. home. It's very funny cuz no one else is home and she's talking to herself.

But um this next part, she's going to kill me if she ever watches one of these, but she doesn't. So that's okay. So this next part is about learning the system. And as an engineering manager, sorry, I am also getting paged as a backup on call. So let's see. I don't edit these videos, so you got to deal with it. Um, okay. I'll wait to see on this one if my primary needs me. So, um, learning the system is going to look different for different people. I think as more junior developers, you're going to be spending time in a more specific area, more narrow to begin with, right? because you're not going to be tasked with rewriting the whole system or architecting huge uh features and changes and stuff like that. So, you can spend more time going more narrow.

I do recommend you understand a very high level of what your system or service or product is doing, but that might be overwhelming if you try to get too much of it all at once. So, getting into a spot, learning it, it's good. As you're as you're more and more senior, I think it's important to to kind of like approach things from both sides. you're going to likely be working in a particular area. So, you probably want to be exploring the code base, understanding that, interpreting that, going through code, going through pull requests, like all of this kind of stuff, but also spending time with those subject matter experts we were just talking about and getting them to walk you through different sort of like areas of the system so that you can learn and understand them, right? It kind of has to happen from both sides.

If you just do a top down or like sort of high level and try to zoom into everything, you may find that like it's overwhelming. And if you only go the other way and you're just looking through code, you may have blind spots like, okay, I know I see what this class is doing and this class is doing and how they're connected, but it's only like a small part of the system and it might be overwhelming. Again, trying to do the whole system that way. So my recommendation is come at it from both angles and absolutely leverage subject matter experts for pointing you towards documentation uh video resources and andor spending time with them whiteboarding stuff. Um, I do recommend that you try doing this and then having this opportunity to almost like share back with them your understanding, right? So, when people are walking you through the system design and stuff, don't just like sit there listening and then say thanks and hope you remember it.

Try like demonstrating it back to them. Try confirming your understanding saying okay, if I understand correctly, you're saying this part of the system's connected here, data flows this way. So, like draw it back to them. ask them questions about your understanding. That's what I would recommend. It's like kind of this like two-way approach to learning. Um for me as an engineering manager, it's almost all the top down almost all. Um fortunately for me like I have been managing teams that know C andnet when I was an engineering manager at Magnet Forensics before Microsoft I was also an individual contributor at the same time. So engineering manager and IC for eight years in parallel. So I wrote the code with my team made it very easy to understand the parts of the system.

uh now like the last five years at Microsoft I can do code reviews for people but if there's very specific domain areas that I don't understand really my value for looking at code is like general software development practices and I know a lot about C so I can help with that but there's going to be nuances as parts of the code base that I don't get and I don't think that I should be expected to know that and over time I will get more and more exposure but what I'm trying to point out here is like My understanding as an engineering manager is a lot more like system level versus like specific areas of code. And if you're a senior engineer joining a team, you're going to have to find a better balance of that. So definitely want to understand the system, but you will have to start learning areas of the code more specifically.

So I hope that helps. Um that's what I would recommend. And if you have like more followup to that about like getting onto the team, like maybe you have a follow-up question around like how do you start driving change once you see it, we'd be happy to talk through that. But I'll wrap this one up here. So if you have questions that you want answered, leave them below in the comments or go to codemute.com. You can submit a question anonymously. I have three other YouTube channels. The first one is just devleader. That is my main YouTube channel. That's where my car.net and programming tutorials are. I am splitting that one out into two other channels. One will be for podcast and live streams. So podcasts are where I interview other software engineers. You can hear about their career journey and the cool stuff that they're doing.

And the live streams that I do are going to be AMA style. I've done hundreds of these now. I think I think it's over a hundred now. Um so please join me there. Ask questions. Would love to see you there and answer anything I can for you. And the third YouTube channel is where I do my resume reviews and I will be trying to add things for like interview help and stuff like that as well. So that one's called Dev Leader Path to Tech. So thank you so much for watching. I will see you next time. Take care.