That doesn't square with how people are going out of their way to query OP though, no? If people drag you into meetings tangential to your work, it seems unlikely that they hate working with you...
There’s complex dynamics at play that are a product of the genius developer mythology: someone produces a lot of code, the system becomes an extension of that person, everyone becomes dependent upon that person regardless of whether the person is good or bad, enjoyable to work with or not, because they’re the genius system-whisperer.
Earlier this year I spent some time at a company that has an incomprehensible system that is deeply problematic and painful to work on — so much so, they brought on dozens of developers to try and speed up the rate of delivery (I was one of them) — but the person who built it (and is most productive in it) has been elevated into a position where he now owns the entire technical implementation for the company, and is responsible for designing the solution to the nightmare he created, despite clearly demonstrating he has no business doing so: he’s simultaneously a linchpin and incompetent.
There’s probably some version of the Peter Principle that applies to software engineering: a software engineer’s output will rise to the level where it’s a burden.
Part of the reason why I made this post is I can sense internally that I'm starting to lean on the whole "I know this thing better than you", which actually scares me. If I'm thinking it, I'm probably sub-communicating it.
Both this reply and your original one are solid thoughts.
> someone produces a lot of code, the system becomes an extension of that person, everyone becomes dependent upon that person regardless of whether the person is good or bad, enjoyable to work with or not, because they’re the genius system-whisperer.
I hope this is not true for myself, but your logic is sound. I see the truth in it, I just hope it's not the truth. You gave me something to reflect on.
Whenever I hand code over I ask, does it make sense? Usually they say something like, yep looks easy.
I used to think it was because I was a dumb ass and only wrote simple stuff, but finally realized it's because I spend large effort on making the code read like english. (Good function names, good variable names, code that looks like logical short sentences, etc.)
All this to say, if you make code it's own wiki, you can avoid "I know this thing better than you" quite effectively, and complex code can be made to seem quite simple.
You may already doing that, but thought I'd share in case it's helpful in any way!
This has happened to me in I think almost every company I've worked at. The person at the top really has no business being there and has produced a terribly bad system. Often they think very highly of themselves and have 0 self reflection. They'll be called into meetings as a subject matter expert on things they have no clue about.
The speed thing is also a clue often these dev rattled code out at a high pace without self reflecting on the code either.
Code being perfect and bug free is highly unlikely. I've worked with some very talented devs and there code always had something wrong with it. The type of dev that the OP fit into would argue about something being a bug to make it seem like their code is perfect. So rather than a bug all their bug would become new features. A perfect cop out when something they write is less than perfect.
Doing 79% of the story points is a big red flag. You're hogging all the work when you do this and not letting anyone else in the team learn about what it is your building. It's a bad PO / SM that doesn't notice that one person in a team of 10 is doing almost all the work.
FYI this never ended well for the devs I've seen like this in the past. Either through M & A or change or leadership something will happen that knocks them off the top and their ego will take a massive beating once the new top dev comes in and takes over.
This is normal. The thing that affects the team the most in this case is the complexity of the code base.
A lot of comments are blaming speed for a supposed lack of sophistication, excessive duplication or disorganisation of the code.
But sometimes a developer can be fast is due to someone not introducing unnecessary complexity in the codebase.
A fast developer is not necessarily a 10x developer, but it also isn't making a mess.
Most of the cases of unmanageable code were made by developers with a lot of time and planning on their hands.
Sometimes the "10x engineer" is just the one that's loudest and most persistent. Doesn't mean they're good. Just means no one else can be fucked dealing with them.
This can have the paradoxical effect of people relying on them less in situations where they should, because they think the 10x doesn't know anything, and instead they turn to the braggart 1/10x programmer who claims he knows everything. (Not meaning the OP on this; I just know a guy IRL who is exactly this.)
(It seems to me, though, that OP is both competent and reasonably confident, a good combination.)
Also: (1) It is easy to say "from my experience" without sampling from it representatively. (2) It can be difficult, in general, to gather life experience that is balanced across all four elements of the confusion matrix. (This is a general statement that includes survivorship bias.)
That’s not to say you’re bad or your code is bad, but it’s definitely worth considering whether the way you’re measuring yourself is a true reflection of your value: have you talked to your co-workers about what it’s like to work with you? What value you provide to them? How you can contribute to their careers, their work? The greatest value you can deliver to a business is rarely code: if you can improve every other developer by 1x, the business will be much better off than you being on an island all by yourself.
My measure of myself always starts with whether or not people enjoy working with me, whether I’m providing value to the people around me: I could write 10x as much code as I do now, but I don’t believe it would have better results for the company overall.