So that's why your first project here is going to be writing up some stuff so that it's easier to bring future people on board!
Has "get started on a new project by first writing up the documentation" actually worked for anyone in either a company or an Open Source project? If so, I would really like to know how because I keep hearing this advice but I suspect it comes from people who've never done it.
Putting yourself in the mind of a reader is really hard. And documentation, which is necessarily duplicative, can easily become out of date. So yeah, I think novices are often the best people to write novice-targeted documentation, because they understand the reader's needs quite well.
Personally, though, I'd be a little embarrassed to assign a new arrival that if there were absolutely nothing. I think the process is a lot easier if they have some starting point for the docs, even if it's just some headings and bullet points. I'd also sit nearby and give them strict instructions to stop me at any point they were confused so that I could get them back on track. But I think it's a pretty good task on arrival.
So it just floated around and new hires basically started with the PDF all over again.
This is a good insight: the strategy does work if they have something to work through and a fallback if they are confused.
Everything in that situation came down to documentation and I spent my first couple of days just chasing down the "correct" IT person to setup all of my accounts (company network, version control, bug tracking software, customer network, remote access, email - each required a different person and I had to ask around to find out who they all were). I commented that having one IT person who can handle everything would be ideal; but I had to settle for creating a list of "who to contact for what". This still shaved days off the next person's lead time.
Simple stuff like having a development machine ready to go (installing Visual Studio, an Office suite, etc) when the new person arrives really makes a difference. There was a learning curve w/r/t the actual system but the new person didn't have to switch gears between hunting people down, installing a myriad of in-house software with which they have no familiarity, and other general "drinking from the firehose".
I took some stabs at making the firehose drinking not as overwhelming; but I didn't do as well as I wanted.
The organization's attitude mattered, in retrospect. Bringing on new people took a significant amount of time (still does but it's better) and everyone did what they could to help me document the process. I imagine if the organization had not been incentivized to help me, then I would have failed and "first write the documentation" would not have worked at all.
I setup Vagrant, wrote provisioning scripts, wrote a README, and checked it in after I had figured everything out.
The next employee to join was setup in a day instead of 2 weeks. It worked out great for me.
To be honest, it was a kind of frustrating onboarding experience, but it definitely met the team's goals with a minimum of disruption to people who were shipping features.