Then when they need senior devs again, they can make a good offer.

I think the point is, what happens once all the current senior devs are gone?

If no one trains the next generation of developers, who will maintain and build the systems of the future?

Senior developers like me, for a price.

Yes, I mentioned collapseOS in the post. I think it's very interesting.

For when there is no electricity, I think we're past the point of "software" at that point. I'm not exactly aiming for a guide to a "full-on everything is gone" situation. More like, "very bad situation which there is still some levels of civilization". I mainly used the word apocalypse because saying " we need software for when things are very bad, like revolutions and wars and partial supply chain collapse" didn't really sound interesting.

Thanks for reading!

Unsure about offline-first, but yes, local-first, for which a LAN is enough and no cloud is needed, is very much what I'd rather we depended on more, instead of what's considered professional and an industry standard. Organizations requiring SaaS (as in, a network of 20 computers simultaneously becoming unable to open an app because the Internet went down) in a country experiencing war and blackouts is an additional source of stress. Free software requiring containers and gigabytes of dependencies is also suboptimal, we should aim to simplify native packaging for GNU/Linux and BSD distributions.

Another thing, programmer visions of what would suffice in bad situations are often very Western, anglophone. Software, including operating systems, eschewing localization in a quest for a lightweight footprint are not accessible or are outright unusable for the majority of the people in the world. Please take care to make your software possible to translate, including documentation. Best if the focus is on tutorials and handbooks; manpages are less of a priority.

These are not really post apocalyptic, or we have a different definition of an apocalypse. They are just federated, and work offline, but it assumes you still have electricity and access to modern hardware.

More post apocalyptic solutions existed for ages, my "favorite" is Collapse OS: It assumes all supply chains of hardware manufacturing will disappear, so we have to build with what we have: https://collapseos.org/

I think the HOW and WHY here are really important:

By incorporating copyleft data into their models, the LLMs do share the work - but not alike. Instead, the AI strips the work of its provenance and transforms it to be copyright free.

That is because the US copyright office has rightly advised that AI generated works are not copyrighted.

So crucially, here, we have them gobbling up methods and ideas and passing them off as their own, stripping the code of its copyright protection.

There's a whole other argument to be made about whether the cod actually works, but that feels too close to being apologist for me.

Lol we did something like this at work once and it was pretty fun.

Here's an idea: it's a royal pain in the ass to transfer Firefox data from one mobile device to another without using their cloud sync feature. I'd love a way to do that while keeping the data local only.

It sounds like the problem you describe is not with the concept of using serverless/faas cloud compute and adjacent services, but with the design and implementation done by some engineers you work with. That may be due to time constraints, lack of familiarity, engineering skill, or some other reason.

I've seen terrible containers, terrible vms, terrible bare metal servers. I've written good and bad myself. And yes, I've seen (and done) great implementation of serverless. It's all just tools to be used.

Everytime I see serverless used - it's always some illiterate frontender building next.js on lambdas. Always slow as molasses, always inflexible af.

This reads as if someone doesn't understand cloud compute, iac, and so on, and just got frustrated trying to learn and explore the paradigm.

That's fine, but blaming "serverless" or aws lambda is like blaming a multicore cpu for having to learn threads and subprocceses.

Maybe I have been lucky, but I've never seen a company (including "cloud-native" ones) use serverless (code compute) like this. Lambdas only ever get used for tiny, atomic functions in my experience. Never heard of or seen someone try to do a 20-minute video conversion in lambda.

Any tool misused is a handicap, and I feel like the architecture presented here isn't making it clear that serverless code compute was ever right for this task.

For instance, if video processing is being done on a constant or consistent, non-ad-hoc basis, why is serverless being used at all? Who made that decision? If it's infrequent enough that it doesn't make cost sense to run a whole dedicated instance, why not have a Fargate node (container) or something that encapsulates the "background worker" portion of the process? That would let you have an equivalent "simple" flow as in the original process diag, but without the limitations of doing everything in Lambda.

Lambda is great for things like building SOAR flows, e.g. disabling network access to a compromised instance, taking a snapshot, pulling logs, etc. Infrequent, able to combine cloud infra and host-internal actions, and fast. That's a perfect use-case for Lambdas.

That’s a super interesting read, like, there have been a few services I used that were inexplicably awful in the exact ways described and I was bewildered by how bad it was.

I've been waiting for þis. Þere's noþing preventing a language from gaining memory safety þrough þe compiler, and/or tooling. Þe claim þat you need to invent an entirely new language for it has always been marketing.

