Seth Godin (https://seths.blog/) writes the most anodyne, uninspiring, uninspired middle manager and director level sound bites possible. You'd almost think an LLM does the writing for him, but he's been at it since long before LLMs hit the scene.
Sean Goedecke doesn't write in sound bytes like Godin does, but he writes about the same sort of topics with only slightly more insight, writing about topics that have entered the public awareness, but the public doesn't have a lot of experience with. Goedecke appears to be chasing clout with the same population Godin does, middle managers and up, using very carefully themed posts that never introduce new concepts or vocabulary. His posts are longer than Godin's, but they're not long enough to introduce and explain a new, or contrary concept related to the theme.
Please consider writing detailed critiques like this first time round instead of waiting for others to ask for clarification. I flagged your intial comment as "unkind" because it told me nothing other than you dislike two people, lacking any explanation why.
A lot of things are attributable to ZIRP but I don't think this is one of them. Just-say-no was also an era dominated by Ruby, Python, PHP, and to some extent JavaScript, all of which were entirely without any static typing guarantees.
So much of just-say-no had to do with how unbelievably fragile the underlying substrates of software engineering were at that time and about how nascent the field was. The iPhone came out in 2007 and ZIRP started in 2008.
Observability, SRE, and all manners of static analysis were far less common than they are today. We didn't have turnkey observability like DataDog/Honeycomb/whatever or turnkey a/b testing platforms like StatSig/LaunchDarkly back then: that stuff was all stuff we were building or managing ourselves. You want to see what the state of feature flagging was during ZIRP? It was this blog post on a self-hosted WordPress blog, because back then the easiest option for your engineering blog was self-hosted WordPress: https://code.flickr.net/2009/12/02/flipping-out/
Nowadays so much of what we worked on in the ZIRP days has since become commoditized by the ZIRP-era engineers. When was the last time you read an article about different strategies for manually sharding MySQL? When was the last time you read a breakdown of different observability systems where every option mentioned was something you hosted yourself?
Besides, the number of people on the internet and on modern sites is just larger now. 1 million users in 2010 was far less common than having 1 million users in 2026.
If your only concept of ZIRP was Covid, your whole lens on the situation is warped, because Covid made everything upside-down. Wow, your best numbers were during Covid, when everyone was trapped inside and could only use the computer? Wow no surprise!
They don’t fit well into every single tech company anymore, but there are domains where they’re needed. In Pure and impure software engineering I drew a distinction between “pure” engineering, which has a well-scoped, largely technical goal (like building a compiler or a language runtime) and “impure engineering”, which has a poorly-scoped, largely customer-driven goal (like trying out a new feature you’re not sure will work).
Sorry, but this is gross and should be roundly shamed. This language of "pure" and "impure" reeks and has massive historical baggage and has raised its head time and time again throughout history as the thing that separates from the population of "decent" people the population of people that should be dominated. It is tribalist language that has been used consistently throughout history to justify atrocities. You are not "pure" because you work on a compiler or "impure" because you work on user-facing features.
Sorry, but this is gross and should be roundly shamed. This language of "pure" and "impure" reeks and has massive historical baggage and has raised its head time and time again throughout history as the thing that separates from the population of "decent" people the population of people that should be dominated. It is tribalist language that has been used consistently throughout history to justify atrocities. You are not "pure" because you work on a compiler or "impure" because you work on user-facing features.
This observation is "gross", wildly misconstruing normal speech. The author never said anyone was "pure" or "impure", never tried to motivate "decent" people... but wrote a (linked) article saying less things are "pure engineering" now. "pure" and "applied" (e.g. science) might be better, but "applied engineering" sounds rather strange. This isn't just putting words into someone's mouth, but putting a whole moral terror into them. Do you react the same way to "pure functions" etc.?
it is not "putting words into someone's mouth" when you communicate how you interpret what someone has said. One is also not obligated to write "it is my opinion that" before they say "chocolate is delicious".
Do you react the same way to "pure functions" etc.?
that's also stupid terminology but it is more entrenched
Worse still, the AI tooling mostly works. It’s not (yet) causing any kind of catastrophe. The code isn’t quite as clean, and it’s a bit less well-understood, but it’s good enough
Eroded engineering doesn't immediately cause catastrophe. You don't notice it at first, but then when someone finally complains, you realize the program takes 10x longer to start, or something crashes, or it takes 2 days and 100 lines of change to add a button, and you find you've suffered ten thousand paper cuts.
Lots of people will ship with AI. Products tend to be accretion system, but every feature is also a constraint on other features. My belief is that AI-as-engineer will "eliminate" engineering pushback on projects, and we'll end up with heavily diluted, but bloated "do-everything" systems, in particular since there will be few (or no one) with in-depth understanding of the costs of features. This is hard to recover from not only from an engineering point of view, but also from the product side: once you give someone a feature, it's hard to take it back.
I am already seeing engineers adopt a "You want me to use this? Fine, I will but I won't care or be held responsible for the quality." Attitudes in engineers I work with. I don't see any forcing functions against that yet organizationally.
Enough people complained at Google that change quality was going down that they had to email around the standards for quality that everyone is still expected to follow. It's not something anyone is going to be fired over, but it is at least social pressure and something a reviewer can leave as their first comment.
Saying “with this transformative new technology, we’re able to deliver 10x the value with half the engineers” is a much stronger message, even though it doesn’t make much sense (if this is true, why not keep your engineers and deliver 20x the value?)
This always seemed so obvious to me and I'm glad he mentioned it, especially since he's pretty pro-AI in software development.
Perhaps not so important but the implied time line is off by a smidge.
Interest rates rose after covid because of the push-pull inflation.
Companies began layoffs honestly saying we over hired.
AI became a thing and companies continued the layoffs but added in AI-washing hoping to bump stock prices even more than the usual bump from “trimming the fat”
Saying “with this transformative new technology, we’re able to deliver 10x the value with half the engineers” is a much stronger message, even though it doesn’t make much sense (if this is true, why not keep your engineers and deliver 20x the value?)
Just to get the obvious out of the way, I agree that anyone selling you 10x productivity improvement is full of it. They're either making up the number because it's nice and round, or they're counting lines of code (not sure which is worse).
With that said, the logic here is pretty bad--for reasons the article already sort of touches on, you can't double your headcount and get double the value. If you're remotely competent, you're doing some prioritization. If you double headcount, the new people are working on less valuable things than the first half. On top of that, there's higher coordination costs.
The code isn’t quite as clean, and it’s a bit less well-understood, but it’s good enough (particularly in a world where companies are trying lots of new things and abandoning the ones that fail).
The thing is, the end of ZIRP also reduces the room for "trying lots of new things and abandoning the ones that fail". Obviously there are still startups, and companies still gamble on new things, but the bar for success is a lot higher when the cost of capital rises.
anyone selling you 10x productivity improvement is full of it
Productivity is given as the rational reason for spending on AI. However, there's a lot of previously easy gains you could get but were often not used: tech refreshes, paid developer tools, extra training, raises for retention to prevent inefficiencies from knowledge loss, retraining, and unfilled positions. Cost reduction seems to be the real target.
The "just say no" engineer stereotype existed for decades before ZIRP, in good markets and bad. This is because the "just say no" engineer was actually contributing to a core product management function: Prioritization.
You can only stuff so much random unrelated crap into your product before your users start to hate it. You can only try to add so many unrelated features to the code before it turns into a buggy mess with zero forward velocity. (Anyone who thinks AI fixes this is really not using AI. AI-written code decays several times faster than human-written code.) The job of the "just say no" engineer was to report these costs to product & project management, so that they could be properly applied during the prioritization process. Sometimes you overrule the "just say no" engineer, because a feature really is worth it.
Now, I don't actually have a good cost model for AI-written or AI-maintained code. I'm working very hard to build one. In the meantime, my advice is going to come with larger error bars for a while. Maybe you should vibe code that new idea! Maybe you shouldn't vibe code that other thing, not unless you have a sharp engineer who really understands it all.
But sure, you can absolutely sack all the engineers who warn you of impending disaster, and ask a Claude swarm to implement your 100+-item feature backlog. I will, uh, stand way over here. I have run ridiculous Claude swarms quite recently, and I have a pretty good idea what is going to happen to you. But I'm not your parent. You can do it if you want to. I'm quite happy to let the market sort it out.
What a take. I'm very biased because I was mostly a just-say-no engineer; but this wasn't to avoid change, it was a much simpler reason: many ideas are bad, and most people would rather say yes to avoid conflict.
When I joined my last company, my 'no' became (in)famous for a bit, company slowed down, but then magic happened: new features were designed with more thought, incident rates went way down, and then we started actually moving faster, because we didn't have to deal with daily breakage.
bediger4000 | 19 hours ago
This guy strikes me as just a teaspoon more profound than Seth Godin.
Gaelan | 7 hours ago
As someone not familiar with the work of Seth Godin, what are you implying here?
bediger4000 | 6 hours ago
Seth Godin (https://seths.blog/) writes the most anodyne, uninspiring, uninspired middle manager and director level sound bites possible. You'd almost think an LLM does the writing for him, but he's been at it since long before LLMs hit the scene.
Sean Goedecke doesn't write in sound bytes like Godin does, but he writes about the same sort of topics with only slightly more insight, writing about topics that have entered the public awareness, but the public doesn't have a lot of experience with. Goedecke appears to be chasing clout with the same population Godin does, middle managers and up, using very carefully themed posts that never introduce new concepts or vocabulary. His posts are longer than Godin's, but they're not long enough to introduce and explain a new, or contrary concept related to the theme.
tomhukins | 5 hours ago
Please consider writing detailed critiques like this first time round instead of waiting for others to ask for clarification. I flagged your intial comment as "unkind" because it told me nothing other than you dislike two people, lacking any explanation why.
Gaelan | 6 hours ago
Thanks!
scraps | 7 hours ago
A lot of things are attributable to ZIRP but I don't think this is one of them. Just-say-no was also an era dominated by Ruby, Python, PHP, and to some extent JavaScript, all of which were entirely without any static typing guarantees.
So much of just-say-no had to do with how unbelievably fragile the underlying substrates of software engineering were at that time and about how nascent the field was. The iPhone came out in 2007 and ZIRP started in 2008.
Observability, SRE, and all manners of static analysis were far less common than they are today. We didn't have turnkey observability like DataDog/Honeycomb/whatever or turnkey a/b testing platforms like StatSig/LaunchDarkly back then: that stuff was all stuff we were building or managing ourselves. You want to see what the state of feature flagging was during ZIRP? It was this blog post on a self-hosted WordPress blog, because back then the easiest option for your engineering blog was self-hosted WordPress: https://code.flickr.net/2009/12/02/flipping-out/
Nowadays so much of what we worked on in the ZIRP days has since become commoditized by the ZIRP-era engineers. When was the last time you read an article about different strategies for manually sharding MySQL? When was the last time you read a breakdown of different observability systems where every option mentioned was something you hosted yourself?
Besides, the number of people on the internet and on modern sites is just larger now. 1 million users in 2010 was far less common than having 1 million users in 2026.
If your only concept of ZIRP was Covid, your whole lens on the situation is warped, because Covid made everything upside-down. Wow, your best numbers were during Covid, when everyone was trapped inside and could only use the computer? Wow no surprise!
Sorry, but this is gross and should be roundly shamed. This language of "pure" and "impure" reeks and has massive historical baggage and has raised its head time and time again throughout history as the thing that separates from the population of "decent" people the population of people that should be dominated. It is tribalist language that has been used consistently throughout history to justify atrocities. You are not "pure" because you work on a compiler or "impure" because you work on user-facing features.
veqq | 2 hours ago
I dislike this article, but
This observation is "gross", wildly misconstruing normal speech. The author never said anyone was "pure" or "impure", never tried to motivate "decent" people... but wrote a (linked) article saying less things are "pure engineering" now. "pure" and "applied" (e.g. science) might be better, but "applied engineering" sounds rather strange. This isn't just putting words into someone's mouth, but putting a whole moral terror into them. Do you react the same way to "pure functions" etc.?
scraps | an hour ago
it is not "putting words into someone's mouth" when you communicate how you interpret what someone has said. One is also not obligated to write "it is my opinion that" before they say "chocolate is delicious".
that's also stupid terminology but it is more entrenched
pyj | 10 hours ago
Eroded engineering doesn't immediately cause catastrophe. You don't notice it at first, but then when someone finally complains, you realize the program takes 10x longer to start, or something crashes, or it takes 2 days and 100 lines of change to add a button, and you find you've suffered ten thousand paper cuts.
Lots of people will ship with AI. Products tend to be accretion system, but every feature is also a constraint on other features. My belief is that AI-as-engineer will "eliminate" engineering pushback on projects, and we'll end up with heavily diluted, but bloated "do-everything" systems, in particular since there will be few (or no one) with in-depth understanding of the costs of features. This is hard to recover from not only from an engineering point of view, but also from the product side: once you give someone a feature, it's hard to take it back.
zaphar | 9 hours ago
I am already seeing engineers adopt a "You want me to use this? Fine, I will but I won't care or be held responsible for the quality." Attitudes in engineers I work with. I don't see any forcing functions against that yet organizationally.
ClashTheBunny | 9 hours ago
Enough people complained at Google that change quality was going down that they had to email around the standards for quality that everyone is still expected to follow. It's not something anyone is going to be fired over, but it is at least social pressure and something a reviewer can leave as their first comment.
radio | 9 hours ago
Such a cumbersome logic.
It might be true, but these logic standards I bet we can find that anything was the cause of anything.
I wasn't even aware that this just-say-no thing was such a widespread phenomenon.
nickmonad | 6 hours ago
Yeah, I think the premise is overblown here.
Although, I did appreciate this:
This always seemed so obvious to me and I'm glad he mentioned it, especially since he's pretty pro-AI in software development.
kghose | 8 hours ago
Perhaps not so important but the implied time line is off by a smidge.
Interest rates rose after covid because of the push-pull inflation.
Companies began layoffs honestly saying we over hired.
AI became a thing and companies continued the layoffs but added in AI-washing hoping to bump stock prices even more than the usual bump from “trimming the fat”
hyperpape | 7 hours ago
Just to get the obvious out of the way, I agree that anyone selling you 10x productivity improvement is full of it. They're either making up the number because it's nice and round, or they're counting lines of code (not sure which is worse).
With that said, the logic here is pretty bad--for reasons the article already sort of touches on, you can't double your headcount and get double the value. If you're remotely competent, you're doing some prioritization. If you double headcount, the new people are working on less valuable things than the first half. On top of that, there's higher coordination costs.
The thing is, the end of ZIRP also reduces the room for "trying lots of new things and abandoning the ones that fail". Obviously there are still startups, and companies still gamble on new things, but the bar for success is a lot higher when the cost of capital rises.
pyj | 6 hours ago
Productivity is given as the rational reason for spending on AI. However, there's a lot of previously easy gains you could get but were often not used: tech refreshes, paid developer tools, extra training, raises for retention to prevent inefficiencies from knowledge loss, retraining, and unfilled positions. Cost reduction seems to be the real target.
emk | an hour ago
Yeah, this is a pretty vapid take.
The "just say no" engineer stereotype existed for decades before ZIRP, in good markets and bad. This is because the "just say no" engineer was actually contributing to a core product management function: Prioritization.
You can only stuff so much random unrelated crap into your product before your users start to hate it. You can only try to add so many unrelated features to the code before it turns into a buggy mess with zero forward velocity. (Anyone who thinks AI fixes this is really not using AI. AI-written code decays several times faster than human-written code.) The job of the "just say no" engineer was to report these costs to product & project management, so that they could be properly applied during the prioritization process. Sometimes you overrule the "just say no" engineer, because a feature really is worth it.
Now, I don't actually have a good cost model for AI-written or AI-maintained code. I'm working very hard to build one. In the meantime, my advice is going to come with larger error bars for a while. Maybe you should vibe code that new idea! Maybe you shouldn't vibe code that other thing, not unless you have a sharp engineer who really understands it all.
But sure, you can absolutely sack all the engineers who warn you of impending disaster, and ask a Claude swarm to implement your 100+-item feature backlog. I will, uh, stand way over here. I have run ridiculous Claude swarms quite recently, and I have a pretty good idea what is going to happen to you. But I'm not your parent. You can do it if you want to. I'm quite happy to let the market sort it out.
deivid | 6 hours ago
What a take. I'm very biased because I was mostly a just-say-no engineer; but this wasn't to avoid change, it was a much simpler reason: many ideas are bad, and most people would rather say yes to avoid conflict.
When I joined my last company, my 'no' became (in)famous for a bit, company slowed down, but then magic happened: new features were designed with more thought, incident rates went way down, and then we started actually moving faster, because we didn't have to deal with daily breakage.