This week I have the enjoyable experience of bringing 3 new developers onto our project.  Most of you that know me probably read that last sentence with a sarcastic tone on the word enjoyable.  You, my friends, would be wrong.  Of all the ridiculous things that I do at work right now, training and molding new programmers is by far the most enjoyable.  It’s sad that I don’t have more concrete work to train them with, but I have to deal with what I have.

Because I have little, if any, work most days to give to my development team, figuring out how I was going to train newbies was a daunting task.  There’s the standard “Here, take this document and read it.  I’ll be back to see you in two days.” approach, which I’ve had to implement to a certain extent.  There’s also the “Welcome to the company.  We have two weeks of class room training prepared for you.” approach as well.  I decided to try to fall somewhere in between.

What I’ve done is given the new guys (sorry ladies, nobody from the fairer sex is in this group of recruits) a small set of readings for them to stay busy with.  I expected them to read it during the times that I didn’t have other stuff organized (or spontaneously created) for them.  This leads me to the “other stuff” I was trying to be prepared to give them.  The truth is, my preparation skills were non-existent last week, so Monday when the newbies arrived, I had nothing.  That’s not 100% true.  I had run a few things past some people, but I hadn’t taken those ideas and formulated a plan.

For the past few days I’ve been winging it.  What I’ve tried to do is intersperse a number of different experiences with the reading.  I’ve pulled all of them into a session where we talked about the overall architecture of our application.  We’ve spent time discussing the tools that we have, both home grown and otherwise.  I’ve tried to pull each of them off into a design session so that they can see how I’m approaching the decisions and requests that I’m putting forward to the developers.  Lastly, I’ve started to set them up with full days of pair-programming some of the existing team.

The pair-programming is an interesting experiment both for me and the company.  Normally, new hires work through one or two defects with an entrenched (yes, at times it is like a war) developer and then they’re sent off on their own to work through the minefield that is our code base.  This is how I was introduced to the application and project, and, frankly, it didn’t help me at all.  If it weren’t for the fact we have a slack schedule right now, I think that I wouldn’t have been given the leeway to push forward with this approach.  Because of the schedule slack I’m able to work the pair-programming angle for as long as I can.

So, I’m wondering two things.  First, for the couple of the newbies that may actually read this between Ayende’s 55 posts a week, has this approach been beneficial?  Second, how are the rest of you assimilating new developers into your teams?