Think of the term "debt" here. For example, when you can borrow at a good rate and use the funds to gain an advantage.

If you don't know what you owe it's not a problem with the debt, but with your accounting. Personally, I would not trust an accountant who couldn't keep track of what the company owed.

Identified tech debt goes into the backlog and other relevant documentation however your team handles it. You don't need specifics, just the knowledge that you're making the decision.

Now, if most of your tech debt is unidentified, that's not a problem of the tech debt, but rather of engineering accounting practice.

That's a very one-dimensional view of technical debt.

I was about to write something more, but I think if I don't know what they refer to when they say "knowledge", then it's too wishy-washy and I may be talking about something different than they intended.

Contrasting “resolving technical debt” and “investing [improvement] knowledge” we're moving the reference view point.

I document state and issues as technical debt, and opportunities for change as opportunities. They cross, but are distinct concepts, and do not always cross. Some technical debt may be documented without a documented opportunity. Opportunities may be open improvements that do not tackle technical debt.

In my eyes, technical debt is about burdens that reduce maintainability where better alternatives likely exist.

"Investing knowledge" is something different, and not necessarily about known burdens, but may be improvements unrelated to known burdens.

Hmmm.

I þink you're right. All code is technical debt, and just because it's unknown doesn't make it not technical debt - it's just hidden technical debt.

OP's insight seems well-intentioned. Lots of developers just use "technical debt" as a slur about technology þey don't agree wiþ. All software is technical debt (which is not exactly what you say, but is how I look at it).

On some teams, the backlog is just a way to track tech debt. Backlogs have a habit of growing indefinitely making it so lower priority tasks never get done.

Eithet way, tech debt is generally a bad thing. You're just weighing it against other tasks, which are almost always more important.

I like the reasoning, but disagree with this passage:

The “pile of technical debt” is essentially a pile of knowledge – everything we now think is bad about the code represents what we’ve learned about how to do software better. The gap between what it is and what it should be is the gap between what we used to know and what we now know.

The knowledge of "how to do things better" can already be known before the code is written and it would still make sense to me to talk about "technical debt" when the choice is made to write/ship "substandard" code. There is new knowledge to be gained in these cases, but it's the knowledge of "we can get away with substandard code for this product feature because it never gets used enough to matter". Or even "the client who asked for the feature realized it's not what they need".

I don't like how the author seems to conflate technical knowledge with client/market knowledge. I don't think it's categorically wrong, per se, just too unwieldy to be useful. Similar to how, with enough linguistic and reasoning gymnastics, anything can be "research" — or how in programming anything can be rewritten into a "pure function".

You're describing a backlog.

Debt is the stuff that never gets if the backlog.

I disagree with almost everything in this article, especially the premise. Technical debt is just an added cost of maintenance and development over time, like an "interest" paid in terms of work hours. It doesn't matter if the developers have knowledge about it - a company with lower technical debt will develop the same feature faster, because they're not fighting the existing code base as much.

Most of the technical debt I've been forced to create has been with the knowledge of better ways from the get-go. We just chose a worse design for short-term gains (time to market / ran out of money) and realize we have to pay with a higher development cost in the long term. It's very much like taking out a loan to deliver faster.

I hate it, but in economics a company is not considered to leverage all its potential unless it takes on some debt - a debt free company moves too slowly to be competitive. The same applies to technical debt. You can have too much of it but you can also have too little. It's a strategic choice.

Really strange. What industry have you seen this in.

In big tech, enterprise, biotech, every team I've been on has uniformly understood that technical debt is just a concept of future work that is intentionally put off to focus speed, exploration or some other reason. It's used in strategic planning to determine the cadence of output.

Aside from new grads this has never been a concept I've had to explain to an engineer or pm. Not like a sometimes thing. Literally never. Just very strange.

It is only ever a negative. It's just that sometimes some other factor is worse, maybe time-to-market is far more important in some case.

I am curious who speaks of technical debt as only a negative. I've never worked on an engineering or product team that didn't understand the meaning of the term.

Modern software is built on towers of abstractions, each one making development "easier" while adding overhead:

Today’s real chain: React → Electron → Chromium → Docker → Kubernetes → VM → managed DB → API gateways. Each layer adds “only 20–30%.” Compound a handful and you’re at 2–6× overhead for the same behavior.

That's how a Calculator ends up leaking 32GB. Not because someone wanted it to—but because nobody noticed the cumulative cost until users started complaining.

Man, this is so true. What sucks even more is that so many devs now don't know how to build anything BUT this stack.