Alternative take: the assumption that senior engineers get pressured into agreeing to mentor without it formally being an acknowledged part of their job - that is, that a significant percentage of their time is supposed to be allocated to making themselves available to juniors - is fundamentally a problem.

There is so much stigma associated with being an senior engineer that simply wants to spend 95% of their day working on the problems that they were hired to solve. The worst part is that the vast majority of people in this situation are not compensated for this time, and they are expected to keep up with their actual assigned responsibilities.

This state of affairs is a relatively new thing. The idea that you would join a company with the expectation that the most important people to the success of a project should drop what they are doing to context shift to someone else's problem several dozen times a day is not something that would have been remotely normal twenty years ago.

I am not saying that mentoring is bad or that asking for help is bad, just that there's been a change and the unspoken vibe is that if you're not happy to work at ~30% capacity because you need to mentor people, you're some kind of antisocial jerk.

If a company wants seniors to mentor, pay them to mentor. It's very simple.

▲

em-bee 3 days ago | parent [-]

mentoring juniors should always be part of the job. sharing your experience and knowledge is part of the common job description. the idea that you just write code and never need to share your experience with others is a fundamental misunderstanding of what your work is about. you would have expressly negotiate an exception into your contract if you want that, not the other way around.

what doesn't work is the assumption that mentoring doesn't take any of your time and that you are expected to manage the same workload with and without mentoring. that's not ok. and spending 70% of your time mentoring may also be a bit to much, but if that is what the company needs then it is still your job.

▲

peteforde 3 days ago | parent [-]

It seems as though you want things both ways.

The notion that an experienced person should automatically consider mentorship to be part of their job is not backed by any code or contract that I'm aware of. It's just increasingly been pushed on people who haven't pushed back enough to keep a new generation from feeling as though they are entitled to it.

You can sample as large a pool of senior devs as you want; I suspect that if you can find 1-in-10 who have specific wording and structure in their employment contracts about the percentage of their time that they should expect to allocate to mentorship, you'll be beating my own estimations. No, what you're doing is attempting to codify a very polite form of exploitation. Yes, those people are usually among the most well-compensated, but it doesn't change the fact that they have their own job to do and a finite time in which to do it.

Please note that I am not suggesting anyone on a team could somehow work in a vacuum. Also, even the most experienced person frequently needs to ask for help, guidance and clarification. Being experienced is pretty much the opposite of knowing everything and is much closer to a measure of how much you have forgotten.

Nor am I implying that senior people have any business being rude or dismissive towards team members who legitimately have good reasons to interrupt someone's flow state. Timely clarification is important to a project regardless of who is doing what.

What I am saying is that if you run a company you might legitimately be horrified to learn that your most critical team members are spending 70% of their productive time mentoring, especially if that remaining 30% of their time is so fragmented that it never resembles a true flow state. You need those people to Build The Thing.

If you don't get that, then you're not living in the same reality I am.

▲

em-bee 3 days ago | parent [-]

The notion that an experienced person should automatically consider mentorship to be part of their job is not backed by any code or contract that I'm aware of.

every job i had, every developer i hired. it is also backed by german law for example, refusing to mentor/train others in the work you do is a fireable offense in germany. in any job. not just software development. i doesn't need to be explicit in the contract. it is a natural and expected part of your job. and in the US with at-will employment, what's in your contract doesn't matter as much either. if it seems like a reasonable request they can just let you go if you refuse. the idea that you should not ever have to pass on your knowledge to others in your company seems very entitled to me.

that's my opinion on the matter. you can find more diverse opinions here:

https://softwareengineering.stackexchange.com/questions/8627...

some even fully agree with you.

i already acknowledged the 70% problem you mention. that should not happen unless it is known and intentional. i'd be horrified too if i were surprised by that.

▲

peteforde 3 days ago | parent [-]

That's really interesting about German law. I didn't know that, so I appreciate learning.

I suspect that if we were having this debate over dinner, we would agree on far more than we disagree on. I think we're speaking past each other because we're operating with slightly different notions of what mentoring implies.

From my perspective, I think that there's an obvious and reasonable expectation that you make best efforts to be a good team player. That means doing your part to participate in planning, knowledge transfer, group morale and of course making yourself available to work through tough problems with people regardless of their skill level.

What I think is far more dubious is the relatively recent slippery slope towards the notion that someone should reasonably be expected that career progress dovetails with some sort of natural law that says you are not being a good human if you aren't willing-to-excited to spend 70% of your productive time in a semi-permanent state of continuous partial attention because the people around you demand priority access to your time and attention, above any of your personal priorities or job responsibilities, often without compensation beyond a rote "thanks".

If you can't ship inside of a deadline because your ephemeral "mentoring" took implicit priority over your actual job, then something is very wrong with people's expectations of how key talent's time should be allocated.

	▲	em-bee 2 days ago \| parent [-]
		having this talk over dinner sounds nice :-) german law or courts operate more on common sense than the letter of the law. to be able to reject a task from your boss the task has to be unreasonable. training/mentoring is not unreasonable unless the work is dangerous and/or a trainer needs specific qualifications. running a class that teaches some generic topic like a programming language would probably be unreasonable because you could just hire an external trainer for that. the training has to be rather specific to the individual experience of the senior or some company internal knowledge to be reasonable. so this doesn't apply to the scenarios you seem to have in mind. in any case from what i read it is recommended to talk to a lawyer before refusing. but also, if the request interferes with your ability to do your normal work then you can and should speak up and you can reasonably refuse if your boss doesn't make accommodations for that. if he doesn't then refusal is reasonable, not because training wouldn't be your job, but because your workload has increased, which is not ok.