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

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.

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.

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.

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.

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.

My wife has about twenty pairs of socks, and no more than a few of the pairs are the same variety. It's like some masochistic combinatorics problem every single time I fold socks. My kid and I literally were playing "sock go fish" a few times to get him to help (except ... I was more interested in the pairing, rather than taking turns. Doh.)

Laundry-folding happiness is increased significantly when I don't have to play "Find-the-mate" every time I pick up a sock (which applies to my kids' socks as well, since they are all patterned, but thankfully my son likes wearing party-colored socks, so I only need to match on shape).

I have two "vintages" of socks -- the old ones that I hate, and the newer ones that I prefer, roughly equally divided. I would donate + re-buy if I had more than two flavors of socks.