"Another perspective is to consider training junior engineers to be a core job responsibility of senior engineers. There are always going to be tasks that need to get done even if we don't "derive energy" from them. That's just part of being a professional. Most engineers who complain about teaching and mentoring shouldn't be promoted to senior level in the first place; in the long run they would probably be happier and more successful as independent consultants."
All fine and good but you need to actually get the time and be recognized for the time you put into mentoring. In the companies I have seen senior devs are still measured by their output and setting time aside for mentoring younger devs doesn't really help their ratings. A lot do it anyways but the incentives are against doing so. .
I think the advice can be more general than just "make a training program", too, because the point is that you can't stick a junior next to a senior and hope knowledge will transfer by osmosis. That's lazy management. Instead, responsibilities should be clear ("Bob will spend 4 hours a week mentoring a junior") and employee strengths should be factored in ("Steve prefers not to mentor, but knows the software internals very well and will spend some time improving documentation for Bob").
I don't think "4 hours mentoring per week" works well. From my experience some weeks you need way more and some weeks way less. I would much prefer if I would get evaluated by the progress of the people I am mentoring.
All fine and good but you need to actually get the time and be recognized for the time you put into mentoring. In the companies I have seen senior devs are still measured by their output and setting time aside for mentoring younger devs doesn't really help their ratings. A lot do it anyways but the incentives are against doing so. .