I accept you're a gifted coder, and that you're better than your peers. Good, then do exactly that.
Being good at mentoring people is only vaguely correlated with being good at code. IMHO, the main factor that will make you good at something is caring about it, and if you don't want to talk to people you'll waste your skills.
There is someone out there who would love to talk to people, worry about their development, figure out how to best use your skills and so forth. Let them do it.
It seems to me, though, that OP vastly much better at that, than the others available. And that his co-workers have noticed this too.
A few interesting questions that come to mind.
1 - Does OP feel like they are doing the same things over and over again?
2 - Does OP want to work with better/more skilled engineers?
3 - Is OP setting the technical direction? Do they want to?
Being the top coder by commits in a group of 350 is a super power, however many "Hard" software problems are resistant to code throughput as a fix. There are extremely difficult software problems that take years to produce the ~1k line solution.
Hobbies, sports, instruments, hell even a book club. Get social outside of work. Treat it the same as you’ve been treating your career (dig in and get good). You’ll find you make friends outside of work, but often at work too, as you may have hobbies in common with others at your job.
This will naturally lead to a good work balance, because you may end up wanting to clock out early to get back to your hobby. You’re in a great negotiating position to reduce your hours when that happens.
It's always possible to find people who are so much ahead of you that you'll need to put effort into just following the conversation with them. And when you do, they're your peers and you're proud to be a 0.9x developer alongside them.
- Code editor plugins (or web or mobile apps) tailored to your org‘s workflows
- Language changes in case your org is using an OSS lang
- Libraries for often-used functionality
- DSLs that let your org‘s PMs encode behavior themselves
- Small utility apps (web or mobile) that facilitate more effective communication
- Dev tools for your stack, eg if you don’t have hot reloading yet, that’s a huge enabler
- Test data generators
- You mentioned that you setup automation. Take it a level further and let other devs create scripts by preparing an environment (maybe an IDE) for that
There are no hard and fast rules, but stuff that increases the productivity of other in a (to them) non-mystical way would be best.
It's a judgement call, some of these in the list above made me pause, but the red flags will be specific to each workplace.
The keys is to know what others will understand, and that is a super-power in itself.
I suspect they are feeling stressed because they're the main goto person on the product, and with enough random bobble heads running around trying to commit sacrilege on your codebase it quickly becomes a problem of control to maintain the quality you've so strongly instilled vs allowing the product to progress.
Their best path to get out of this bind I'd say is to slowly try to make themselves redundant on that product, choose a victim dev to be your successor and gradually disengage. Possibly a new product or project will be started and then they're free to get involved in that instead.
Also learn how to interview new candidates and get involved at that level, getting good (even better than you) coworkers is a great way to influence the whole company culture and make your work life much more pleasant.
That being said, tech megacorps are stressful environments, and OP looks like he has his plate full just accepting that he's become the de-facto lead developer. OP built his own niche market, why not dial it back a bit from eleven and learn to enjoy it?
If you haven't read it, "Staff Engineer" outlines some of the ways more experienced engineers continue to grow and provide value without becoming managers. I'd say the first half of it is worth a read to see if it sparks anything for you.
I will say that it gets lonelier as you go along either track. Reach out to peers if you have any. If not, try to reach out to folks outside of engineering.
It's a tricky path, and I wish you the best.
I know this because I've watched it happen many times, not because I'm one. I've had lead developers report to me and good ones can really have a great impact. The tooling, procedures, technical debt, etc. All will be positively impacted by someone like you.
If you're not enabling your team to take over your job, you're doing it wrong. And by a comment I saw elsewhere, the tendency to control things is natural, but you should resist that - it's the only way you can scale.
If your organization doesn't have that kind of individual contributor leveling, that would be a good conversation to have. Or if your team isn't big enough, maybe its time to look for a new challenge.
There will be a learning curve and a mindset shift, but it's really the only way that you truly become a force multiplier.
Soon, your commits will go down, but your reviews will go up.
Later, your reviews will go down, but your strategy/design/planning docs/conversations will go up. Your job is designing for the 1-3yr future (or more but rare) and across the organization.
BTW that's not isolation you're feeling. It's responsibility, respect, and frustration. You didn't ask for the first two, you earned them.
Specialists and Generalists tend not to respect each other, for example. Folks with CS degrees and autodidacts likewise (though both can have impostor syndrome comparing themselves to the other).
There are also three personality types (or cultural types) suited to different maturity stages of the system being worked on (which also implies different processes, BTW): Pioneers, Settlers, and Town Planners[0][1]. Many businesses tend to collect one or two of the three types. Pioneers+Settlers is viable, as is Settlers+Town Planners. Orgs that only have Pioneers+Town Planners tend to have interesting pilot programs that never get successfully rolled out.
[0] https://blog.gardeviance.org/2015/03/on-pioneers-settlers-to...
[1] https://swardley.medium.com/what-culture-is-right-for-you-ba...
I like mentorship, helping people figure stuff out, giving technical advice etc. I don't like going to zoom meetings all day, which is what "leadership" in today's modern world has become.
My problem is that I love code much more than talking to people all day. I have been mentoring Jr Devs for a while now in an official capacity which helps.
I like the idea of "make systemic changes to help your peers become more effective". So that's something I will have to think about.