[BigJono]

> Those aren't the only two options. You can try to get a team to develop systems that any other capable software engineer can pick up reasonably (such as via effective documentation, and reasonably maintainable nature of the code).

That sounds nice in theory, but I've only ever seen it be a disaster in practice. It's like that mirror thing from Harry Potter. As soon as you actually try and make a maintainable code base, it starts going the other way.

The only way to truly optimise for onboarding is by writing the simplest, cleanest code possible. Everyone is already trying to do that by hiring the best devs they can. Any further efforts just look like more dependencies, more patterns, and more incidental complexity to act as guard rails in the pursuit of a newb-friendly codebase.

The end result is that new devs are productive at small and simple tasks, but big things take longer. Also, you're never going to find a manager that understands this trade off, so your new dev is going to be left in a terrible position trying to explain how they got so much work done in the first month when they knocked off all the small cards, but now the new feature that the business desperately needs has taken 3 months all by itself.