golddust-gecko

I think it's ultimately about finding the organization that fits the workflow you want.

This is a key point, and one that is rarely articulated.

The problem -- for me, anyway -- with the Current Era is specifically the workload, but the relentlessness.

I'm old enough to remember the Old Days of big release dates. You'd grind for a while, sometimes in a deathmarch, but after the release the organization would relax and there would be _some_ slack.

Now it's an endless river of prompts, push to prod, fix, repeat ad nauseam. Because implementation is now much cheaper but genuinely good ideas are as scarce as ever, companies are turning into a random walk optimizations weirdly mirroring training regimes. The idea apparently being that you make enough features/changes you'll eventually find the key to unlocking hyper-growth.

But unlike a training system, all these intermediate steps compound. Customers find their software mutating under them at an alarming rate. Maintainability becomes barely possible, even with Claude doing a ton of work. We're just creating technical debt we expect the future AI to fix, and getting no closer to the "revenue unlock."

Many are chained with fear to this dehumanizing and demoralizing system, and it sucks.

This is I think a very common issue. The term "startup" has two connotations: a nascent business trying to find its product/market fit and "a private business whose capital structure is dominated by VC money"

Companies that fall out of the first definition -- they've found their market, such as it is, but it's smaller, more competitive etc., than is needed for hypergrowth -- but are still in the second definition are in a bind. They've generally used up all their ideas, and have created a nice, small business. This should be a win, but in SV it's the worst kind of failure. The VCs aren't going to want to book a loss, so the company thrashes about trying to figure what else to do while trying to keep its business running. They should and ought to be evaluated using normal accounting, but that would mean the value of the business is a fraction of its "valudation"

This ends in the company being strangled by its own mal-investment, or sheer exhaustion when everyone, the management and the VCs, face reality, take the L, and leave the business for private equity to run off the remaining terminal value. Maybe sometimes this becomes a lifestyle business, but more than likely it's just a transition from the washing machine of "this month's great idea for growth" (they never pan out) to the grind of cost-cutting and extracting any customer surplus out of the system, leaving everyone miserable.

Yet I am immensely grateful that my ancestors chose to build homes and marry and have children

I think this premise is questionable. I double that choice had much to do with it, for most of our ancestors. In particular a large fraction of children (majority?) born were not born out the free choice of the parents, but rather as a result of accident, social pressure/expectation, economic necessity etc.

Given a free choice, the same uncertain and/or bleak future produces the rational outcome that it does not seem prudent to have children.

I feel like this part is either a mistake, or a whole story in itself:

This premise was based on the results of a 1940 study by Ichiro Tani, a Japanese scientist who demonstrated the relationship between surface roughness (an indicator of the state of the machined surface) and turbulent transition, arguing that surface roughness, which was unavoidable with the manufacturing technology of the time, prevented laminar flow from being realized.

However, in 1989 Tani reinterpreted the experimental data on rough-surfaced pipes obtained by fluid engineer Johann Nikulase in the 1930s, suggesting that “roughness may not necessarily only promote turbulent transition and increase fluid resistance.”

So if true, this means that Tani was working on the same problem for 49 years.

Evidently [he died in 1990](https://www.wikidata.org/wiki/Q24868684), so it's at least possible.

100% this.

I'll also add another factor: it's become increasingly clear at our company that AI-enabled humans are getting to the bottom of the backlog of feature ideas much quicker. This makes the 'good ideas' part of the business the rate limiting step. And those are definitely not increasing with AI, beyond that generated by the AI churn itself ("let's bolt on a chat experience or an MCP!")

So maybe the coding assistants don't get a 10x improvement any time soon, but we see engineering job market contraction because there aren't really enough good ideas to turn into code.

"GitHub only gets better if people who give a shit stick around to make it better"

At best that's half of the equation. You also have to continually hire new people who give a shit, and you have to do that within the context of Microsoft.

Given the rot already evident, there really isn't any incentive for people who care to join. They would have to care more than the organization does about the product, and there would have to be many of them.

Once product in large companies get to this point, there's no real way back. Quality will max out at the minimum required to retain the revenue. And if that fails for too long, it'll be put in product hospice.

This is 100% true.

You might wonder why, if businesses are the target, why not just make Windows a no-frills, solid base for the other offerings? Why slop it up?

The answer there is cultural. Windows needs a large team just to keep supporting it at scale. All those engineers and PMs need career paths, and shiny things with which to sway their managers into promoting them. The strong, experienced, leaders have largely left because they know this isn't a company priority. So you end up with B players promoting C players for slop.

Time goes on and the Bs become Cs, and so on.

So the dynamic is that something that isn't a priority doesn't merely slop evolving, it devolves. We're now several iterations into this process, which will accelerate due to AI.

100% -- the conventional wisdom was that the x86 architecture was too riddled with legacy and complexity to improve its performance, and was a dead end.

Itanium never met an exotic computer architecture journal article that it didn't try and incorporate. Initially this was viewed as "wow such amazing VLIW magic will obviously dominate" and subsequently as "this complexity makes it hard to write a good compiler for, and the performance benefit just doesn't justify it."

Intel had to respond to AMD with their "x86-64" copy, though it really didn't want to.

Eventually it became obvious that the amd64/x64/x86-64 chips were going to exceed Itanium in performance, and with the massive momentum of legacy on its side and Itanium was toast.

Agree 100% with this. It gives the illusion of understanding, like when a precocious 6 year old learns the word "precocious" and feels smart because they have can say it. Or any movie with tech or science with <technical speak>.

Perhaps it's nothing, but:

“GitHub and its leadership team will continue its mission as part of Microsoft’s CoreAI organization, with more details shared soon,” says Dohmke in a memo to GitHub employees today. “I’ll be staying through the end of 2025 to help guide the transition and am leaving with a deep sense of pride in everything we’ve built as a remote-first organization spread around the world.”

Is interesting to me. There is quite a number of rumors that MSFT will be Returning to Office next year. The prominence of 'remote first' in this quote may indicate that such concerns are playing a role here...