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'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.<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'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.
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.<p>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.<p>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.<p>2) Have a plan on how to cover all parts of the code base and have an architecture overview.<p>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.<p>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.
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.<p>Even when companies have an onboarding program, they often fail to relay the <i>tacit</i> 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.<p>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 <a href="https://tasytt.com/" rel="nofollow">https://tasytt.com/</a>, 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.<p>Code reviews are also really helpful. We use a projector and go through pull requests line-by-line, asking questions and explaining design decisions.<p>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.
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.<p>Ask your supervisors to organize pair-programming sessions. That way you'll learn a lot.<p>[1] <a href="http://www.catb.org/~esr/faqs/smart-questions.html" rel="nofollow">http://www.catb.org/~esr/faqs/smart-questions.html</a>
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.<p>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.