Pain points of developer onboarding

In my non-indie hacker role, I'm a development manager for a venture back software firm. Here are some of the process I've used for on-boarding our new hires in the past year:

I send a welcome email to their new company email and ask them to create a Github account linked to their company email address and send me their Github handle. Once they've done that, I grant repository permissions. Inside the repository, there's documentation on how to setup their dev environment. If they can access the documentation, then have access to all the code + instructions they'll need to get started.

On their first day, I set up some 1:1 time to set expectations. Their goal is to have a running development environment by the end of the day. The documentation walks them through everything. If they get stuck, they're instructed to reach out to the previous new hire to help them get un-stuck, and update documentation for anything they've learned. (this helps them start building some team relationships.)

While they're getting setup, I give them Jira access, any other tools they need, and add to standing calendar invites.

At the end of the day, we sync up again and assign them a few low priority bugs that we'll discuss the next day.

On their second day, we have more 1:1 time to do an overview of the codebase, the product, architecture, and team cadence (shipping schedule, standup, etc). I give them a gentle push in the right direction with their bug tickets... and they're off! By the end of the week, most folks have fixed a few bugs already and have a handle on pull requests, code review, and ticketing.

During their first week, I check in at least once a day to make sure they're not stuck ... a bit less frequently on the second and third weeks.

I expect a 3 month ramp up time for any new developer before they're fulling productive. I set expectations with them on that, and work with them over their 3 months to make sure they're not encountering roadblocks.

Is that process high touch and time-intensive? It is. But this is a key time for me to build relationships with folks and start them off on the right foot. So, I see it as a key part of my role in driving success. However, I can only handle ~1-2 new developers per month.

For me, I kind of (respectfully) disagree with your premise: "Let's be real: nobody on either side of onboarding really loves it." I can't speak for the folks being onboarded, but for me—I see it as a high-value add to help someone succeed in their new role as quickly as possible. Adding new team members is key to the company's long-term success.

It is a real challenge like you said but I think in our team we have a reasonable approach to it:

• 1-day crash course on context (what is there, which terminology we use, any important business concepts etc.).
• start with a bug.
• sit next to an existing team member.

That's it.

The bug is small enough that it can be solved without too much code meaning an onboarder needs to make a small change. A small change goes through review fast and the new team member thus get instant feedback. Most of the review things that come during a first review are automated anyway in our ci/cd (linting, testing etc.).

In essence: jump on it and let new members make small changes with instant feedback and have someone around for the 'where/what is this' questions.