They have built an orchestrator, not Kubernetes. There is one key difference: they know this thing, end-to-end, down to every single bolt and piece of duct tape (with possible exception for Docker internals)
And that's a very important distinction when it comes to maintaining complex systems. This could've changed with LLMs (I'm still adjusting to what new capabilities mean for various decision-making logic), but before machine intelligence debugging an issue with Kubernetes could've been a whole world of pain.
And chances are only they know it. If my role has enough cluster access, I can muddle through pretty much any helm chart (with lots of cursing, yes) but it might take me days to set up whatever elaborate bespoke environment and script invocations are needed to replicate the current production setup maybe.
> This is a modern “oops, I ran DROP TABLE on the production database” story.
It's not that story, though. It's a story "oops, my tool ran DROP TABLE on the production database" (blaming the tool). At least I haven't heard people blaming their terminals or database clients as if the tool is somehow responsible for it.
We’d all wish it’d be so, doctor. Sometimes it’s as clean as biological systems - touch something somewhere, a different seemingly completely unrelated thing elsewhere breaks.
Even in the dawn of the era, where accumulated complexity was a while lot lower, we have tales of 500-mile emails and “magic/more magic” switch ;-)
Inferring things in a legacy codebase old enough to drink can be quite a challenge. And the way I get it, you folks are dealing with a multimillenia-old mess of layering violations - so no surprise first principles are tricky.
Indeed, but then not surprising. Russia haven’t ever had developed a mature democracy, it merely had a very brief chance at taking long road of becoming one, and everything went off the rails in just a decade or so. Kind of a handicap when it comes to keeping bloodthirsty politicians and siloviki in check.
At least that produces tangible value for the rest of us this way.
Current idea of sports is that athletes wreck themselves for mere performance value (and money to the people who set it up, with a bit trickling down to athletes for enabling it all). As far as I understand, nothing they directly do is otherwise reusable to anyone else.
I’d rather watch a live commercial for human enhancement industries. At least that’s something that eventually becomes available to everyone.
Nah, it's simpler. Microsoft just lost sense of UX and touch with the reality to their own internal management vibes.
Look at the Windows start menu. It used to be trivial to switch users. Two clicks, one to open the user list, another to switch - done. Now it's four: user panel, three-dots, switch user, pick user.
Look at the login sequence. They want their Windows Hello and they don't care if it works well or not - no way to get a pin or password prompt instantly, you gotta click three times (one to show a method picker, another to pick PIN entry, and lastly one to focus the goddamn field) despite no reasons to hide this UI.
It's not like they're trying to scam or sell user into something. It looks like some internal decision-makers that don't ever dogfood their decisions losing touch with the common sense.
Apple has that too, and this rot spreads elsewhere. But it's not intently malicious, a lot of things simply don't make sense - just total lack of self-reflection capabilities at the corporate level.
A lengthy preamble and then just… an advice to keep kicking, remain curious, tinker around and see how things are now, adjust to the new situation?
Am I missing something? Because it was always like that, you stop exploring and playing with new stuff and in just a blink you’re no longer relevant. (Which sucks if you’re burnt out or depressed.)
Ultimately he's pointing out the scope of the changes is significantly different. It's nothing like before when you could've kept up by learning new programming languages and frameworks.
Where we're going, programming languages and frameworks are rapidly losing relevance.
Ultimately it's still the same thing - problem solving in specific domains.
Languages and frameworks and libraries and IDEs and agent systems are all - in the end - just some new tooling, they were always the lower-hanging fruit. Cool, fancy, do novel magic, open paths previously unknown or thought impractical or unrealistic, but still - it's just some new ideas and instruments and ways how to use those efficiently - all to write programs that match our needs and fulfill our expectations, making things happen.
Nothing about underlying principles of software engineering had changed - some methods became more feasible, ML got really hot (and very rightfully so), but overall software projects are still software projects. Just recently I've looked at some machine-assisted software development courses and it was just the same good old "use your head, try your best to do things right or bad things happen, and here are the important gotchas of the day that you're best to constantly stay mindful about" material, just with "the machine can very rapidly produce code now, but it's not your code until you comprehend it" flavor, followed with a showcase of capabilities and features of newest tools on the market.
In my understanding, the eternal hustle still stays the same: find a passion, get into something, keep up with others, continuously learn new stuff, try to think something of your own and share, try to produce valuable things that others are willing to pay for, repeat until you can't anymore. Current state of "AI" doesn't disrupt this at all. Although it pushes the tempo up, and the times are stressful even without it.
And that's a very important distinction when it comes to maintaining complex systems. This could've changed with LLMs (I'm still adjusting to what new capabilities mean for various decision-making logic), but before machine intelligence debugging an issue with Kubernetes could've been a whole world of pain.
reply