Donald recently wrote about how he brings new developers on his team up to speed, talking about wonderful things like pairing and coaching.  Of course, for Donald "pair programming" actually means Donald going up to a developer and saying,  "I'm busy stalking this one chick I met online - code up this feature for me or you're fired".  Say what you will about the Igloo Coder but he is a *master* delegator!   As he likes to paint a pretty picture, he also left out the part about "Tell your new developers they must suck up to you publicly as much as humanly possible or there will be consequences."  Thankfully Shane Courtille stepped up in comments to tell Donald, "Good job boss!!   Everything you do rules!  I made your coffee myself today...I hope you like it" (or something to that effect).  Shane, I can tell you with obsequious enthusiasm like this, your job is definitely safe with Donald.  


In all seriousness, it is good that Donald is involved with new hires to the extent that he is.  I find that a lot of companies forget about how vital it is to treat new people well in their first weeks/months at the organization .  Just as your new hire makes an impression on you in the first week, your company is also making an impression on the new hire.  If you want to ensure your new hire stays with your company or project for a while, it's best to make them feel that they made the right choice.    It's startlingly easy to do this; your company just needs to actually give a rat's ass about its new hires.  You would think this is common sense, but there's actually a wide divergence among organizations and the way they treat their new people.  Some samplings from my own past experiences:

• telling the developer their computer isn't ready for their first day but to just sit and watch somebody answer E-mail for the next three days
• Taking the developer out to the most expensive place in town for lunch and letting them pay for everyone when you forget the company card
• "You know, it's good that you're here because we *really* need someone to come in over the weekend to fold some fliers for our marketing expo next week, and BTW I love the fact that you don't feel anything is 'not my job'"
• And of course, the ever popular "RED ALERT!!  HOLY CRAP PRODUCTION IS DOWN PRODUCTION IS DOWN." 

In my career, I have only felt that possibly one or two companies I've worked for actually got the "new hire introductions" right.  As a team lead in my current gig, I'm the one who shoulders the responsibility of introing new people to our project.  What I do today and am sharing with you below is a composite of those good experiences.

1) Before the developer ever starts, ensure everything they need to get working is ready for them.

I should emphasize how important it is that the following things are ready for your new employee for their first day:

• phone
• computer
• tools setup
• proper software configuration
• logins and access for everything needed to do their job (source control logins, etc.)

Note: I understand that in certain situations you may not have as much control over this as you would like, but try to do what you can to the best of your ability.  Although it's a bit underhanded, if you think IT is lagging have the developer take over your machine and simply tell IT they will be using it until a machine is made ready for them, so your own productivity is being affected.  Note that this won't work all that well if you're not productive in general, but then again if you're not that productive you're likely not being put in the position of introducing new hires.

2) The developer is taken around to be introduced to everyone in the company. 

I want to ensure the developer immediately feels that they are considered an integral part of the team (heck, if we're going to hire someone, they'd *better* be an integral part of the team!), so I will take him/her to meet and greet.  Note that this is not limited to developers - your new hire should be aware of all of the stakeholders in the project, from the lowest to the highest levels where possible. 

3) A document called "Newbie's Guide to the Company" is given to the developer

This can be in wiki or Word format or *any* format for that matter.  This explains the general technical team structure, some company policies, as well as commonly asked questions and answers.  For the first week or two of the employee's time, that employee is responsible for maintaining/adding to the document as they see fit.  If you're doing a document like this, I recommend it being light in both tone and in page count.  The best way to ensure that this document doesn't get updated or read is to make it 70 pages long and looking as if it was written by someone who's never gotten laid.

4) Pair programming

Presuming that we didn't hire this guy or girl on their ability to write scintillating documentation, the remainder of the week is spent doing off-and-on pairing with a developer on the project, as we handle a minor bug/feature.   While we are doing this, we also take the opportunity to give a small tour of the architecture through code and a discussion of how our general methodologies work.  Note that when I say off-and-on pairing, I do not mean show up for 15 minutes a day to see how the developer is doing and then running off to an important meeting.  For the first week, pretty much nothing should be more important then the time spent with the new developer, and this is something that management and the team should both understand. 

5) Lunch

I take the developer out to lunch once or twice depending on the time frame for the week.  Once is with the main team they'll be working with, and once is with me one-on-one.  Always pay for the new hire - if the company doesn't pay for it, cover it yourself.  Some people consider this too expensive, but I counter that the cost of one or two meals is nothing compared to the investment of my time and the team's time if this person leaves after only a couple of months. 

I'm always interested in self-improvement, so I thought I should ask a couple of questions of those that are reading:
a) Are there things you would change about the way I am doing this?  Too much?  Too little?  Not enough tips on stylish shirts and fantastic hair?  Should I get the new devs to go wash my car?
b) What is the worst experience you've had as a new hire?
c) What is the best one?