Which, for example, gets you more sway with your employer, personal "branding" value, and future income / ease of switching jobs: "I was instrumental in inventing React" versus "I was instrumental in realizing we didn't need to invent React"?
Well yeah, but first someone has to get the credit for creating some "high-productivity" hog of a framework to make it slow, then someone else can come tear all that crap out and claim they made it fast.
I guess it depends on if you frame it: "I was instrumental in adding complexity under the false promise of ease of development" versus "I was instrumental in saving the company time, money, and improving the product for our users."
Things like this are why I'm glad I'm not in the bubble anymore.
"I was instrumental in a major rewrite for [REASONS]" vs "We kept it the way it was because it was good enough and a rewrite would've improved [X] but hurt [Y]"
At a previous employer, I was dumped a client lib and server whose purpose was to maintain a data cache with realtime updates. It was fragile and slow as fuck.
When I got ahold of the source and started diving into it, discovered the client had 2 copies of the data, which was kept in memory. The server had 3 copies of the data in memory! Worse yet, the primary cache would be updated, then a multicast message was broadcast to update all the clients and the server's secondary and tertiary caches...thats right: the server would update the 2 other caches by broadcasting a multicast message, receiving it, then updating the other 2 after message receipt. A re-architecture was definitely in order. Took 3 months. Took another 3 months to get the interface to be backwards compatible with the original version.
Mind, the server was responsible for serving up relatively static market data for finance. But, considering we traded globally, we had +400 objects we cached, more than a few had 100ks of record. Memory usage for the server was many GB.
The rewrite involved moving to a single cache, instead of multiple for both client & server. It was also architected to handle large volumes of updates. Original implementation could even handle 100 updates per hour without bringing the server's and all clients to their knees. The write could handle +10k updates per second amd clients would barely notice a slowdown. Write locks were only held for a pointer swap. Memory usage for the server went down by close to 2/3. Client memory usage by 1/2.
During that time, also moved from static libs to dynamic on both Linux and Windows, so I could make nonbreaking changes without a firm wide recompile/relink, which typically took 3 days. HUGE productivity boost. A small bugfix didn't require a firmwide recompile/relock for the smallest bugfix.
