So, your company or department has been growing, and like every other organization is having a bit of a tough time finding experienced developers to fill your ranks. To help alleviate the situation they’ve decided to embark down the path of bringing in talented individuals that are just getting started in the IT industry or have made a career change but don’t yet have any professional experience. Perhaps they’re self-taught and impressed the hiring manager with their dedication. Or perhaps they’ve attended a boot camp to learn the basics of our craft of software development. In addition, you’ve been tasked with bringing these fledgling developers into the fold and teaching them both how software development works in the real world as well as setting them up for success in their new career path. Congratulations… you’ve now become a Mentor!
As you’re embarking on this journey together, I recommend that you seek to give your new mentee the tools they need to continue on with a long and successful career. One of my goals, as I’m working through this process, is to make sure anyone I’m mentoring starts learning the WHY of what we’re doing and not just the how. I’ve seen a lot of developers that can just push out code but don’t take the time to understand what’s actually happening or even, more importantly, why we chose to implement a feature in a specific way. The latter will probably take a long while to develop, but if you instill the idea of understanding the bigger picture, you’ll set up your new Jr for a lifetime of success.
Getting into how you should typically begin this process, the first point you’ll need to understand is that your own productivity is going to take a hit during your first few weeks with your new colleague. Even though they may have recently gone through a boot camp or been exploring on their own, classes or tutorials all tend to cover the same kind of things in a rather simplistic way. Being an agile shop, I’ll usually continue to work on my specifically assigned tasks but work through them slowly. As I’m going, I’ll be explaining:
A). What exactly I’m doing in terms of functionality.
B). What each piece of the puzzle is supposed to accomplish.
Over the course of another week (or 2 or even 3) I’ll start allowing them to direct a bit of what I’m coding. At this point I may even turn the tables a bit and begin asking them to do the actual coding. Quite frequently, especially as this phase starts, I’m essentially doing the code through them. Pointing them in the right direction or even explicitly telling them what to code, but all the while explaining not just the how but the why. This isn’t just a situation of merely dictating the code and expecting them to type it out. I’m actively trying to make them start putting into practice the lessons we’ve been working on. i.e. thinking through the process. Having them start explaining what they think should be done to satisfy the requirements of whichever task we’re currently working on. If something really needs attention, I’ll ask them to write up a plan on how they should approach the problem of a specific task or requirement we’re trying to satisfy. While they’re doing that you can use the “down time” to address any urgent items that have come up. I’ll also use those urgent items as learning points for the new dev once they’ve been addressed. Ideally, we’re working towards the next phase of this onboarding experience where you begin to allow our newbies to start working a bit on their own.
Finally, it’s time for our fledgling new developers to begin striking out on their own. You’ve gone through a few weeks of them riding your coat tails. You’ve had a few weeks of them mostly working on tasks (or stories in the agile parlance) with close supervision. It’s time to begin letting them loose on some tasks of their own. In our agile environment I’d begin assigning them specific user stories for them to try to work, start to finish. Part of their work should be thinking through the process and documenting the steps needed to achieve the result. Typically, we ask developers to put that into sub-tasks associated with each user story. However you do it in your organization, it’s a good practice and for the first couple of stories be sure to review the steps detailed by your new developer.
By the time you’re finished with this process you have a newly minted developer who has a bit of confidence in what they’re doing but will still need guidance and assistance. So, by no means are you finished. If you’ve developed the relationship correctly, you’ll be a long-term resource for your new developer to reach out to as questions arise. Hopefully, they’ll feel comfortable asking you questions related directly to their role in the development team, but they may also come to you with more general career-oriented questions. As the “old man” on the totem you’re now a source of information and advice that a new developer can and should utilize going forward. Congratulations once again! You’re now a Mentor and have added another capability to your own professional arsenal.