> People didn’t challenge them because it was exhausting, because they knew best, despite their constant churning out of garbage code that the business didn’t have the guts to address.
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...
Difficult to say without knowing the OP personally, but in my experience, all of this can square.
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 how it is at every company. The older developers create the universe new developers need to figure out. ON average newer developers don't perform as well as the older ones. This effect is highly correlated by the complexity of the code base.
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...