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).

I'm looking for ideas and experiences from people on what's worked to train programmers and what you've liked. Not necessarily on teaching Python basics, for example (although that's always helpful too) but more about the day-to-day business specific stuff.

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're quick to provide feedback/criticism when I make a mistake, there's not so much before-the-fact assistance to help me do it right the first time. I'd like to work on improving this but I'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/, 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

[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?