What to Focus on FIRST in Your New Developer Role

Transcript is auto-generated and may contain errors.

Hey folks, I am doing a lunch break code commute because I'm working from home all week this week and I didn't film all the way to CrossFit cuz my wife drove. Okay, so this one is from the comments. This one says, "Hi Nick. I start my new job today at a new company as a mid-level engineer. Congratulations. That's awesome. I was hired as a front-end dev and the company's tech stack is React using Webpack, TypeScript, PHP, and AWS." And they said, "For context of those technologies, I don't know PHP. What do you recommend for new hires to do their first day and even week?" And this is from 9923rs. So, thank you very much for the question. I responded quickly on YouTube saying like, "I'll get this video done, but it's not going to help your first day because you'll already be done." Um, but hopefully I can get it out tomorrow or the next day, so it'll be out your first week at least.

But first day is kind of uh missed from me being able to help you. So I apologize for that. But friendly reminder for folks, this channel is driven by your questions. So if you have a question about software engineering or your software career, leave it below in the comments. Happy to try and answer. If you are not comfortable leaving a public comment, you can message Nick Cosantino on LinkedIn or you can look for Dev Leader on any social media channel. It's also my main YouTube channel. and then send me a message and I will keep you anonymous and make a full video just like this one for you because odds are your question is gonna help other people. Okay, so there's a lot to unpack in a open-ended question like this like what do you do in your first day and first week? Um it's going to depend a lot on the company and like sort of your your ability to get onboarded which is going to be partially on you, partially on the company.

I find that most companies, and I don't have stats on this just as like anecdote, but I feel like most companies do a pretty bad job with onboarding. I feel like it's pretty rare that I hear about companies that are like people like rave about how good the onboarding is. So, unfortunately, that seems to be more common. um in your first day um depending on like how many onboarding activities and stuff they have prepared for you at the company that you're at cuz sometimes they like places will overload this for you. But um if you have time I would say try to get your development environment set up like that's a really nice milestone to try and get that done in the first day.

depending on the complexity of the stuff you're going to be building like you you know maybe you get most of the way there or something maybe you I don't know like at Microsoft when we have to get credentials and stuff in sometimes it can take a little bit longer to propagate so you can get like most of the way through but like you couldn't get a a poll request up or I'm just making this up right you might not be able to get a pull request up because some credential or some authentication some eligibility has not propagated through the massive system yet. Ideally, we can get ahead of these things, but I've seen scenarios like this where it's like, okay, got you most of the way.

But being able to like have code running locally on your machine or compiling locally, depending on what you're building, I think is a really awesome milestone to work towards because if you aren't in that position, like the longer that you're not in that position, the longer that you're not able to like contribute tangible value, which feels kind of crappy, right? Because I think for a lot of people, especially when they start, they're like, "Okay, I want to make sure that I can hit the ground running. I want to be like an effective member of the team." But as long as you're not able to actually develop locally, you can't even like get a head start on that. So, I think that's a really good milestone. I think that it's really important to try early on to have like networking happen for you. So, was it the weirdest way that I possibly could have said that my brain is apparently not working?

I think you should try networking early. There we go. And that means like starting with your team members, right? So, uh I'm not saying to like necessarily fill your first day like trying to book one-on ones with people and get on calls and whatever, but I think it would be good to try figuring out early if you can uh understand like you know who subject matter experts are in different areas. if you can make time to have someone sit down with you on your first day and walk through like high level what the system does uh or uh the domain cuz sometimes you might be working in a domain that's completely different to you. To give you an example, I used to work at a digital forensics company. How many people watching this have experience in digital forensics? Probably zero. Did I have experience in digital forensics?

Absolutely not. It's not a thing that's common, right? So um you know for me when I started at that company it was like we didn't we didn't have the luxury of having onboarding like that. I remember one of the first like technical conversations with the CTO who like he could write code so he's not a software engineer but he was a police officer and did build this tool and does understand digital forensics. He was talking to us and he's like, "Okay, how many people understand like, you know, like NTFS, file systems, FAT32 or like just these concepts?" And I just remember being like, I've heard these words, but I just don't know, right? I don't know. And so going through something like some type of training uh for onboarding into a domain, I think, can be very helpful. If they don't offer that, then I would see if you can have someone make some time with you to go through that kind of stuff.

I think there's an interesting opportunity in all these things I'm going to be talking about here, which is like if the documentation or the training doesn't exist, if you're going through this stuff, you can make a huge difference in trying to capture some of the learnings as you're going through. If there's onboarding documentation, keep it up to date as you're going because odds are it's out of date as soon as the last person touched it. It's just it's always documentation is always out of date. So use it, try to update it so you can help the next person get a head start. And that same philosophy you can apply to your onboarding experience. Are there just things completely missing? Is there no domain related training? Cool. Like take some notes. You might be able to make, you know, on your uh your team's like wiki page or something.

