

Ask HN: How do you onboard new developers? - mvkel

I've developed an onboarding strategy for new hires in other departments and have a rough outline of the plan for bringing a new developer up to speed culturally and logistically, but because the position is so unique and tied more to skills than attitude, how do you bring new developers up to speed on the product itself?<p>From what I've read elsewhere (there's not much), getting their environment set up and then asking them to dive in and change a minimal part of the code is... something, but it seems to skip over a big piece of the picture, namely, an overview of the product and its internal code base.<p>Any and all thoughts are appreciated!
======
drstewart
I just went through the process with a new hire that's pretty fresh out of
school, so not much previous work experience.

The first thing we did was give him a big picture overview over lunch along
with the other (non-technical) project members.

Later, I sat with him and did a one-on-one high level overview from an
architectural/technical standpoint that included:

a) How we got to where we are,

b) Where we are now,

c) And where we want to go in the near future

Only after that did I sit down and begin pairing with him. Initially I pointed
him to some of the specific projects he worked on and guided him through
setting up things like dummy apps and running tests and then let him do a
couple of things (like adding documentation or tests) on his own so he can
explore the codebase.

Afterwards, we started pairing on smaller things like bug fixes where I took
the lead and basically just talked about what I was doing.

After all that, I started assigning him some of these smaller projects on his
own and just checked in now and again when he had a process question. From
there, it the ramp up just kind of naturally happens on its own as the dev
gets more and more engaged in the project.

------
Irishsteve
Talk to end user's if possible to understand how they view / use the software.
A casual chat or explanation of a bug that irks them is handy.

Documentation around batch , down or up streams is important.

Tell them about any dodgy piece of glue code that the entire system relies on,
can't be replaced (Because Dave left) and is to costly to refactor.

And as you mentioned, fixing a small-ish bug in the system. Introduces them to
the code base, the release process and any red tape.

------
tectonic
We pair with them. Of course, we pair almost all of the time, so we more or
less don't need an onboarding process.

