imo, this all comes down to the fact that management is still not able to assess the quality (or even the real nature) of developers work. Of course there are managers who are developers but they themselves speak a very different language with the people above them so it’s really easy for them to convince upper management that they (and their team) are doing the good thing.
I’m not blaming anyone here, we are just workers that are a little less abused than the others. But as a developer who is not really fond of tinkering things (at work), I’ve seen things. This industry never stopped to promote developers based on their LoC count regardless of the business efficiency.
In fact I’ve seen people become millionaires because they wrote extremely generic frameworks (akin to netcore, angular or bootstrap but "invented here") which then became the company’s SPOF once they left. Good for them, but I’m still amazed that upper management never realizes when they are paying someone during 4 or 5 full time years because he didn’t like Bootstrap (won’t blame him) and convinced his hierarchy that we needed to develop our own competitor.
Oh and don’t read any jealousy in my comment, the only bitterness I have is against myself, because at the end of the day, if management doesn’t care about the real output, they deserve to be served a $500k brand new css framework.
I come across lots of situations, with legitimately bright developers, who have replaced a standard subsystem either a home-grown one, usually for performance reasons.
In that moment in time, in that context, the general solution was less performant or had an ugly bug, or whatever, so they replaced it with something designed for the one specific context.
But then the context changed, and now heres this bastard-child that's been narrowly designed, and optimised for performance (so hard to maintain or change. ). And the developer is somwhere else.
But equally I've spent a career writing the "new standard solution", which of course started out as an alternative to "the standard solution". And in our context that -has- made a huge difference. So it eould by hypocritical if me to say "stay inside the box".
If you do need to get outside the box, I would give some advice though.
A) documentation. Nobody likes doing this, but this is the most important part. If it's not documented properly, it doesn't exist. And just the act of documentation will show you where the design is deficient.
B) write your code as clean as you can. Make it easy to follow. Make it easy to read. Try not yo be clever and where you are clever don't skimp on the comments. You'll thank yourself for this later.
C) as much as possible try and build for the general case, not the one in front of you. The more useful this vote is the more it'll be used. The more it's used, the easier it is to identify flaws.
In summary - stay on the main road. But if you do need to forge your own path, make sure it's done properly, not some single lane gravel dirt thing.
However, that’s just my personal experience, it’s possible that I’ve only seen the wrong kind of companies.
Sometimes the person really is brilliant and you should do anything to keep them. But if it's because they're the only one who understands their code, then they are a liability.
Or is the hero deliberately sabotaging such efforts to maintain scarcity, and thus their higher value?
If you a middle manager that's really, really good at upmanagement, they can make things a little better.
