As a new person on a team, I'm thinking about what works well for making new folks comfortable and productive. Wow, being new is a firehose of information. I'm appreciating 101 tutorials, whiteboard sessions that repeat key information, and code reviews that are forgiving of my very basic git skills. (I should learn to rebase, seriously.)
Effective onboarding was even more important on my last team. That project was a scrappy group effort, a small core team bolstered by a rotating cast of 20% contributors, interns, IT residents and engineers briefly on loan from other teams. It worked surprisingly well, but we had to learn how to onboard people very quickly. If it took someone a month to get started, we might have wasted a third of their time on the team.
Many of the people starting with us were new to the company, or even to the industry, and certainly didn't know our source control system. Dropping them straight into our codebase (an intimidating networking library used by almost everything) would have made them run screaming, so we let them learn the code review system before touching any code. We made a directory in our source control system and asked them to commit a joke to the directory. That meant that their first change was completely low stakes (apart from the pressure of thinking of a good joke!)
You can tune a piano but you can't tuna fish.
Their second change was to add their names to the list of team members on our website. This was a small markdown change, but one that meant getting a review and modifying something real. It gave the immediate gratification of seeing a changed website.
Finally we gave them our "pingpong" toys, a client and server in each of our major languages. I'm so proud of these things. They were probably each less than a hundred lines of code, and all they did was talk to each other, and export monitoring data.
Our networking code was called whenever many important clients and servers talked to each other. It was pretty scary code. But we'd get our new people to build and run their own little pingpong client and server in their favourite language, and poke at it a bit. Run the binaries, stop them, start them again. Make tiny changes to the local copy of the pingpong code. Maybe add a log line, or make it only pong for every second ping. The code's not getting committed; it's just a local change. Build it, run it, poke at it some more. Look at the logs and look at the monitoring data.
Once they felt safe with that, we'd have them make a similar logging or monitoring change to their local copy of the networking library, and rebuild the binaries. They'd break something, and watch the pings not ponging. They'd fix it again.
These very gentle steps got our new people from "this code is terrifying" to "I own this". For interns, it might take a week or two, and at the end they'd know how to modify, build, deploy and monitor code. For experienced transfers, that might all happen on day one. (We didn't make experienced engineers tell us a joke, though we probably should have.)
Our team lead, Silvia, had the insight of having interns and junior folks then present what they'd learned at the team's weekly meeting. Presenting your work is a core skill in software engineering, but a pretty scary thing to do, so we made sure it was a friendly and supportive room. It took our new engineers some time to put the presentations together, but it was worth the time (and they did great).