I'm pretty sure I was unclear in my original reply (not enough coffee at that point to be replying to the internet I think :) ), I think we actually agree more than disagree. Perhaps I can explain what we thought of as problems and solutions a bit better now that I'm fully awake:

First the idea of paid, but not directed tutoring is a bit weird. When a person is paying they exert an influence over the person they are paying. So in a tutoring situation, the student can say "no I don't want to focus on that fundamental thing because I don't see it as important and you have to do what I say". This can turn off a lot of tutors, because they honestly know that understanding that bit really helps (e.g. knowing about how HTTP works, even if you are just writing DJango apps and never deal with anything other than an abstracted object representing the request). The goal of a lot of tutors is to help people learn, and not just make money. Further it is a bit sticky, because if the student decides not to learn stuff, and can't get a job or doesn't really gain skills, it reflects poorly on the tutor - a bit of a problem if that is your business.

The reverse situation exists in programs like internships or company-internal mentorship programs. The mentor/boss always holds a trump card of "because I am higher in the hierarchy and say so" which can influence the student/learner to not want to rock the boat or express disagreement or initiative. This sort of thing really has the same fundamental "I need to work and keep working to afford life" pressure on it.

The traditional solution to this is a mentorship program (basically what you've been describing). This is generally a safe place to be able to express opinions and disagree, and I completely am on board with your entire post in this sense. One of the problems with mentorship generally is that it can be hard to really get deep tho. Conditions like NDAs on work can really limit shared context - problems are kept in the abstract and specific code review/pointers can be lost. This makes the problem hard. Further, finding mentors can be hard, because from the mentor side doing that task falls into the volunteer/contribute to fun oss projects/hobby category, and therefore the task is in competition with other worthy tasks.

So this is why we were talking about the structure I described. It provides a mentorship opportunity with all the benefits you stated, with the added benefit of easily allowing shared context for the mentor and learner, and reducing the opposition of "competing choices". Essentially it is a way to foster mentorship in a way that everyone wins, with the benefits for all parties being a bit more clearly defined and in focus.

A final note about the software field:

At the end of the day - there are lots of equally good technologies, and people, even the best, will have preferences and beliefs on what is a better solution. Things like architectural style (e.g. event driven or threading?), language (python, ruby, clojure?), and on and on don't actually have a "right and well reasoned" answer. It is hugely style/belief/experience driven. Even at the code level this is true - is a facade or strategy better here is regularly unclear. Is a decorator or descriptor the better way to do this thing in python? How should I break up my classes is a huge source of disagreement even amongst people subscribing to seemingly the same philosophical set (e.g. srp, dry, yagni).

Sometimes the decisions made are based on subtle factors that are impossible to easily clearly explain, and it sounds like hand-waving: "down the line it will be easier to refactor for what we actually need rather than figuring out perfect right now" is a statement of belief and experience, not of reason and fact. Particularly when the same person will say "lets do it right - we won't want to change this later" on a seemingly similar problem. I do that. I try to explain why to my team. It really comes down to "because it just is in my experience - the problems are not similar on a human/project level, not a technical or reason level and those human factors are really hard to pinpoint or don't seem relevant, such as the way the boss reacted to a particular statement, or past experience with the client on a completely different project"

My point is that one of the reasons to ask for advice from an experienced person is that they have an opinion and experience in things that you can't just write a book or set of rules about. Ideally they guide you through the minefield of non-deterministic decisions and consequences when there is a lot of choice and no clear obvious solution.

I've guided a lot of people through stuff like this - very bright people who I learned a lot from and who were very good at learning. The biggest problem wasn't "I don't know how to do this" but "I see so many ways to do this and don't know how to choose". It's a weird thing that comes up in engineering and software: how to be wrong in the right way.

I hope this helps clarify what I was trying to say. Best luck with your finding a coach!

Thanks for this thoughtful reply. I think you articulated the power dynamic between tutors and students very well. I was reluctant to use the word "tutor" in my post, and picked "coach" instead, for this very reason, but I did a poor job of explaining it.