On Training New Developers

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.

make her feel useful and engaged

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.

it’s actually good to let a new developer struggle

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.