You can lead a horse to the water but you can't make him drink.
It's completely okay to "just" do your job professionally. However, skill development, transfer of skills to junior developers and mentoring is a different issue - if you want to learn from me, you have to want to learn; if you're just here for the paycheck, then I'm not going to go out of my way to educate you even if (which is the case for many junior developers) you're unable to actually do your tasks properly on your own without this help.
People with the desire and capacity to learn go over the "junior" phase very quickly (over a short internship or already during college) and become able to do decent work on their own; but those who don't and really need an actual prolonged "junior developer" role on the team... there's no incentive for the employer to do that, and there's no incentive for the colleagues to spend their effort if it seems wasted on someone who's not into it.
I can see your perspective. I think we're kind of talking at cross purposes here. I think it's reasonable to expect someone who needs mentoring to pay attention and want to learn. What I don't like is this idea that you need to spend every waking hour on programming or you're just a clocker who has nothing to contribute to a serious team.
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.
Absolutely - trying to teach people who are not interested in learning requires a very special set of skills, motivation, and personality that few have IMO. It certainly demoralized me as my university teaching responsibilities gradually shifted from small graduate research seminars to overcrowded introductory undergrad surveys, and now in tech roles I make sure to push back whenever my job devolves too far into babysitting. Smart, motivated junior devs are a true pleasure to work with, but unfortunately are still the exception rather than the rule.
It's completely okay to "just" do your job professionally. However, skill development, transfer of skills to junior developers and mentoring is a different issue - if you want to learn from me, you have to want to learn; if you're just here for the paycheck, then I'm not going to go out of my way to educate you even if (which is the case for many junior developers) you're unable to actually do your tasks properly on your own without this help.
People with the desire and capacity to learn go over the "junior" phase very quickly (over a short internship or already during college) and become able to do decent work on their own; but those who don't and really need an actual prolonged "junior developer" role on the team... there's no incentive for the employer to do that, and there's no incentive for the colleagues to spend their effort if it seems wasted on someone who's not into it.