I don't know. I'm just making this up, right? You can start trying to collect some of this information. And it might not be perfect to start with, but it's a starting point because anything like this is going to be a work in progress for forever, right? The information will go stale if people aren't updating it. But you having a head start to start contributing towards that, I think, is extremely helpful. So, um, networking within the team, right? Try to learn who the subject matter experts are. Try to sit down with them, see if they can teach you about the domain andor the product or service. Anything that you can start gaining information from people, I think, is going to be super helpful. Um, trying to get time with your manager on your first day, I think, is extremely important, right? Um, I think it's kind of crap if you start and your manager's like, "Oh, like I was already booked up the whole day." like really like I don't think it's a good move.

Um does it happen? Sure. There's always excuses for things that are legitimate. I would just hope that you can get some time with your manager in your first day. Um if you don't have something like an onboarding buddy, which might sound like a silly kind of phrase, but I would say try to early on. So like when you're starting, try to figure out if there's someone who's been appointed to be your onboarding buddy. And if not, see if you can kind of create that relationship with someone where it's like like you know someone who like depending on your team or how things are grouped up like I'm I manage I work in part of a routing team, right? But so there's a few engineering managers. Then underneath us we have a few feature crews. So we kind of split our team up even more into feature areas.

And so if I had someone hired into one of those feature crews, I might try to pair them up with someone else in the feature crew that's more senior, right? So you can see what the lay of the land is and see like, okay, if no one's set up something officially like that for me, is there someone else in my like feature area or whatever that is more senior that I can kind of like, you know, leverage to be your contact, right? To to help you on board. Um, I I think that it's from a comfort perspective, I think people really value having like a person that they know they can go to. So, if a company doesn't really like I don't know, like set that up for you, it kind of sucks. But don't limit yourself to only one person on the team cuz I think that's one of the side effects of having like an onboarding buddy.

It's like, oh, my buddy doesn't know or my buddy's in a meeting or my buddy's they took vacation or they're sick, whatever it happens to be. and you're like, "Oh, well, that was the only person I connected with. Now, it feels like super awkward to reach out to anyone." Start the networking early. Um, I say this too as someone who is introverted. Um, you may not know that because I make a bunch of videos on YouTube. I am very introverted. I lose a ton of energy doing people stuff, which is ironic as an engineering manager because I think people stuff is the most important part of my job, but it also takes the most energy from me. So, I know what it's like to join a team and being like h like this guy, this bald guy on the internet saying I got to go talk with the team and get to know people and stuff like like it's going to be so much effort.

I get it. But honestly, what's going to be a better outcome? You try getting a head start on that and it might be a little bit uncomfortable. I hear you. Or you go a week and you're like, I haven't talked to anyone on the team. and you go two weeks and you're like, I have to start reaching out to people. Oh, but it's been a little while and like you start secondguessing yourself and like it's all awkward. Just get into it because people genuinely want to help you. I have never been on a team in my career. I'm not saying it's impossible, but I've never been on a team where people didn't want to help. If you are making an effort and trying, people want to help.

If they're helping you and you're not doing anything to try and learn or get better, eventually people get frustrated with that and they're going, "Why do I spend time, if they're not making an effort and I have to keep teaching them the same things?" So, generally people will respond positively even if you're asking them more questions, if you're proving that you're like sort of advancing and that you're getting value out of uh the help that they're providing. So, um do ask questions, right? talk to people on the team. Uh from a technology perspective, like I don't know um if this person was hoping that I would answer on the technology front, but I would say like okay, uh they listed a few things, Webpack, TypeScript, PHP, AWS. Um they said I don't know PHP. Great. Like, you know, I don't think that's a big deal. Uh you know, other I'm assuming you know other programming languages.

TypeScript was in there. So that's at least one. Uh I find especially this person said they're mid-level. If you know a programming language and you're comfortable in it, learning the next one, not bad. Uh it's going to feel like your thumbs might be tied together for the first little bit, that's fine, right? You're you're going to see the commonalities. You have to practice the syntax before it's more familiar. There'll be lots of examples for you to look at. You will be okay. I promise. Um I person like I'm a bit of a hypocrite this way. Like I basically only program in C because I like C. Can I use other languages? Absolutely. Do I prefer to? Absolutely not. I just like using C. But like even for the software I'm building on the side, Brand Ghost, Brand Ghost, our front end isn't Typescript. So I have to know Typescript.

I have to be able to work in it. I just don't like to. So my preference is to gravitate towards things that I like. But in your case, because it's going to be like PHP is going to be the thing that you have to know at work, I would say like, you know, don't don't fear it. Like it it's such a weird thing, right? Um I know some of this stuff sounds like a tangent. I promise it's it's going somewhere. I was even talking to my wife about this this morning when we were driving to CrossFit and um I'm going to give you two examples. The first one was I was talking about CrossFit in general and I was saying that it's easy. It's been easy for me to like skip the workouts where I'm like, I don't like it, right? Oh, it's just going to be running.

