It’s said that some of the most stressful things you can do in your life are move, have a kid, get married, and start a new job.  It’s all true, too, but this essay focuses on starting a new job because I’ve just started one.

All new employees are vulnerable, regardless of rank or position.  The newbie doesn’t know anyone, doesn’t know the culture, the business, or how to do the job they were hired for.  Yes, they have the skills and are experienced enough to do the job, but they lack all required institutional knowledge to start doing that job on the first day.  It’s a tough position to be in, especially considering the new hire is probably excited and enthusiastic, but rendered utterly impotent by lack of knowledge.

The best way to keep the enthusiasm alive and make that new hire productive is to get them integrated as quickly as possible.  Here are 5 simple things that will reduce downtime, reduce stress, and increase morale for the newbie.  This list is geared towards developers and techies, but some items apply generally.

1.  Make yourself available!

Nothing is worse than being shown your desk or office and then having your guide disappear, leaving you all alone.  Plan on spending time with your new hire or otherwise arranging their first few days to learn from the right people.  Yes, it takes time and everyone is busy with the current release, but abandoning your newbie increases their stress and lengthens the learning curve.

2.  Make sure their PC is ready to go

Twiddling thumbs is bad enough, but not having a PC online with email ready is even worse.  Make sure the new hire can connect to whatever resources they need to do their job.  Many companies achieve most of this by having ghost images of machines with most software pre-installed, but there are necessary network tasks as well.  Email setup?  Is the new hire in the right distribution groups?  All shared drives and other resources given the right permissions?

Make a checklist of all the tasks required to get the new hire into the network and domain.

3.  Hello, World!

The canonical “Hello, World” program proves a lot of things for such a simple application.  It proves that your environment is setup correctly, that you can checkout, build, deploy, and run your code.  It provides a working foundation to build upon and learn within.

What is the “Hello, world” equivalent for real world projects?  A working build from a clean checkout where all unit tests can run, preferably within the IDE, with minimal setup and configuration.

Your new developer needs a checklist of software to install and a simple guide to building and running the project’s unit tests.  I think a checklist is better than a preconfigured environment (from, say, an OS image with everthing preinstalled) because it gives the developer a thorough grounding in the technologies used for the project.  Let them install the build tools themselves and set the appropriate environment variables.  Let them install the source control software and checkout the project.  I believe this gives the new developer a sense of ownership over their PC and deeper project knowledge by knowing how to get it running from the ground up.

It’s true that the new developer will not be truly productive until they gain more intimate knowledge of the code and project, but by having the project running quickly on their local PC, the amount of downtime is lessened and the new developer feels less stress.

 4.  Define your SDLC

How does your new developer get new issues to work and resolve?  What is the process for testing and check-in?  Who are the people responsible for helping the developer get code through the process?

This is basic Software Development Life Cycle stuff and the foundation of the Capability Maturity Model (CMM).  It also helps the new developer feel a whole lot less lost when entering a new environment.

5.   Pair ‘em up!

There’s strength in numbers and comfort in a crowd.  The new hire doesn’t know anyone, so pairing him up with another new hire encourages bonding and forges immediate workplace friendships.  It also helps them both learn more quickly because they are both asking questions and going through it together.  They’ll remember different tidbits when overloaded with too much information in the first couple of days.

If there is only one new hire, have a more tenured employee work with them the first several days.  It’ll slow down the developer who’s been there a while, but it will speed up the new guy.


You know your new guy is stressed out and generally uncomfortable.  Making the assimilation process quick and easy is the humane thing to do, but it also makes a lot of business sense.  You are paying that new developer a lot of money.  You should want them to be productive as quickly as possible, as opposed to soaking up company resources.  Make them feel at ease and decrease the learning curve by getting them immersed quickly into the new environment.  It only requires a little bit of planning to keep them busy for the first several days and some basic documentation to get them up and running with a working project.

The above list is certainly not complete, it’s comprised of the first bunch of things that I thought would make my own transition easier. I’m sure a lot of new developers feel as I do when starting a new gig.  Please feel free to leave other helpful tips in the comments.