DPM is in redesign.
The title says it all. Every operation consisting of more than one atomic operation is intrinsically stateful, and that makes idempotency harder.
On the job front, interviews are ongoing. Crushed a couple of them. Needed the win. Need the job more than I need the win. One of them is in person a few days a week though. Ew. Yeah. In 2026, too.
Anyway, that’s a slow, maddening process that I never liked. I don’t like talking myself up to people.
The DPM redesign is interesting. DPM is going to stay modular, but where things live and how they work is going to change. It’s going to have modules that provide basic functions and then as dependencies get installed it’ll add new modules that use those dependencies and wrap the more basic modules to do what they do, so that the implementations don’t spread to multiple locations. At least, that’s the version I’m considering doing a viability study with. I’ll be doing a refresh of Dyad and Pyrois at the same time in between stuff to do some testing on an updated image to look at what actual dependency trees I’d be shortening and how much, as, it may simply not be worth the effort to modularize that far out and to just install the dependencies and replace with native packages after those are built. Considering once it’s installed on the image we’re moving to a package based distribution anyway, I feel like the modularity is a secondary concern, but, then I also see potential for extending the package manager functionality later and don’t want to have to pull out so many wires to do that once its in place — a modular package manager /does/ make sense, but how many there are for core functionality is really what’s being evaluated.
Meanwhile it’s “apply, apply, apply, network, network, network”, in between AWS refreshes, Kubernetes courses, Terraform refreshes because god help me if they come up at one of these interviews — it’s been at least 6 years since I’ve touched at least Terraform and Kubernetes, and I’ve always rejected native services at the CSP level because they’re designed to create overhead and cost and that awareness isn’t baked into their training (quite the contrary).
IaaS was the last service model this industry created that was actually made to do what companies actually need to do in the cloud, but that’s a can of worms you don’t want to open after a sufficient level of investment in a CSP.
Kubernetes is in the same boat. It’s pure overhead and bloat for most workloads, underperforms compared to monolithic architecture for most of the same use cases, it’s adoption is often cargo-cult — it’s built by devs, for devs, without a systems view in sight, and devs and infrastructure people view infrastructure in completely different ways. For most web platforms it’s entirely the wrong architecture and it costs companies millions keeping it. You’ll never hear that in a training video. You’ll never hear it on an engineering floor. People that don’t see it won’t ever agree with you or believe you, and you’ll create a discontinuity that’s relationship disrupting. Don’t ever say it if you ever notice it.
Every company says they use it. Then whenever I’ve seen a place and look, that they don’t but were trying to bring it in at one point because they believed it’s the next big standard, or they have a dead pilot going with it, but so far they never have because of the problems it introduced and it feels like I’m revealing an industry secret saying that. Gartner would disagree. So would the big 5. And their marketing teams. And the engineers that listen to those marketing teams. Is every company I’ve ever worked at in my 2 decades of being a contractor a bizarre exception or is the marketing chain split from reality? Somewhere in between? I have to rely on my direct experience with it. I’m not against kubernetes or containerization, but, I have to point out that primarily it’s the people selling it that are driving it aside from consumers who look to them for their standard when I see advocacy for it in colleagues. I’ve always thought that dynamic was so weird.
Containerization itself was a rushed concept. It’s a good idea for isolation. In practice, though, it results in some really insecure practices and supply chain gambles that have plagued the industry at a huge and invisible scale — not because containerization is bad, it isn’t bad at all, but because of how the tools that work with containers decided to be implemented. Built by devs, for devs, without systems people involved. That’s how you got NodeJS and the travesty of a security problem, dubbed “NPM”. Devs and Infrastructure people look at systems in very different ways and that’s largely invisible to alot of devs.
Then it was Serverless, which, well, let’s face it, it’s not “serverless” you just don’t see the servers. It has some uses. Most of them aren’t common.
Then it was “low-code” which fell hard on its ass as a gimmick. Then it was “no-code”. Also a failure.
Then we started advertising and popularisiging engineering gaps as features, like “DSL” (domain specific languages). Sure, DSLs in various forms have been around for decades, but look at these half-cooked configuration languages being called DSLs just to avoid using proper established object notation formats. We even split away from JSON towards YAML because the concept of standardizing object notation was so aversive to large product creators for some reason.
In better news, companies are starting to recover a bit from the AI psychosis. It’s got its uses but how it can be used and what it should be used for, and what types of results to expect are starting to become more understood by the market, and so the fat-trimming excuses don’t work as well. It’s expected over the next year or so that hiring will broadly open up. That does me no good at the moment until I’m cashing checks but it’s a hint of a light at the end of the tunnel, even if the only thing anyone is talking about is AI instead of what problems they’re actually solving.
Approval gates are the next big realization. A team of 10x devs can’t do 10x code approvals without 10x+ risk. On this one the market might thrash around a bit with various emergent subspecies of Agile models or maybe even something new but I think this is going to run into a natural throughput vs. risk barrier that surfaces once the math kids get their hands on the problem, but, I don’t know if we’re going to be allowed to say that until someone at google says it.
My biggest concern is, this space chases so many trends, and, the sources of tool market share consensus are largely rooted in marketing strategy output, so, there’s a very fractured reality at play. I’m not great at navigating manufactured realities. The manufacturers are hard to tolerate and the followers are often judgmental and dangerous to correct. So which shards of whose reality should I operate with to maintain the most industry competence?
It isn’t as simple anymore as just learning your craft, you have to navigate a multiverse of opinions and potentially fabricated data. Learn, unlearn, relearn. The human brain simply wasn’t made to do what we’re making normal and we do it with everything.