Like there's no like there's no squatting. There's no deadlifting. Like the stuff that I'm good at or overhead pressing. I'm like, it's like running and burpees. And I'm like, that's so dumb. I'm not going to go do that workout. It's too easy for me to skip it and just be like, I'm not going to wake up at 5 in the morning and go. But then what happens over time is when that stuff is included in the workout, I'm like, I hate doing this. Why do I hate doing it? It's because I suck at it. Why do I suck at it? Because I keep skipping it. I don't do it. Right. So, I'm I'm getting to the point, and sometimes you have to like learn the hard way. But I'm getting to the point where I'm like, if I want to stop hating running so much, I got to stop sucking at it.

And that means I actually have to do it. It's really not that bad. It's not. I'm just bad at it because I don't do it. And it's a vicious cycle. The same exact thing happened to me with public speaking. I've already said on this video, I've made I think like over 600 YouTube videos, maybe close to 700 now. I think I've live streamed over a hundred times. I'm not sure. Maybe. But like I do live streams. I do these vlogs that don't get edited, right? There's almost 300 of these vlogs alone. It's good practice just for speaking. Um I used to always say I'm bad at public speaking. I hate doing it. I'm afraid of it. But why? Because I don't do it. I never did it. I would avoid it from, you know, as early as like elementary school and the teacher would call on you to answer questions.

I'm like, I'm not speaking front of the class ever. We had to do presentations for projects. I hate it. I hate it. I hate it. I'm so bad at it. Why? Because I don't do it. So, I learned from doing content creation and stuff like this and then doing live streams. I think live streams helped a lot. I'm like I'm not actually bad at public speaking. I don't I've been I don't know if I enjoy it because like I don't I don't really speak in front of audiences, but I don't actually think I'm bad at it. And why do I not think that? Well, I have YouTube channels. I do this all the time to a camera.

there's people on the other like right now as I'm recording there isn't but when I do live streams there absolutely is there sometimes hundreds of people on the other side and I mess up all the time or there's technology problems whatever and I'm like the more that you do this the more that you realize like no one actually cares so are you bad at it I don't know just practice more right so I learned through public speaking stuff like doing YouTube and then I learned like kind of my lesson with CrossFit is like when you suck at something, you got to do it. Like you have this vicious cycle. So I'm not saying this person's necessarily afraid of PHP or something. I'm just trying to give this advice for people in general, which is like don't fear these things because if you're like, "Oh, I don't know PHP." And again, I'm not saying that they're taking this angle.

But if they were like, "Oh crap, that's going to be so hard. It's going to be the worst." Like, no one's expecting that you're going to be a PHP god on day one or week one. Week two, yes, you better be the best in the world. But in all seriousness, like you're gonna it's going to take you time. So people know that. Jump into it. It's okay. You're not going to get better by being afraid of it and not doing it. So, um I think you know by the end of your first week, again, assuming things are set up in a way that's uh conducive to you getting on boarded, it would be great if by the end of the first week that you could have um committed something to the codebase that was end to end. That could be something trivial like updating a log message or something.

Sometimes we've used that as an example to walk people through the whole software development life cycle from a technology perspective. But I think that could be a good thing to aim for. If there's a small bug fix that's actually adding value, that could be really cool. Um, but this kind of advice, you know, I I'm on social media a lot. I will see people saying, "Oh, it's ridiculous if you know a developer in day one can't like land a bug fix because it says, you know, the team is broken." It's like, sure, but like I don't know like who who is that advice for? If it's for the person who just got onboarded to a team with a broken process, it's on helping them. So, you might be at a place where it sucks for that kind of stuff for onboarding and whatever else.

And I'm sorry, but if that's the case, do your best to get to the point where you can get some things landed so you can feel that end to end flow of like committing value on the team. So, I think overall, just to kind of summarize this, don't be afraid to ask questions. Make sure that you're reaching out to people. Try to get your environment set up to uh develop on your first day. Ideally, like first day to like first week kind of time frame you have code that's been committed um so that you've gone through the whole life cycle. I think that's really valuable. Network. Try to talk with your manager as early as possible. Um, you know, you might not have like deep dive career conversations right from the start or anything like that, but you want to start building these working relationships with people.

And I just recommend doing it early. So, don't shy away from people. Don't avoid them. People want to help you because they selfishly want you to be a contributing member of the team. Remember that they want to help you. But even if let's pretend they didn't. Let's pretend they're like, "Oh man, this person's going to drag me down. they're going to be annoying with their questions. Let's let's pretend that they want you to be effective on the team. So, if you're getting help from them, keep that in mind. You're going to be more and more effective on the team and suddenly suddenly it's going to take a while, but you know, you're going to be a contributing member adding value. They want that. So, don't talk yourself out of it, right? People want to help you. I hope that helps you in your first day and first week on your new team.

Thanks for watching. Friendly reminder, if you want questions answered, comments and if you aren't comfortable doing that, send them into dev leader on any social media platform or Nick Causantino on LinkedIn. And if you thought this was helpful, I would really appreciate it if you shared it on social media, namely Reddit, because I can't share my own stuff on Reddit. I would love that. Thank you so much. Take care.