
Ask HN: What's the best way to train/onboard new programmers? - thumbtackthief
After working at my current position for nearly two years (having been a programmer now for nearly four) I am frustrated with our lack of onboarding and training.  To their credit, my supervisors have heard my complaints and want to meet with me to talk about improving (or implementing at all).<p>I&#x27;m looking for ideas and experiences from people on what&#x27;s worked to train programmers and what you&#x27;ve liked.  Not necessarily on teaching Python basics, for example (although that&#x27;s always helpful too) but more about the day-to-day business specific stuff.<p>For me, I feel like I waste hours or even days trying to figure out a problem or using some new technology or third-party software, and I feel like there are already people on my team who know how to do it and could both save me the headaches as well as making me a more productive member of the team.  While they&#x27;re quick to provide feedback&#x2F;criticism when I make a mistake, there&#x27;s not so much before-the-fact assistance to help me do it right the first time.  I&#x27;d like to work on improving this but I&#x27;m not sure how.
======
Hamatti
Having been a junior dev in a couple of startups lately and discussed about
onboarding with one of them a lot, I have a few points. This is all about the
technical stuff, not anything about creating accounts or signing forms.

1) Make sure you have a working and detailed setup instructions for the
development environment. Nothing is more frustrating than spending the first
afternoon trying to get dev tools setup and having to ask questions all the
time.

Setting up the virtual machines, cloning all the right repositories required,
figuring out configs etc ending with instructions on how to run full test
suite. Successfully running all tests is a good signal that things are set up
well.

2) Have a plan on how to cover all parts of the code base and have an
architecture overview.

I personally like to start by fixing bugs. I love when a senior developer can
spend some time pair-programming with me through a few simple bugs in
different places on the code base. Fixing bug covers setting up dev
environment, writing/running tests, finding out how the code is related to the
issue (eg. how to find the right code related to the bug), using bug tracker,
doing pull requests and code review and deploying.

I understand that many small startups might feel they don't have resources to
designate senior devs to do "non-productive" work with a new recruit but it
pays off so fast when new people get up to speed faster and can start being
productive earlier.

~~~
thumbtackthief
This is helpful, thank you. We're not a small startup by any means--we are a
company that predates the Internet by about 100 years, literally--but we are a
small team (seven devs).

Do you have a formalized pair programming process, or is it just "Hey, who can
help me with this?" We're the latter, and while people often try their best,
it usually devolves into "Let me do this for you".

~~~
Hamatti
It depends a lot on the company and the team but I think instead of just the
new dev shouting out "Can anyone help me?", there would be a senior dev
dedicated to you. That way that person knows it's her/his job to help you out
and it's okay if that means you don't get so much done. At the same time other
people on the team will be able to focus on their work.

------
chrisbuttenham
You’re totally justified in your frustration, most people think about
onboarding in terms of signing forms and getting added to a payroll database
when really, it should take you from day 0 to 90 to the end of your tenure. In
short, its about getting you up to speed.

Even when companies have an onboarding program, they often fail to relay the
​​ _tacit_ ​​ information a new hire needs -- like the tech or third party
software you describe. That's partially because tacit knowledge is hard to
record and transfer, but its also a because no one thought to create a
knowledge base or make it easy to transfer that knowledge.

If you're looking to improve the training, I would strongly suggest recording
the way you use tools on a day to day basis. That way its not overwhelming if
you have to explain or write everything down for a new hire. Using
giphy/screenshots/videos is a more engaging strategy for demonstrating how to
use an application. If you record processes every once in a while, pretty soon
you'll have a compendium of your workflow or a living operations manual. While
you could use a cloud storage platform for this, something like
[https://tasytt.com/](https://tasytt.com/), let's everyone collaborate and has
features like account provisioning, analytics (for compliance), and more fluid
access than Google Drive.

~~~
thumbtackthief
Thanks for your support--it's really frustrating.

I'm looking at tasytt but having trouble figuring out what they're used for...

------
shogun21
At all places I've worked at, it's been the "jump in the water and try to
swim" technique. One thing really helpful is stressing the importance of
asking questions, even if they're dumb/simple.

Code reviews are also really helpful. We use a projector and go through pull
requests line-by-line, asking questions and explaining design decisions.

Acknowledge the fact that it's going to take long time and just keep new
programmers bouncing around with projects so they eventually touch all areas
of the code base.

~~~
thumbtackthief
Sadly, while question-asking is encouraged, question-answering is not. I can't
count how many times I've asked something--to the group as a whole or to an
individual--and it's just been ignored.

Do you find the "sink or swim" the best technique, or just the way it's done?

~~~
shogun21
Does everyone have someone they know they can go to for questions? I've had
times where asking a question to a group, it could be ignored (everyone
assumes someone else will take care of it). But if you can have a one-on-one
with someone, I haven't had those instances ignored.

That's just how it's been done. I do think, though, the best way to learn a
system is to work on internal, non-critical projects.

~~~
thumbtackthief
We're a small team, but just today I was in the middle of a Slack chat with
someone and told him I was lost, but never got a response.

------
jumasheff
Being a noob, after asking several "dumb" questions, I was given a link to
Eric Raymond's "How To Ask Questions The Smart Way"[1]. You need to learn to
ask questions the proper way.

Ask your supervisors to organize pair-programming sessions. That way you'll
learn a lot.

[1] [http://www.catb.org/~esr/faqs/smart-
questions.html](http://www.catb.org/~esr/faqs/smart-questions.html)

------
sumodirjo
What about documentation? Having a good and up to date documentation on \- how
to setup the development environment \- what is the coding standard that the
team follow \- How to build the project \- (maybe) how to install components
like db, key value store etc.

Of course having a script to setup the environment will help so the new person
can start doing something, they might get error but at least they start
getting error that they can work on their first few days.

~~~
thumbtackthief
We all agree that documentation is important, but none of us want to write it.

~~~
chrisbuttenham
What if you were incentivized to do so? As an engineer

~~~
thumbtackthief
What would you suggest? That's the sort of thing I'm looking for to prepare
for this meeting this afternoon. Have you found something that works?

