Goodbye, and Thanks for All the Bikesheds

In addition to Second System Syndrome that has already been covered, I think there are several other things going on here that lead to the tug of war.

In another reply I already mentioned a flavor of Sunk Cost, which is resistance to any change to the code that 'made us successful' because they consider they have already won and taking it away now is some sort of revisionist history effort instead of just Progress. Hofstadter's Law, which tells you we still have plenty of time, despite three initiatives already having finished long past the point of maximum tolerable pain already.

But more damningly, I have worked with a lot of people who want to skip from Make it Work straight to Make it Fast without Making it Right in the middle. Those are the people who, among other things, reach for caching too early, and then declare the war for cost reductions over before they've even started, because there are no perf analysis tools that can see past and around the caching logic to find the issues that caching either didn't fix or made much much worse.

I'm not advocating for making hot decisions at every point along the way. I'm advocating for people having enough experience and foresight to understand which 20% of the code flow is Architecture from which is just feature factory work and making sure that 20% gets 80% of the design thinking and timely preventative maintenance.

On a couple projects I've just done all that myself. But it is a quick road to being a bottleneck and then to burnout. You have to aggressively recruit people to be bus numbers on all of those things. This is part of why I do so much mentoring.

Always fun when they manage to categorize it wrong 3 times in a row.

One of the hardest parts of my job is trying to convince people where the pool of blood on the floor is coming from. We are forever stitching up the wrong wounds and missing others entirely.

Pain sneaks up on people and they often don't realize they're in pain until someone takes it away. This is probably why Refactoring is one of my favorite tech books. It's a set of tools and justifications for chipping away at that pain bit by bit, instead of tolerating more and more while productivity grinds to a halt.

At the end of the day, if only three people really have to care about a thing and they're fine with it, is it their business to run the project the way they prefer/tolerate? It does matter if the opportunity costs and externalities are affecting other projects. If they don't have time to work on other features because of the mistakes they never correct. If other people's flow is constantly interrupted trying to work around their quirky stuff. But if we don't see any of that, or only rarely, then it's more that my internal architect trying to be bossy rather than lift all boats.

Let me rephrase that. I've seen a few cases where it became a major issue, rather than just being a fact.

Often people are smart enough to not ask questions they don't want the answer to. If the three people trusted to handle a problem all are in agreement as to how, then the peanut gallery may just be confounding issues in order to pad resumes or to feel important and involved.

Bike shedding means no decision of consequence is made. People wanted to participate in something, and they sucked all of the oxygen out of the room for other decisions.

It's that important decisions were either not made or got insufficient scrutiny that's the problem. So aggressively shutting down bike shedding that is actually bike shedding by picking a solution and moving on or tabling the discussion to let a team of 2 solve it offline is what you're after.

Sometimes though, bike shedding can be a delay tactic. We have a decision we are not ready to make that someone is forcing a vote on, and there's a silent conspiracy to derail the conversation to avoid the vote for one more meeting.

And then there's people learning not to be responsible for anything, either as a career choice or due to previous trauma at this business. So they are asking for too much input so any consequences are not their fault alone. As you say, being a coin flipper in such situations becomes its own soft power. I've worked at a couple places where a handful of people clearly followed my advice solely because they knew I'd say it was my fault if things went wrong. They just wanted a Decider and I sounded like one so they did things the way I wanted them done. Their motivation was to avoid having to deal with being yelled at. I did my yelling in private, instead of turning it into an opportunity for public humiliation.

I'll fully grant that the vast majority of the time when I use the word neoliberal, it is indeed derisively. Doesn't change that this is, again, simply an observation that names the thing. Markets, localized or world, free or not, do not function in vacuums. They are shaped by ideologies, including that of the neoliberal school of thought.

It's frankly far more derisive of me and any reader really to say that because "free market" has the word "free" in it that the majority of people will cosign it happily with no further thought. Do you also think the DPRK is a democracy because it says so?

The EU has a large menagerie of businesses, successful and otherwise. If hiring friction and tax policy were the whole story, you'd expect the EU to lag in all capital-intensive industries, not just have a specific gap in hyperscale tech, which is the one sector most directly shaped by network effects and first-mover advantage from a market that let a handful of US firms scale first.

Additionally I'd push back on the premise that "doesn't produce hyperscalers" is even a mark against a system in the first place. They're what you get after competition has mostly finished collapsing into a handful of winners who then run the supposedly free market. Funny how the same people who'll lecture you for an hour about the sacred competitive forces of the free market go quiet the second vertical integration and monopoly-adjacent scale start choking those forces out.