322. How to Onboard a New Developer the Right Way

Your team just hired a new developer. How do you get them up to speed? How do you make sure that they become a productive member of the team as quickly as possible? How do you get them comfortable with how you do things at your company? These are the questions we will answer in today's episode of DevQuestions.

Website: https://www.DevForge.com/ 
Ask Your Question: https://suggestions.iamtimcorey.com/
Sign Up to Get More Great Developer Content in Your Inbox: https://signup.iamtimcorey.com/

Transcript

Copy Transcript Copied

SPEAKER_01 0:00

Your team just hires a new developer. How do you get them up to speed? How do you make sure they become a productive member of a team as quickly as possible? And how do you get them comfortable with how you do things as a company? Setting up a new developer for success in a new environment can make a big difference when it comes to their long-term success. It can also make the team as a whole better as well. Let's talk about how in today's episode of DevQuestions.

SPEAKER_00 0:35

Welcome to the Dev Questions Podcast with Tim Corey.

SPEAKER_01 0:39

Software development is more than just writing code. So let's talk about the rest of it. Specifically, let's talk about how to onboard a new developer the right way. Now, if you've ever started a new job at a new company, you probably remember the confusion. You're setting up payroll information, getting your healthcare information ironed out, filling out forms, going through the handbook, and more before you even get to the actual job. Then you sit down at a brand new computer, figure out your login, and start on the real work. You have to figure out where the shared files are, where the documentation is, you have to figure out how to actually start working on code, where the code is, what the process is of getting code into production, where to find out where the tickets are, and so many other things. There's a lot that gets thrown at you right away. And the worst part is that you get all this fire hose of information and you miss things. And then you feel like you feel bad about having to ask again and again for these things because you forgot. Now, on the side of the current developers and management, the process is often similar as far as it's a bit of confusion where they we just hired somebody new. Now what do we do? Oh, we gotta remember to get all the documentation put together. And where is a documentation? Do we have documentation? And oh, we need to get them a computer. What should we installed? And how do we do that again? Because we haven't done it in years, because we've had our computers running forever and so many other things where it's kind of just ad hoc and as you go. Unfortunately, most companies waste a whole bunch of time during this process while still not doing a very good job. So let's talk about what things you should work on before hiring a new team member so the process goes much smoother and so your team operates better as a whole. So, number one, let's establish a standard work environment that can be automatically set up. This is if you use Visual Studio, then here's Visual Studio, and here are all the plugins or extensions we use and have a list. If you use VS Code, well, you can even have a VS Code setup that just sets everything up with different environments for the way you work on different areas of the code. And if you have options, well, that's fine, but document them. Have an automated process for installing the tools you need. Because it's usually tools that are, you know, maybe you have to install FFmpeg on a machine because you have to make sure you process videos a certain way or whatever the case may be, have a process to automate that as much as possible. Because here's the thing. First of all, it's gonna help a new hire because they're gonna have the same setup as everybody else. Now, yes, we all customize things and you know change our themes or whatever. But for the most part, you should have a standard base you work off of. And that'll help them get up to speed. And when you show them, oh, you're gonna do this and go here and go there, they're using the same tools so it looks the same. And it's much easier for them to understand and follow along with you. There's less translation about, oh, well, you're using Visual Studio and that's how you do it, where I use VS Code or we use JetBrains or whatever the case may be. But also, if your computer crashes, which does happen, I have lost a few machines in my day where the machine fries, the hard drive fries, something goes wrong, and you need a new machine. Well, you don't want to spend the whole day setting everything back up, installing everything. Again, this is where Docker really helps too, because if you're using like SQL and MongoDB and RavenDB and all these other database environments, that can be very quick to set back up. But if you have a standard work environment with configuration for how to install it automatically, well, you can do that too. So you can get back up to speed very quickly when your computer dies. That's number one. Number two, keep documentation of your systems and processes and keep them up to date. This is where the central storage is, where the ticketing system is, and how to get to it, and what the logins are and who to ask for logins, who's in charge of these different systems. So if there's a problem, you know who to go to. And all these various things, keep them and keep them up to date. Document your process. This is where maybe AI can help a bit. I'd be very careful though, because yes, people will just say, well, AI can do the grunt work of just documenting. Yes, but what happens instead is it creates some verbosity there that makes it really difficult to understand where things are because of so much content. And what you really want to have is as small as possible documentation. You want that to be, you know, a little bit of information, not paragraphs and pages of information. So, and the other thing is you don't want to give AI any kind of login information or or any kind of keys or anything else. So be careful there. But this is where you document your system and your processes. So, number three, and this kind of goes along with this, but document every step to fix a bug and deploy it. Every step. So this comes from where do you get the ticket for that? How do you know it's assigned to you? How do you filter just the ones that are assigned to you? How do you prioritize all these things until you get to the point of, okay, we have a bug now. Let's walk through the process step by step with pictures on how to fix that bug. The reason you do this is because this is probably one of the most common processes you do. Now, if you have a different common process, document that. But this is a very common process and a very common thing you'll give a new hire a do as the first task. You say, okay, here's a bug, go fix it. It's a simple bug, but that'll get you through the process of understanding how we submit code for review, understanding how you push the code into production, understanding how we deal our ticketing system, and so many other things. So document that entire process. That means that your team members aren't being asked over and over by a new hire, hey, how do I do this now? How do I find my tickets? How do I mark the ticket as done? When do I mark it as done? Who reviews this? All this stuff can be in documentation. That this is not that you don't want people to talk to the new hire, the new hire to talk to people, but you want to give them as much autonomy as quickly as possible so they can feel like they're making a contribution and they can get up to speed very, very quickly. With this, number four, document every step to add a feature and deploy. Because this may be a bit different. So features are different bugs because of the fact that you're adding something new. And how do you add something new? How do you figure out what to add and where the libraries are for the different things we have already done? And how do you make sure that we're not, you know, repeating ourselves in a way we shouldn't, and so many other things. Document that step by step with pictures. Again, this is the next big step for a new employee where they're gonna add something new. And so you want to be able to walk them through and give them as much confidence as possible in the process so they can just focus on the code. All right, that's number four. Number five, give them time to absorb everything. You do not want to just have a fire hose. Give them time to absorb things, give them space to kind of understand what's going on. And this is where that documentation helps too, because you can say, hey, you know what? Once your computer is installed and set up and all the rest, and once you kind of poked around a little bit, here's a bug. Here's the documentation for how to fix that bug. Take your time, get to it, and walk through the process and then come back to us when you're done. Not a rush. That gives them the opportunity to kind of calm down, let things filter into their brain, let them come up with questions they might have, make sure to give them time to absorb everything. You don't want to just overwhelm a person. You want to allow them to absorb what they've they've been presented with so they actually learn things. Because if it's important enough for you to tell them, it should be important enough for you to give them time to actually remember it. Number six, pair them with an experienced developer for their first task. Now, this may be after the bug, this may be after that first bug fix or two, since they had that paperwork, that documentation. But at some point in the near future, pair them with an experienced developer for their first task and let them drive and say, okay, let's walk through this thing that we're gonna do. And just watch them do it, talk them with them on the process, and make sure they are confident and comfortable doing the process. And this is not, make sure it's not a a person just telling them what to do step by step. Make sure that you let them drive so that they can understand what they're doing and and kind of make false starts and make, you know, and then walk them through it, go, oh, nope. Here's where you find that information. Here's how it, you know, and that will reveal some things they may have missed. You can help fill in those gaps with them. And this kind of feels comes to next number seven, which is encourage them to say, I don't know. That phrase is so important for people to be able to say. So tell them you need to be able to say, I don't know. And say, you know what, you're not gonna know most of the stuff, and that's okay. But we want to know what you don't know because we can't fill in those gaps if we don't know you don't know. So, and this also can be something where you lead by example, where they ask you a question and you say, I don't know. Let's go find that. And so make sure they know it's a okay phrase phrase to say, and in fact, it's an encouraged phrase to say. And then make sure they know who to ask for help. This is where knowing who's in charge of different things and that documentation earlier, where you say, you know, Bob's in charge of the SQL Server, and you know, Mary's in charge of the ticketing system, and and so they know who to go to when they have a problem with one of those things. So encourage them to say, I don't know. And then let them know who to go to for help. Number eight, have written expectations of how they'll be evaluated. This comes on a management shoulders, uh, especially, not just the team, but let them know what you're looking for. Some organizations say, you know what, we're gonna evaluate you based upon how many tickets you complete. Okay, they should know that up front. It should not be a guessing game. If you say, we're gonna do lines of code, these are horrible ways of evaluating developers. But let them know what your way is of evaluating them because they shouldn't have to guess, am I doing okay? They should be able to be the first line of evaluation on themselves on how to be evaluated. But they can only do that if they're evaluating the same way their boss will be. So have it written down. Here's how we evaluate you. This also encourages management to actually know because some places just don't know. They're just kind of guessing at how they're evaluating. So I feel like you're doing a good job. That's not a great evaluation, right? So you need to have a way to say, this is what we're expecting from you. And then this is how you can evaluate yourself to know if you're meeting our expectations before we do. Number nine, ask them to document anywhere they had issues in the onboarding process, and then fix those issues. So this helps you make the onboarding process better. And it also reveals to you any things where you kind of skip over things, where you, you know, just kind of hand wave past certain areas because you've done it for so long and you miss. Oh, yeah, we do it that way. And when you figure out those gaps, you might also figure out, hey, we shouldn't be doing it that way. Right? And so you figure out, hey, you know what? We should probably think about what we're doing. Sometimes you get so in the groove of doing something that you don't think about it consciously. But when a new hire comes in, they kind of reveal these things. And if you have them documenting any place where they had an issue or they're they're missing documentation or whether where they're confused on something, when they document those things, then you figure out, oh, we're we're missing this. We have this gap that we didn't see. It's a great opportunity for the organization. Number 10, and I think this is really important, not just for the new hire, but for the team in general. Number 10 is schedule a celebration for two to three weeks after the new hire starts. Not right away, not the same day in a celebration. It could be a lunch. It I personally I like to have a let's take the team out for lunch and kind of celebrate. But if your company's not big on that or they they're not gonna give it time to do that, well, bring in donuts or you know, have some kind of celebration at work with you know muffins or whatever. But take the time to celebrate when that new person has gotten past the, oh, I'm still dealing with HR. Like, because you want to get to the point where they are in the job, they have done a few things so that when you hang out and you're talking to them and you're saying, hey, how's your onboarding going? It's not just, oh, I've got my insurance set up now, great. Like, that's that's not what you want to have the conversations about. You want to have the conversations about, hey, I got my first ticket out. Hey, I'm I made my first mistake, right? Like, have those conversations because it's more realistic of what a developer goes through and it's a better bonding experience. Because this is important, that new hire, you need to work on bonding them with the rest of the team. Because if they don't bond well, you're gonna have a hard time as a team. Whereas if you can get them to see each other and you know, have a casual environment where they can talk and they can talk about, hey, what's your you know, your your hobbies or whatever, or talk about the you know, the first things that you that you learn on the job, and then you can talk about how, yeah, my first week, I deleted the SQL database. And have those funny conversations that starts to build camaraderie and it starts to build a bit of trust between team members. And you be careful because you don't want to put the person on a spot. Don't put them in the front of the room and make them give a prepared speech that's gonna terrify some people. That's not it. But you know, a celebration where you're having muffins or going out to lunch and you know, eating pizza, those things can really change the team dynamic. So preparing to onboard a new developer, it's a great opportunity for your team to formalize your process and to get your entire team on the same page. And then when the developer does join, it's a great opportunity to identify the gaps in your process and fix them. It's also a great opportunity to further build team cohesiveness and morale. Don't let the opportunity pass you by. All right, thanks for watching. And as always, I am Tim Corey.

SPEAKER_00 17:01

Thank you for joining us for this episode of Dev Questions. When you're ready to learn to think and code like a professional developer, head over to IamtimCorey.com and enroll in a course.