Culture plays a huge role as well. I have seen the environments where existing folks are un-willing to help out new guy. This could be due to lack of time, getting territorial, just-being-jerk, lots of attrition, etc.
The best way to get started is to start writing tests for the team and work your way up. I find this useful for all levels of hire.
The way you make people productive in that environment is you have, and enforce, good coding and design standards so that code will do what you expect and you can rely on parts of the codebase that you don't necessarily understand the internals of. Frankly, having to consider "nuances, and deliberate details, and designs, and prioritize and a million other things" is not a good use of people's mental capacity, and you should aim not to have a codebase where people have to do that. Write your codebase like a tower of libraries/DSLs, where each layer presents a solid abstraction to the layer above it, and the topmost layer is just the business logic written in the language of the domain; then it's easy to make a simple change to that business logic because you just have to make the same simple change to your code.