Ask HN: How do you onboard new developers? | Hacker News Reader

Ask HN: How do you onboard new developers?

5 pointsmvkel3 comments

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?

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.

Any and all thoughts are appreciated!

View on HN

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.

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.

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

Reply on news.ycombinator.com