Training any new employee is often an expensive undertaking. During the training period, both the trainer and trainee are working under capacity. The senior developers have to devote time to showing off the code base and performing quality control on the new employee’s contributions. The new employee, on the other hand, has not quite built a full knowledge of the business domain and development process and will understandably take longer to perform even rudimentary tasks.
But I think that proper preparation can go a long way towards minimizing those costs.
Have plenty of tasks to ramp up on
Have a large set1 of tasks queued up for him to get started on. Try to order the tasks in such a way as to introduce him to each of the core aspects of the business and the development environment.
With our most recent new hire, I tried to start with some relatively simple front-end markup changes: this gave me an opportunity to demonstrate how our development environment works, such as getting source control set up, checking out the repositories, launching the local development servers and a tour of our custom web-framework. Next I could move up the stack to server side code and database integration. Along the way, there are plenty of chances to point out business domain knowledge and various points of technical issues he would have to look out for.
While ordering tasks, also try to keep in mind the business’s priorities. If you are able to knock out high priority tasks at the same time as showing the new developer the ropes, you make her feel useful and engaged while simultaneously taking care of the business.
Have all the infrastructure set up before arrival
The first day can be really frustrating if you have to sort through all the permissions, Active Directory groups, and accounts new employees will need to have set up and/or configured. If you don’t plan ahead, it will seem like every time you try to do something you need to track down an administrator to create an account or grant the correct permissions. This slows you down and makes you look unprepared all while making your new hire feel ineffective.
Try to keep documentation discussing all the things that need to be set up so that you can walk your trainee through it during on-boarding. If you can get it all out of the way before starting on any real development tasks, you avoid a lot of frustrating context switches that cost time and money.
Do pull requests for code-review
Even if you development culture tends to trust developers to make the best decisions and work independently, its helpful to do pull-requests for code review for the first couple weeks.
This lets you address bad habits before they become ingrained. You can make notes on coding-style guidelines and traps that might be particular to your environment or infrastructure. For example, I was able to warn our new developer that we tend to use lower-case filenames because our production environment has a case-sensitive file system. Not knowing this can lead to a confusing and difficult to figure out bug that only show up post-deployment.
At the same time, resist the urge to require her to do everything exactly the way you would: if her approach is reasonable then by all means approve the PR. Different developers approach problems differently and there is often no “right” way to solve a given problem. Being too much of a stickler about things that don’t matter will be discouraging and time-consuming.
Be prepared to let him fend for himself
Resist the urge to walk your new hire through each of his tasks. Not only does this waste your time and prevent you from getting your own stuff done, but it communicates to the new developer that you don’t trust him. A little hand-holding is obviously required as you show off the code base and how to find things, but at some point you have to let him figure things out on his own.
I think it’s actually good to let a new developer struggle somewhat. I find that I learn best by doing: if I’m just shown how to do something once, I may only be able to remember the gist of it. It’s not until I struggle through it the first time that all the particulars and quirks get drilled into my mind. Being told about a trap isn’t nearly as memorable as almost losing your foot.
Presumably, you didn’t hire the new developer to be your second pair of hands. The business needs people who can figure out how to solve its problems: if the new hire is not one of those people, you need to discover that early on and address it appropriately. You can’t do that while holding his hand.
Larger than you might think↩