> AI didn't take our jobs. Greed did. Same greed that moved factories to Bangladesh and keeps slaves in cobalt mines in the Congo, wearing a new mask. Tell the nephew to do something else. Anything. It won't save him either, but at least he won't have to pretend the thing destroying his life is a robot.
This hit me hard. This article is art. I think I need to sleep on this and read it again in the morning.
This was beautiful. I also appreciated the backlink to Peter Welch’s spiritual ancestor to this essay, which I had forgotten how to find, and had the joy of reading again.
> You knew. And you signed off anyway. Because the alternative was losing the job, and the job was the mortgage, and the school fees, and the visa, and the version of yourself who'd fix it later once things stabilized.
I felt the pang in my bones reading this. All of us peons are just wading through this brave new world trying to do what we know is right but ultimately having no choice but to give in to life's needs.
The USB stick hints at a big problem in our trade though: how do you "reboot" your IT infrastructure if it literally burns to the ground? I'm not talking about Google-scale systems (which still couldn't restart from scratch IIUC but they're actually working on it?) but only about SMEs.
How does a medium-sized SME were all the payrolls depends on Sara and her USB stick do if, literally, their servers do catch fire.
You've got backups, then what? How automated is the reinstallation of your typical SME's infra?
The closest I saw to that scenario was some documentary where some little trading firm had just time to fetch the backup hard drives before leaving the building on fire after a plane crashed into it on 9/11. The CEO (I think it was the CEO) was explaining that had he not grabbed a HDD with the backups, the company was done (not that I advice onsite/offline backups on HDDs that you must not forget to grab when the shit hits the fan as a solution btw).
I understand the "just drink the cloud kool-aid" angle: but are SMEs typically doing that?
How many SMEs out there are depending on Sara's knowledge of the USB memory stick and how to use it?
I've definitely seen similar things. And I'm sure many of you did too.
When I took charge of solving backups for the single important box with unique, irreplaceable data -- the accounting system -- at an SME a long time ago, I think I approached it with the right amount of correctness. Therein, losing a day or three of recent data would have been recoverable; losing all of it would have been catastrophic.
I devised a system to perform bare-metal backups onto an easily-swapped, external 2.5" hard drive, using Acronis. I provided a plurality of these hard drives, and they were to be rotated off-site. The system was tolerant of human error and would proceed with making valid, current backups even if the drives were rotated incorrectly, or if not rotated at all on any given day. The backup drives each had complete file history (yay shadow copies) so any given drive could be used as a time machine of varying resolution, and as the single source from which to independently start fresh.
I'd watch the logs to see that it was done, and for the most part: Whoever was assigned to that role normally did it properly-enough.
I documented it and showed the other technical folks how it works.
Sometimes I'd wander back and make sure the backup drives weren't accumulating on-site (there should never be more than 2 on-site). I'd periodically test these backups by restoring them completely onto identical hardware, to make sure the system hadn't got crufted up somehow and that it still continued to perform its task of restoring a working system from zero.
It worked fine for years and years.
Eventually, my role changed and those things rather officially became Not My Problem.
Later, they moved the accounting system from that lineage of stout Proliant boxes to a trash-tier small-form 1u Lenovo machine that someone found used, on eBay, for cheap.
Backups are handled by the clown, somehow. The last I heard anything about it, the person doing the talking was very pleased with the money they'd saved and that they'd no longer have to pay "extortion" to Acronis.
I have every expectation that nobody has ever restored these backups. They're probably relying on the sheer hope that they'll never have to recover them, much less from zero.
And I also hope they never have to restore them, lest they may find out exactly what that data is worth to them.
> How does a medium-sized SME were all the payrolls depends on Sara and her USB stick do if, literally, their servers do catch fire.
Like every job, we overestimate our importance.
What do they do? They pay everyone the same as last month as a temporary measure, ask you to talk to your manager if your pay should be more this month, warn everyone that they're going to recalculate the payroll and adjust any differences next month. Then they calculate everyone's pay from the inputs, which really isn't such a hard problem when the alternative is failure. Maybe they pay some fancy consultants or an SAAS provider for a few months. Maybe they have to cut a few corners. Maybe they even get fined by their state's DoL. Life goes on.
> How many SMEs out there are depending on Sara's knowledge of the USB memory stick and how to use it?
I think at least in part, that is the point: orgs are missing the part of the equation where the institutional and organizational knowledge is critical. Sure, the code to accomplish parts B and C can be re-duct-taped together in a month or so by off-shore, or maybe an agent... but part A, its plumbing, and why it does what it does the way it does it due to historical failures and the knowledge behind that is probably what keeps it going.
Those things are learned starting at the ground level by bumping into them in the trenches.
The company just shuts down and its customers switch to competitors. This is economically efficient. The redundancy of a company is another company. It's a bit like how we don't insist on every server running two CPUs in lockstep in case one fails, because we have more than one server to handle requests.
>The USB stick hints at a big problem in our trade though: how do you "reboot" your IT infrastructure if it literally burns to the ground? I'm not talking about Google-scale systems (which still couldn't restart from scratch IIUC but they're actually working on it?) but only about SMEs.
Maersk ground to a halt because it got done nearly 100% by cryptolocker. IIRC they went to hard copy records, called everyone, got all of IT together with some company credit cards to get new laptops and flash drives and shit and literally rebuilt their infra from scratch.
I read a better post mortem but thats the highlights.
>How many SMEs out there are depending on Sara's knowledge of the USB memory stick and how to use it?
Part of my day job is finding, documenting and remediating these sort of issues.
"The CEO Coded this application in VB5 15 years ago, the entire business relies on it, theres no source code, theres no binary backups and the one computer it runs on just had its PSU fail"
"Theres a cron somewhere that compresses, zips and transports the payroll database interstate, outside of our network, before our weekly pay run"
"Theres been no documentation of this environment for 20 years, most of the hardware is that old, and the team that developed it just sold all their shares and left"
This shit is my life lmao.
Theres obviously some bias, because the good companies aren't asking me to do it for them. But I make a decent living examining, documenting and remediating this shit.
I think one thing that has changed permanently is coding by hand has become unnecessary. Programmers had edge over others because they knew the spec and syntax. Now that field has been leveled.
You still need to know the syntax but not the nitty gritty details and you don't need to be able to code a java's lambda's anonymous override or streams anymore. Just knowing it "somewhat" is enough.
But that's all that has changed.
What has not changed is the requirement for "systems" thinking and the general good practices. In fact, that has become even more important because earlier we were forced to think in existing patterns (editing pre-existing code), but now with coding agents, it can very easily duplicate the logic in its own module and call it a day.
So we need to be the forcing function here with our systems thinking and guardrails.
Let me add to the chorus of admiration for this piece of writing. Poignant, accurate, appropriately cynical.
> AI didn't take our jobs. Greed did. Same greed that moved factories to Bangladesh and keeps slaves in cobalt mines in the Congo, wearing a new mask. Tell the nephew to do something else. Anything. It won't save him either, but at least he won't have to pretend the thing destroying his life is a robot.
This hit me hard. This article is art. I think I need to sleep on this and read it again in the morning.
This was beautiful. I also appreciated the backlink to Peter Welch’s spiritual ancestor to this essay, which I had forgotten how to find, and had the joy of reading again.
Archive link as the site seems down - https://web.archive.org/web/20260507003341/https://www.stvn....
Lovely writing!
> ... to which they nod before moving on to a lighter topic, like whether we're going to nuke Iran or not.
> There are no more juniors. There was a funeral for their passing in 2024. Nobody came.
> AI didn't take our jobs. Greed did.
Love the sarcasm, it carries a cynical form of experience :)
Yes. And the reason for all of this is the same as it's always been, and requires literally no technical knowledge to understand.
There is essentially zero accountability for harm.
There is no button on your toaster that blows up the toaster.
But there's a link in your email. And that's a button.
And no one has figured out how to punish Microsoft or Apple or Google for allowing that to continue, though we do this just fine elsewhere.
Someone or something has to be punished, regulated or otherwise hurt for anything to change here.
I was expecting another AI rant. I got really great writing instead. This escalated quickly.
This is absurdly well written.
I don’t know how someone takes the familiar anxiety around AI replacing developers and turns it into something this beautiful and funny.
Once again, the programming industry has robbed literature of a potential Nobel Prize candidate.
> You knew. And you signed off anyway. Because the alternative was losing the job, and the job was the mortgage, and the school fees, and the visa, and the version of yourself who'd fix it later once things stabilized.
I felt the pang in my bones reading this. All of us peons are just wading through this brave new world trying to do what we know is right but ultimately having no choice but to give in to life's needs.
> anxiety around AI replacing developers
For the benefit of people who don't absorb the entire article (spoiler alert):
>> … AI didn't take our jobs. Greed did. …
As another commenter implied, the title a reference to this - https://www.stilldrinking.org/programming-sucks. Which is an incredible read as well
The USB stick hints at a big problem in our trade though: how do you "reboot" your IT infrastructure if it literally burns to the ground? I'm not talking about Google-scale systems (which still couldn't restart from scratch IIUC but they're actually working on it?) but only about SMEs.
How does a medium-sized SME were all the payrolls depends on Sara and her USB stick do if, literally, their servers do catch fire.
You've got backups, then what? How automated is the reinstallation of your typical SME's infra?
The closest I saw to that scenario was some documentary where some little trading firm had just time to fetch the backup hard drives before leaving the building on fire after a plane crashed into it on 9/11. The CEO (I think it was the CEO) was explaining that had he not grabbed a HDD with the backups, the company was done (not that I advice onsite/offline backups on HDDs that you must not forget to grab when the shit hits the fan as a solution btw).
I understand the "just drink the cloud kool-aid" angle: but are SMEs typically doing that?
How many SMEs out there are depending on Sara's knowledge of the USB memory stick and how to use it?
I've definitely seen similar things. And I'm sure many of you did too.
Many houses of cards?
When I took charge of solving backups for the single important box with unique, irreplaceable data -- the accounting system -- at an SME a long time ago, I think I approached it with the right amount of correctness. Therein, losing a day or three of recent data would have been recoverable; losing all of it would have been catastrophic.
I devised a system to perform bare-metal backups onto an easily-swapped, external 2.5" hard drive, using Acronis. I provided a plurality of these hard drives, and they were to be rotated off-site. The system was tolerant of human error and would proceed with making valid, current backups even if the drives were rotated incorrectly, or if not rotated at all on any given day. The backup drives each had complete file history (yay shadow copies) so any given drive could be used as a time machine of varying resolution, and as the single source from which to independently start fresh.
I'd watch the logs to see that it was done, and for the most part: Whoever was assigned to that role normally did it properly-enough.
I documented it and showed the other technical folks how it works.
Sometimes I'd wander back and make sure the backup drives weren't accumulating on-site (there should never be more than 2 on-site). I'd periodically test these backups by restoring them completely onto identical hardware, to make sure the system hadn't got crufted up somehow and that it still continued to perform its task of restoring a working system from zero.
It worked fine for years and years.
Eventually, my role changed and those things rather officially became Not My Problem.
Later, they moved the accounting system from that lineage of stout Proliant boxes to a trash-tier small-form 1u Lenovo machine that someone found used, on eBay, for cheap.
Backups are handled by the clown, somehow. The last I heard anything about it, the person doing the talking was very pleased with the money they'd saved and that they'd no longer have to pay "extortion" to Acronis.
I have every expectation that nobody has ever restored these backups. They're probably relying on the sheer hope that they'll never have to recover them, much less from zero.
And I also hope they never have to restore them, lest they may find out exactly what that data is worth to them.
> How does a medium-sized SME were all the payrolls depends on Sara and her USB stick do if, literally, their servers do catch fire.
Like every job, we overestimate our importance.
What do they do? They pay everyone the same as last month as a temporary measure, ask you to talk to your manager if your pay should be more this month, warn everyone that they're going to recalculate the payroll and adjust any differences next month. Then they calculate everyone's pay from the inputs, which really isn't such a hard problem when the alternative is failure. Maybe they pay some fancy consultants or an SAAS provider for a few months. Maybe they have to cut a few corners. Maybe they even get fined by their state's DoL. Life goes on.
> How many SMEs out there are depending on Sara's knowledge of the USB memory stick and how to use it?
I think at least in part, that is the point: orgs are missing the part of the equation where the institutional and organizational knowledge is critical. Sure, the code to accomplish parts B and C can be re-duct-taped together in a month or so by off-shore, or maybe an agent... but part A, its plumbing, and why it does what it does the way it does it due to historical failures and the knowledge behind that is probably what keeps it going.
Those things are learned starting at the ground level by bumping into them in the trenches.
The company just shuts down and its customers switch to competitors. This is economically efficient. The redundancy of a company is another company. It's a bit like how we don't insist on every server running two CPUs in lockstep in case one fails, because we have more than one server to handle requests.
>The USB stick hints at a big problem in our trade though: how do you "reboot" your IT infrastructure if it literally burns to the ground? I'm not talking about Google-scale systems (which still couldn't restart from scratch IIUC but they're actually working on it?) but only about SMEs.
Maersk ground to a halt because it got done nearly 100% by cryptolocker. IIRC they went to hard copy records, called everyone, got all of IT together with some company credit cards to get new laptops and flash drives and shit and literally rebuilt their infra from scratch.
https://www.itnews.com.au/news/maersk-had-to-reinstall-all-i...
I read a better post mortem but thats the highlights.
>How many SMEs out there are depending on Sara's knowledge of the USB memory stick and how to use it?
Part of my day job is finding, documenting and remediating these sort of issues.
"The CEO Coded this application in VB5 15 years ago, the entire business relies on it, theres no source code, theres no binary backups and the one computer it runs on just had its PSU fail"
"Theres a cron somewhere that compresses, zips and transports the payroll database interstate, outside of our network, before our weekly pay run"
"Theres been no documentation of this environment for 20 years, most of the hardware is that old, and the team that developed it just sold all their shares and left"
This shit is my life lmao.
Theres obviously some bias, because the good companies aren't asking me to do it for them. But I make a decent living examining, documenting and remediating this shit.
> How does a medium-sized SME were all the payrolls depends on Sara and her USB stick do if, literally, their servers do catch fire.
The SpecOps guys have the following bit of wisdom on offer: "Two is one and one is none".
And a backup you haven't verified you can restore from isn't one.
Good read.
I think one thing that has changed permanently is coding by hand has become unnecessary. Programmers had edge over others because they knew the spec and syntax. Now that field has been leveled.
You still need to know the syntax but not the nitty gritty details and you don't need to be able to code a java's lambda's anonymous override or streams anymore. Just knowing it "somewhat" is enough.
But that's all that has changed.
What has not changed is the requirement for "systems" thinking and the general good practices. In fact, that has become even more important because earlier we were forced to think in existing patterns (editing pre-existing code), but now with coding agents, it can very easily duplicate the logic in its own module and call it a day.
So we need to be the forcing function here with our systems thinking and guardrails.
I hope to never work with you.
No offense.