Hi, Shabang!
Good on you for asking this question. If you are looking for a sign that you are not conceited, asking “am I too conceited?” is a great first signal that you are not.
You ask how you can get feedback when you intimidate others with your success/output/influence. A very good question.
1. Be relentless in your admission of weakness. You see someone nodding at a half-formed idea as if it were genius “I’m sorry, I am barely making sense to myself here, I hope it's helping and I see you nodding along, if you're seeing something I am not seeing, great.”
2. Actively solicit. If someone else says your input was really helpful without feedback, “can I ask you for a favor? I'm trying to be more clear and succinct in how I communicate, and this looked kinda successful maybe, but was there anything I could have been more clear and succinct on, or any, like, important details I didn't really understand but just blew past?”
Some people on my team ask for approvals, “please approve my merge request.” I am always asking for feedback, “please tell me if anything looks unclear, if I need to comment something, whatever.”
After onboarding someone to a new system, “what was the hardest part of this to wrap your head around, is there a way for us to make it easier?” Or, “genuine question, if I asked you to just clean up tech debt on this repository for a month, where would you start?” ESPECIALLY do this with newbies. Someone who comes in as a blank slate has so much to give, the moment that they say “oh that surprises me, I would have thought we would have done this this way” you can rethink, “oh yeah why DON'T we do it that way?” and if you code it up and see no obvious reasons to do it the way you originally did it, you can ask them to rereview that code and you can ultimately merge it ... What an egoboost! Your newbie feels they delivered value from day 1, meanwhile you are seeing things from a different perspective.
3. When people are asking for your opinion, don't just give them one opinion. Even “Which would be better, A or B,” you can answer “well, I don't really understand the problem as well as you do, so I can't answer the question for you, I would choose A in situations that look like OPQ and I would choose B in situations that look like RST and for that matter I would choose C in situations like UVW and if it were a personal project or situation XYZ, I might just brute-force it with option D. But I don't know which of those trade-offs are the best in your case, your hunch is way better than any experience I have.”
Now to your other big question, you ask how to become less controlling and less frustrated with others. Two tips there.
1. Let it f**ing go. Seriously. 90% of these decisions are not important enough to justify blocking merge and release. They didn't insert a null check in a place where it comes automatic to you—so what? Here's the deal, learning is pain, more accurately learning is the relief that comes after feeling a pain over and over. Your desire that this other person never feel pain is this a desire that they not learn. You need to have the attitude of, “if I am wrong then I have learned something, if I am right then we can fix it later.” Just let the damn thing go, and your subordinates will learn and skin their knees and delete the prod database and grow.
2. Often people become 10x developers in a certain context because that context is full of landmines which they are able to avoid. The other people in that context are running into them and dying. But, you can find yourself in a rut.
Next time you are brushing your teeth, take note of what side you normally start on. Start on the opposite side. It's weird, uncomfortable, but not wrong. Next time you find yourself building code, maybe you start from a function that you're pretty sure you will need, start with some small examples, build out, eventually the larger structure will crystallize in your head? If that's you, reverse it. Pretend that you have an AI bot that, just by naming a function, will properly implement it for you, and start from the outside and build your way down to the details and the nitty gritty. Or if you program outside-in, flip this advice and program from the inside out.
You KNOW there is more than one way to do it, you are a smart person, obviously. But you have to FEEL that there is more than one way to do it, that is harder & needs to be drilled and trained.
3. Invest your surplus. You are 71% of the story points vs 9 others, correct me if I am wrong but that makes you a 22x developer. You commit to investing 20% of that and you become an 18x developer, nobody is going to complain. 2 hours a day or one day a week, however you can arrange it. What do you do with that time? Many options.
Maybe you mentor others on your team. “Oh Shabang, I can't take up your time, your time is very valuable.” NO! There is literally nothing more valuable that I can be doing than making you more productive. Because that's linear versus quadratic growth. Actually if I can get you trading the next generation too, it's exponential growth. It doesn't matter what the coefficient is, quadratic beats out linear eventually.
But you have indicated that you are not so interested in the management track and that is totally fine, you should be able to remain an individual programmer without needing to become a manager in order to get ahead. So what does that look like? One way: You invest in a new technology. Say you decide to do machine learning, you go learn some PyTorch, you build some models and train them, see if you can't apply it to some random problems at work. Another way, favored by the late Joe Armstrong, you invest the 20% in rewriting. You deliberately take 25% of your remaining story point load and nominate things to be implemented twice. You build it once and learn the shape of the problem and then you build it again. Can be combined with the previous idea, you decide to learn functional reactive programming or μKanren or Rust or what have you, by taking 10% of your story points and reimplementing them in those styles, assuming that you need to spend at least as long as the original bug just understanding what the new idioms are.
The goal here is to get to the point where, if someone else has a novel approach, you are no longer saying no to them, rather you are coming up the next day and saying, “hey that sounded really interesting, I wrote this proof of concept, is that what you were going for?”...
The golden rule of standup comedy, you never say “no,” you say “yes, and.” when someone says “We will just leave the authentication token off of that endpoint,” you suppress your sense of saying “no, every endpoint needs authentication, don't be ridiculous” but instead try to see their needs and say “yes, and we can build a way to instead authenticate by cookie/track the requests some other way/automatically audit accesses and limit the rate at which they are provided so it's not useful unless you know exactly what you're are doing/whatever.”
Hope thpse bits of advice help?