Building a Developer - How to Nurture a New Dev

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.

In the current environment of COVID, I’ll usually have a zoom meeting constantly running with my new dev.  In the “olden times” when we were in the office together it was a bit more crowded as we were both huddled around 1 or 2 monitors staring at the same code.  During this training period, I’m also dropping out various pieces of knowledge such as additional tools or short-cut keys built into the editor we’re using.  Given we work in a C# environment that’s typically Visual Studio but as you all know, add-ins can make a huge difference in how you code.  The same goes for Visual Studio code or even if you’re having to slog through Eclipse or IntelliJ.  Since our shop is typically made up of full stack developers, we’re also bouncing around a good bit between the front end with all the HTML, CSS and JavaScript goodness along with the back end and various C# frameworks.  Again, the whole point of working together is so that you can begin (or continue) reinforcing not just how things are coded, but why we’re coding this way as well as how the various pieces interact.  Once I feel they’re starting to get the gist of what we’re coding together I’ll explain what the next piece should accomplish (possibly even starting it) and ask them what should come next.  It’s OK if the answer isn’t perfect or even if they don’t know. The whole point there is to begin the process of making them think through the problem.

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 coattails.  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.