This. Mentoring should just be pointing people in a direction and occasional code review. Go do this (for a few days). Let's see what you did. This is good, this should be that, name your variables better, etc.
If you let juniors figure it out the hard way, they will learn better, or they will fail. If they fail to learn by themselves, they will never become senior.*
*Shitty code bases should be given a lot of leeway on the learning curve.
> Mentoring should just be pointing people in a direction and occasional code review. Go do this (for a few days). Let's see what you did.
That's one (totally fine) way of mentoring, but it's by no means the only one.
A lot depends on the work environment and the relationship. I work with a couple junior engineers that are also friends, and in addition to "pointing people in a direction", code reviews, etc.:
* We frequently tackle harder issues together, pair-programming style (using a shared tmux session)
* In addition to code-reviewing their work, I have them code-review mine, and I walk them through my code and thought process
* Talks/meetings once a week or more about architecture/up-front design for projects, in which the junior devs are often included or free to attend
* We have a non-work-related Hackerspace that we attend every 2 weeks where we work on side projects / fun creative projects
Certainly this situation is not possible on many development teams, but I just wanted to point out that mentoring is a wide-open thing that has many approaches and options.
If you let juniors figure it out the hard way, they will learn better, or they will fail. If they fail to learn by themselves, they will never become senior.*
*Shitty code bases should be given a lot of leeway on the learning curve.