I draw a corollary to how graduate medical education works. You go into residency a fresh doctor with zero applicable skills. You may not even be CPR certified, but you're an MD/DO, and you've matched into a residency. You know less about actually helping people than a nurse who's been on the job for a month. You spend the next 3-7 years working 80-100 hours a week learning your chosen specialty. You become an absolute expert at your specific field. If you're in a surgical field you spend thousands of hours practicing and performing the surgeries you'll be responsible for. You may or may not specialize even further with a fellowship for another 1-4 years.

Then, when you graduate and can start making real money (probably), if you work at a hospital that does resident education, you're almost immediately expected to let the residents do as much as they can safely do, so they can learn. You go from working 80 hours a week performing surgery after surgery at a senior resident to working 30 hours a week watching the senior resident perform surgery.

Similarly (and admittedly it isn't a perfect analogy) as a junior and mid-level you're spending all this time learning how to write real software. Most of it's bad and especially at the junior level you're going to spend a couple years being more trouble than you're worth in terms of productivity. But by the time you're a senior, when you theoretically know what you're doing, you're going to have to spend most or a large portion of your time helping out the juniors in your org.

If you don't want to do that, you shouldn't be accepting senior positions. Or at least, go work somewhere where they don't hire juniors.

What if you just want to write software and not be responsible for mentorship? Why do capable individual contributors always have to be roped into leadership?

> What if you just want to write software and not be responsible for mentorship?

At a certain point, you probably know considerably more about the work than the people working around you. You might say you develop "seniority". At that point, the balance of value between your individual contributions and the knowledge you can share with others reaches a tipping point.

If you're limiting the value you're bringing to the company to only individual contributions, you're capping the value you can bring the company and by correlation the compensation you're due.

Work at places that don't hire junior devs.

I think there is a limit of the efficiency of a single person. At some point, helping out others to be more efficient is more efficient than doing it all by yourself.

With that said, I don't see anything wrong with stagnating at your peak IC efficiency if that's what makes you happy.

I agree with sibling which says that mentoring is not leadership. Helping out others is not the same as giving them instructions or evaluating performances for example. However I can understand that someone would like none of that.

As long as you are not your own boss (and even in this case, tbf), you are likely to not do only what you "want", because you are not the one defining what is your job.

Honestly, it's a weird remark. Pretty much all jobs on this planet have aspects you wish you don't have to do. You work for your employer and your employer needs you to train the juniors. If you don't want to do that, change for an employer who only recruit senior engineers, if you can.

Employment is a negotiation, always has been. Senior technical staff often negotiate from a position of strength.

I'm not sure I see mentoring as leadership as much as I see it as passing the experience along to someone less senior than you. Or did you become a capable IC in a vacuum, without the guidance of more senior engineers?

Beyond that, you could go into contracting. Do the work, point to your contract whenever someone asks something else of you, move on after 3-6 months, rinse and repeat.

I mean, actually, mostly yes. I've usually been the last stop for technical help since school. There hasn't been anyone I can go to, so I've had to figure everything out on my own. I guess I'm wanting to work with senior peers more so than constantly dealing with juniors who seem to get lazy because they know I can solve their problems for them, often trivially.

Not wanting to help juniors so they're left to struggle the way you did seems incredibly devoid of empathy. I could describe my career the same way you have, but mentoring juniors is now my favorite part of the job. When you were a junior, would you have been satisfied regurgitating a senior's answer without understanding it, or would you have wanted to learn? If you were into learning, why assume nobody else will be?

When pairing with juniors, I avoid directly solving problems for them as much as possible–lessons tend to stick better when you ask leading questions and let them discover solutions for themselves. Perhaps this technique would also work to filter out "lazy" questions.

Working with a mix of super competent developers at all levels has really driven home for me that everyone is better at something, and worse at something, than you are. I've learned lots of new things from developers with less experience than me. I've also worked with many devs with senior titles who were worse off than most juniors.

Ultimately it's okay to find mentoring unenjoyable, but if this describes you, please stick to teams with most/all seniors and don't agree to mentor even if pressured. Attitudes like this can really exacerbate imposter syndrome for juniors, and I've seen it damage several careers.

> I'm frankly somewhat disgusted

I wouldn’t want to work on a team with someone who has such an attitude. I’m very grateful to work in an environment where we all want to help one another. This really reminds me how good I’ve got it.

Do you really work in a team where people are not at all expected to try to help themselves?

> Why do capable individual contributors always have to be roped into leadership?

Training your replacement is how the cogs in the machine reproduce.

And yet a junior dev who LCd for a few months will get paid way more than a MD in residency. It might be interesting to see if the quality of people (measured with IQ) or some other simple metrics who pursue medicine relative to other fields have gone down over the past decade.

Let's say you are the cryptid 10x engineer/tech lead, supervising a team of 8 junior engineers. You can spend 4 hours, the equivalent of a 40hr week of lesser mortals (this math is almost never true in my experience), or spend a half hour of time on each of your junior engineers. The problem you help each of them solve is solved in 30m as opposed to the 3-4h they might have tried solving it themselves, and they've learned something that maybe saves them an hour a day. You do this twice during the week.

You've 'lost' 80h effectively of productivity for the company (remember, mythical 10x), but you've gained 104h (32h+32h+81h/day5days) from your team, for a net 24h gain.

Of course, numbers are exaggerated, but the point remains the same: if you are a tech lead helping your team succeed is your primary job, not coding/design. You are the person who connects the lines of communication, removes obstacles, mentors the team on coding and design, and gets the team moving in one direction that aligns with the customer needs.

You probably will code, to fill in gaps and help out, but personally I find it's split around 5/2/2/1 - 5 parts are working with your team to guide them and help them overcome obstacles, 2 parts communicating with management and customers, 2 parts coding/design, and 1 part administrivia/training.

This requires an environment where long term productivity is more important than short term productivity, it doesn't account for juniors who won't get it, no matter how hard they try, it doesn't account for juniors who will leave the company after becoming more proficient because they can't get an adequate payrise.

10x engineers can be a good match for startups where shipping now is essential and for big businesses who need something done quickly (for a change, the bigger the company, the slower everything else).

The only cons of 10x engineers is that they will burn out and that they're incredibly rare. Advising 10x engineers to help out other and collaborate is also nice to give them a bit of down time so they don't burn out and leave for the next startup with a 50% raise.

That said, it's not like HR managers are able to distinguish between senior low productivity engineers and 10x engineers, so it doesn't matter. No company will have a strategy around employees productivity.

I disagree the 10x engineer is a myth, as an hiring manager, I can easily tell you who is a 10x engineer after working with them for a year or so.