Worst of breed software

I see this as a red flag, and an attitude problem typical of toxic employees. I'll explain why.

More often than not, I see this sort of complain from junior developers who either completely miss key requirements behind constraints or are completely oblivious to operational constraints. They invest little to no effort to try to understand the problem domain and what problems are fixed, and instead they redirect all their energy arguing for major rework that they claim makes things simpler albeit their analysis is superficial and simplistic as they are oblivious to the actual constraints. But that doesn't dissuade them.

This analysis failure ends up creating problems within the team because they conflate any lack of support for their half-baked ideas as an irrational opposition to their personal initiative, and thus somehow a part of the problem. Consequently, you start to see those types lashing out at team members and throwing accusations and being an all around pita. They pull these stunts at every single occurrence of any minor inconvenience, as if it automatically means anything else is always better than what they have.

The worst comes if these egregious types get their way. They roll out a change that they depict as a silver bullet for all inconveniences, except that even in ideal circumstances in the real world there are always minor inconveniences. When they surface, these egregious types get all defensive and throw tantrums to bully the team into suppressing any sort of criticism that they themselves spent their time creating for others.

There are many reasons why some companies impose and enforce principles such as "respect what came before" and "disagree and commit". No one wants to work with the assholes who don't follow these principles. Their output is always pristine and the shit shortcuts they took are always thoroughly justified, but he'll forbid if someone else's changes have anything that pricks their sense of taste.

It's a red flag. Clearly an attitude problem. Throwing a whole organization under the bus is a clear tell. If everyone around you is an asshole, the ugly truth is that you are very likely the only asshole around.

You're basically stating that people who are hired to staff projects that are superfluous secondary moonshots are more likely to be fired than those who maintain core business areas. That's stating the obvious. When a company goes through spending cuts, the first things to go are the money sinks and fluff projects that are not in any key roadmap. This is also why some companies structure their whole orgs around specific projects and even project features, because management limits the impact of getting rid of entire teams by framing that as killing projects or delays in roadmap.

I wasn’t trying to rework everything and I am not 100% sure how you reached that conclusion. There were just plenty of times that for certain things there were clear simpler ways of doing things but those weren’t sexy and you were only incentivized to constantly do things to make yourself seem important instead of actually doing work.

I’m not an idiot, I know that you cannot rewrite everything in a 20+ year old codebase, and I wasn’t suggesting as much. At BigCo, instead of actually doing work, you instead were expected to hold several meetings about every minor change you were going to make, come up with a million classes and abstractions that serve no purpose other than to increase your LOC count, and then have a bunch of things to point to at your end of year self-review.

I am pretty sure most of my teammates liked me just fine, because I was generally not critical of any individuals code, because I felt like most of these issues were top down. Management created a situation that if you wanted to get a reasonable yearly pay raise you had to be able to point to a bunch of “big successes” (their words) in your yearly “self review”. Great if you have big projects to point to, but if you’re working on a “keep the lights on” team like I was, you start running out of new proper nouns to list. Instead have to constantly rebrand any small small thing you do as an “initiative”, and you point to the dozen meetings you called for it, and maybe even literally mention the LOC written for it.

Companies that have been around for awhile will always have cruft, and I agree, a lot of seemingly “stupid” code actually has a good reason for being that way, and I knew that even at the time. The code quality itself wasn’t really what I was complaining about, it was the politics around it.

But please go on about how you think that I shouldn’t be able to express my frustration at a corporation’s idiotic policies at an exit interview.