Clone and have fun! Onboarding developers

When you start a new job as a developer, the most important introduction in your first week is to the development environment for the products you’ll be working on.

There are a few ways this can go down. But the most popular, at least in my own experience is the clone and have fun(!) method.

That is, you get given a computer, a port on the network, a bunch of privileges, auth details and your public key on some servers and you’re left to clone a repo and get it up and going.

Maybe somebody will help you through, or what they can remember of it from when they last went through the process. But generally it looks like this…

git clone repo
cd repo
ls
less config.file

“There’s some databases in the config file, ok…”

apt-get install mysql (port install mysql)
create database project_db

mysqldump -u -p -h host project_db > project_db.sql
mysql -u -p project_db < project_db.sql

config.file < new db details

“Ok, maybe we’re good to go.” Run thing...error, missing other-thing

apt-get install other-thing / port install other-thing

Run. Error, missing other-thing-2…

Repeat * n until thing starts up.

Finally we get to the point where OK, thing runs in principle. Until we load the first screen past the auth...error, call to dependant project failed…

git clone repo2...

And this continues on until every error has been resolved, every dependant thing now exists in some (probably slightly stale) form on your local dev environment.

This isn’t a post about containerising dev environments, though that is part of what any good solution to the question would likely contain. I'm asking myself the question, how best to onboard a developer?

Some of the onboarding experiences I've personally been exposed to:

• “Clone and have fun!”
• “Clone and have fun! and this guy will help you as you go” or assisted clone and have fun
• “here’s a server with production code and the network share of the last developer that worked here”
• And a much nicer half day powerpoint presentation / workshop by a mid-level dev to give an overview of products and tech environment, followed by assisted clone and have fun.

Why care. Because depending on the environment, setting up a local dev environment can take a lot of time - in my experience a minimum of 2-4 days from here’s your brand new computer plugged into our network, to ok I have code and most of the errors are gone when I run it. In more complex environments, I could see it taking much longer.

And this doesn’t even begin to touch on the time it takes to actually become productive with the code base. Which I expect is a function of familiarity with the tech stack and the problem domain, the further your experience with either deviates from your new environment, the longer it will take to write code that makes it into production.