Code is a liability. Saying no is because the engineer wants to reduce complexity, not because she/ he is so subjectively “obsessed” with code quality. The term “quality” is nowadays misunderstood by management. It means the right amount of effort to build the product as fast and for as low as cost possible, taking into account a team of engineers that can easily add and modify code.
"quality" isn't succinctly definable. Zen and the art of system maintenance quality code is written by an old and wise programmer and any attempt to rigidly codify what it is they did and why is doomed to fail.
p.s. We've had to ask you this before: https://news.ycombinator.com/item?id=47103856. If you'd please review the guidelines and take the intended spirit of the site to heart, we'd be grateful.
Also what's wrong with "code is a liability"? That's just 100 % true. The idea isn't exactly novel or revealing, but it's also really fundamental. Every line of code is a liability from day one.
The comment you replied to used that as a reminder and as an opening to an actual argument, it wasn't just a knee-jerk reaction.
Production code is an asset, its maintenance and obligations are an expense, its risks might become liabilities, and companies shouldn't run more code than they need for the same reason they shouldn't own a larger vehicle fleet or more spare warehouse capacity than they need.
I don't think most engineers really disagree with this. Saying code is a liability is technically incorrect but pithy shorthand to communicate that it comes with the associated baggage of maintenance, obligation, and risk; these things suck up money the same way a liability does. Tech debt is also not real debt. It's a figure of speech.
A building is an immovable asset. It’s also made of things that wear and tear. Its value is derived from its capability to house and the capability to house something extends beyond four walls and a roof.
The asset has inherent liabilities. A codebase can be reasoned about extremely similarly
Note how the longer sentences are significantly stricter than the shorter ones. You could maybe add another condition, in the sense that the code has to generate more revenue than it costs to maintain. Then I'd start to agree.
Also note that even when a line of code is generating revenue, it never stops being a liability in almost every sense of the word. Testing it still costs money and time, understanding it costs cognitive power, having it in the context of your LLM coding agent costs tokens, and that's assuming it's a good line of code. If it's bad code (badly named, badly placed, a logic chain that works but has hidden flaws), the costs increase and reverberate throughout the codebase (and your AI coding sessions).
That's an oversimplification. Asset vs liability isn't a binary state but a superposition. An asset can carry liabilities.
Your asset might generate $10k a month in revenue, but at the same time may have a high chance of needing a $100k investment in upgrades and repairs to remain productive.
Nah man. You got to say "no" a lot. Even in the age of AI. Often times features downright make no sense, the time to implement can span weeks and it would actively damage the product in the long term. I work in a ecom startup and I got to say no so many times due to added complexity for little reward.
I think saying no is more important now with AI, as features can be built so quickly now. But there are a lot more costs after the feature has been built. Mostly with AI the code isn’t understood that well, wich incurs a cognitive debt. Then there are extra maintentance and documentation costs. And the costs of carrying around features that add no value.
I can imagine that if you’re a startup and want to try new features quickly, it makes sense to say yes more. But the senior mentioned in the article will also be able to understand that.
The problem with this kind of armchair economy is that you can argue both ways.
"End of ZIRP and the raise of just-say-no engineers": with capital being more expensive companies need to invest it wisely, therefore the need the judgement of the just-say-no engineer to avoid blowing it on unnecessary stuff.
I would add: Either you are an engineer that management trusts and whose judgement they value, or you aren’t. If you aren’t, you’re in a bad position anyway.
There's a good article about it. Saying no is a budget. In other words you don't have enough veto power to stop all bad projects so you need to be strategic about spending this budget.
It's on stories like these where I honestly just love the HN community and the comment threads.
I was reading the article, and as it went on I increasingly thought "This is one of those articles that sounds like it's saying something insightful ('it has all the right lingo! ZIRP era! Just-say-no engineers!'), but then when you dig deeper, it doesn't resonate with my experience at all when I was knee deep in software engineering in those years, nor do I feel that it in any way accurately diagnoses the immense changes that are currently happening with AI." In other words, it sounds like buzzword bullshit to me, and in the absence of a downvote button on stories, I'm glad the community is calling it out.
Higher interest rates indicate higher urgency, meaning short term investments with fast payoffs. Throw in LLMs that play into that urgency and you get a mass production of AI slop. It doesn't matter if the AI project is a failure, since it failed fast enough to go and do something else. Doing the right thing from the get go is something that only matters for long term projects with significant initial investment.
> Having half of the company’s engineers enmeshed in an endless loop of proposing changes and being told no was totally fine - they didn’t need to be productive anyway, and this way they weren’t impacting business-critical systems.
There are many stories of FAANG hiring during that era for the purpose of denying talent to competitors. But now that you hired them, what will they do? And how will you keep them from creating problems?
It sounds cynical in retrospect; at the time the same set of facts were explained differently, in a way that didn’t hurt people feelings.
At the FAANG I was at, we were pushed to interview interview interview, and the company tripled in size in two years.
We constantly questioned the motive for more engineers, when we had plenty already, constantly seeking alignment. The rationale was more engineers meant we could make more products more quickly.
It never worked, and caused huge headaches that never really went away. It didn't help that team size was made a specific goal of a number of VPs. So it because a goal to grow team size, rather than a business need
And because the VPs were doing it, a whole bunch of people down the hill started copying then, using team size as a forcing function for power.
That's a bit silly. Presumably you wanted to deny competitors use of these engineers, because they would build something useful. Just have them build that stuff for you instead?
And if competitors were in the same boat, why bother hiring these people at all?
It's about denial of labour leading to denial of broader competition, rather than a true intent to build a competing product.
If you were actually to follow through with building the product you would need a lot more than just engineers to roll out a successful product, effectively an entire company is needed, which would spread the company focus out and the lead to investor questions about your focus and commitment. Then if it's an unproven idea there's significant risk in going to market etc etc.
Cheaper to just lock up the talent and burn the wages. Bit of a ding to your books, big ding to your competitor's capability.
In saying that, it's a terrible practice. Massive waste of time, opportunity, talent and money.
>And if competitors were in the same boat, why bother hiring these people at all?
Suppose an established org (N) got disrupted by a startup (N+1) because the startup was able to do things faster and cheaper. Once the startup becomes the established org themselves and slows down a bit, they are exposed to the same risk, unless they hire all the smart people (who would otherwise be hired by N+2 startup) and buy out all the N+2 companies who actually managed to do something despite having less money. Eventually it becomes too expensive and there is a good excuse to fire all those people. I don't think it's 100% of what is happening, but it could be.
As someone else said, much about the post is simply not testable.
Is someone at Facebook working on the Metaverse a crucial part of prototyping new business models, or are they doing busywork? It'll only be clear in hindsight.
> think of this as the just-say-no engineer, as opposed to the just-say-yes engineer. The just-say-yes engineer is obsessed with moving fast, approves code changes by default, values MTTR over MTBF, and tends to ship a lot of code. The just-say-no engineer is obsessed with quality, is happy to move slowly, and blocks code changes by default.
Love the concept of the 'just-say-yes' engineer vs 'just-say-no' engineer (and corresponding prioritisation of MTTR over MTBF).
I'm definitely a 'just-say-yes' with the caveat that bad architectural choices can be super painful to fix later, and features become a lot harder to fix when they have users as opposed to before launch (so I'm a little bit 'just-say-no', or at least 'just-think-for-a-bit-first').
I also think the balance between 'just-say-yes' and 'just-say-no' really depends a lot on the project. If it's finance or healthcare, perhaps 'no' by default is best. But if it's a silly startup idea, YOLO.
A "just say yes" attitude leads to certain disaster then because the time to fix the product never comes. Demanding the time to clean up is equivalent to saying no. Whoever is in charge of development needs to have the power to do that and actually use it (if they don't ever use it, they effectively don't have it).
> A "just say yes" attitude leads to certain disaster
Disaster's a possibility. But if an idea has a 1% chance of success, "just say no" usually assures failure, whereas "just say yes" is a shot at that 1% chance.
Don’t be an engineer who says “no” with zero alternative solutions. That’s not being a good engineer, it’s being lazy and trying to look good. Often times an engineer will put forth a solution that’s non-ideal due to legacy reasons, but required nonetheless. And no they can’t rewrite the entire system to “do it the right way”. You're not being some super high IQ genius by saying “no” or pointing out the solution is non-ideal.
I remember this exact software dev manager. She knew the system well. She became a manager. She started saying no to many PMs and other devs. In meetings with business people, she was a bully because she knew how to code. The worst was that she offered no alternative when she didn’t agree with the proposal. She was difficult to work with.
I wonder if she is the same ZIRP person this article is talking about.
What a wild take. The straightforward takeaway from the end of ZIRP and the resulting increase in focus would be that you need to say no to more things, not fewer? You have to really contort yourself to argue that actually ZIRP gave rise to an entire class of make-work which then gave rise to a class of folks to keep said make-work under control.
The relevant era wasn't even a good example of (near) zero interest rates. At least when control for inflation. And there are other eras that also had low or even negative real interest rates.
> having more engineers around was beneficial to the stock price ... When banks hiked interest rates ... It was just no longer profitable to keep a bloated engineering staff around to boost the stock price.
Erm, what's known of the mechanism coupling software engineer head count and stock price? Or is it just an empirically observed phenomena?
> … why not keep your engineers and deliver 20x the value?
Probably because there isn’t actually an increase in demand for the capabilities of software, and engineers, product managers, and UI/UX designers are justifying the existence of their jobs by complicating software more than necessary.
Anyway, the essence of the article is that a “just say no” engineer is a person who knows how to use and enforce constraints so that complex systems remain manageable in the long-term; and that companies perceive such engineers to be irrelevant as AI coding tools become more mainstream.
I think that that has definitely happened, even with my own employer, but I think that companies of the same mindset just don’t have strong engineering cultures to begin with, and will be natural selected into oblivion during this wave of disruption, which already coincides with a prolonged period of economic uncertainty to begin with.
AI tools are great, but they are only as good as your people’s discernment. If you’re making AI adoption a KPI in your company, you’ve already lost sight of what your business is really about, and you’ll be bankrupt by your token spending before you can beat your competition.
Doesnt seem very testable of a hypothesis. As a company thats trying to get things done, doesnt it make sense to have someone help you prioritize by telling you when some decisions have long term costs?
There’s this trend that tries to sell the idea that, if LLMs and agents have any shortcomings, instead of them getting better we should lower the standards. Focus on the “MTTR”. Is the code bad? Don’t read it. Don’t review it. Remove the bottleneck (the human in the loop). This narrative is all over the place.
This tech is quite useful, and I wish we focused on how to work with the tool better and improved our processes around it instead of treating the symptoms.
Aren't people working on both? I'm sure the AI labs are working on their end of it. People are building better agents. You can work on skills or tweaking your AGENTS.md.
There no end to what you can do, but the question is how much time you devote to that versus your actual project.
The "Just Say No" engineer is a person who knows what existing tools can do, while more junior people don't know what their tools can do. So junior people are constantly proposing new types of yak shaving (new architecture, new storage backend, new framework, etc) that must be done before solving the problem at hand. This is all wasted resources and time, even if LLMs let you shave yaks faster. A good JSNE focuses your resources on solving problems straight away, not pouring them all into a bottomless pit of busy work.
One aspect that still bothers me is that you claim the just-say-no-engineer "was a critical role during ZIRP." I might be in the minority here, but I don't hold that same stance. I wonder if I am alone in that?
I think the "just say no" engineers were massively sidelined during ZIRP
Actually I suspect they are just massively sidelined in software in general because of how few regulations exist
The "just say no" engineer is someone who thrives in regulated environments, because (enforced) regulations are the only things that actually slow down the growth at all costs minded PMs in the world. And even then only sometimes
I think that's it. LLMs infected companies with the Rage Virus and now they're running mindlessly at anything that moves. A "just say no" engineer has no air in such an environment. It is FOMO of the most diffuse kind, with absolutely nobody knowing what the what is we're missing, but everybody (and that includes myself) knows something is going to change.
We like to dress up in suits, but we're all apes afraid of shapes in the clouds.
> It used to be that they only had to say no to more junior engineers’ handwritten PRs, but now they have to say no to a barrage of AI-generated code, some of it generated by managers and VPs who are politically difficult to say no to.
Holy cow. I worked at a big tech firm but left the industry prior to the emergence of InstructGPT et al., so I haven't experienced LLM code generation from the inside. Is this really happening -- upper managers and VPs proposing code changes they generated with LLMs? I don't think I'd survive.
Yes, this is happening. A friend of mine was telling me about a 25k LoC PR that was submitted by a product manager that he had to content with. And the politics are real - you can't just be like "no", but it's pretty tough to meaningfully review a 25k line PR, let alone from someone who knows fuck all about what they're doing and can't answer questions you might have.
I skimmed that PR briefly and it appears a) not to be slop and b) to be very reviewable as its structured as a series of small commits that each make one small change. This is far from the sort of management PR I'd fear.
There's no reason for engineers to be under more pressure to accept technical debt (which is what we're really talking about with the yes-or-no framing) after the end of ZIRP. Quite the opposite: right now debt is expensive and programmers are cheap, it's a good time to have high quality standards and build robust infrastructure that will position you to catch the next growth wave. It really is AI (or rather AI hype) making the difference.
the difference IMO is that now businesses have to find a product-market-fit faster. you can't spend 5 years building the perfect system. you get to spend 1 year building a system somebody will pay to use.
>Quite the opposite: right now debt is expensive and programmers are cheap, it's a good time to have high quality standards and build robust infrastructure that will position you to catch the next growth wave.
Uhm, no? You got it exactly backwards. Tech debt isn't the same as interest payments, tech debt is a future productivity decline, whereas interest payments require you to pay more than the initial money you borrowed.
If debt is expensive, then your goal is to pay it off quickly, since debt scales with the remaining principal and grows with interest. This means that you want to cut corners everywhere and incur tech debt. You do not want a long term investment in high quality standards and build robust infrastructure. Doing that will delay the payoff day. Each early payments reduce the principal, which reduces future interest payments.
In other words, it's a terrible time to have high quality standards and build robust infrastructure. There also won't be a "next growth wave", because the growth wave is now. You're about to miss it if you invest in the long term.
You pay tech debt with compounding interest at exorbitant rates.
Another way to look at it is to say that like any analogy applied to software development it is weak. It is not like normal debt at all because you must start paying back immediately one way or another. So you can't just pile hack on hack and wait for a year to pay back. You will start having to pay back for the hacks within a couple of months because of the bugs you have to fix and how hard it is to work with the messy codebase. In some cases you may even grind to a halt before you get anything substantial out to the customer. This doesn't mean that you should never hack stuff in. But in general it's cheaper to pay off the debt quickly instead of paying for the debt.
Ah indeed. As monetary debt becomes more expensive it makes tech debt relatively cheaper - fixing your code in the future is cheaper than fixing it now.
I've seen the "just say no" thing institutionalized through SRE, where they can use the "banhammer" to stop the deployment of new features or whatever hasn't passed their various "reliability checklists" and such (if they're responsible for on-call)
I'm sure this won't be popular but a lot of "SRE" teams were definitely ZIRP phenomenon, heh.
as someone on the other side who has had to deal with deploys that go from 5PM to 2AM due to bad code changes, and being on call with 40+ pages a day, there's a reason why SREs are just say no when they're the first responders to outages caused by poorly implemented features. I'm not saying just say no is the right mentality but I can see why many develop the cynical anti-change mentality
It's a classic case of power vs responsibility. Generally SREs get all the responsibility but little power. Even if developers are also suffering on-call shifts, the first strike always hits SREs.
I agree with the author that engineers need to recalibrate and say yes more often but the zirp connection is a stretch and unnecessary.
Good engineers will say yes and no thoughtfully and will adjust to the new reality anyway. So it feels kind of pointless since no one is really a just say yes or just say no person, though it is well written.
> 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?)
in some orgs it was a good excuse to cut the underperformers. these folks wouldnt deliver 10x value with AI, they would either deliver 0x or -10x (with contributions that the just say no engineer would have normally said no to)
What else will we blame interest rates for? I believe we're applying it as an explanation for far too many things. It is but one factor of many changing the mechanics of tech since ~2020: AI coding; big tech capex spending on AI; pandemic over-hiring hangover (mostly done); slowing growth of digital ad spending; TCJA section 174 (partly repealled, but still a thing).
> 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?)
I guess not every service or product needs 20x the value. That depends on the market segment, market maturity, and actual demand.
Who is their right minds would be wedded to an identity of saying "No"? Code quality puritans are annoying but if they do their job right they actually speed-up the development process because they don't let technical debt accumulate. Ultimately saying "No" is protecting your codebase. In the era of LLMs, saying "No" is much easier because you don't have to worry about the author feeling bad.
The whole zero-interest rate narrative I see used in a variety of context is a bit silly. Real interest rates were seldom close to zero. During much of that time they were negative, for example. And during many other times, when we had rather high positive nominal rates, real rates were closer to zero (because of inflation), and the author doesn't say anything weird happened then.
I agree with this take for experienced and capable engineering teams. Three times over the last three years, I have told my senior engineers to skip code review, and nothing catastrophic happened, and recovery from bugs was rapid. Three times I have been told by engineering management to reimplement code review. Now that management is either gone or about to be gone.
It is a bit frustrating when you want to do risk based approach but then it is much more work to explain it to people who don’t know better but they want a checkbox or read on the internet “that’s proper way of doing things”.
Another example is password complexity rules, we try to use latest recommendations with no forcing of PW change, no requirements beside length - but then there will be customer that will make fuss that we don’t have it as as it is compliance check box to have complex PW.
Skipping code reviews and the bugs it causes can be a problem, or it can be easily solvable later when the bugs are found. It varies a lot.
Skipping code reviews and the poor code that can happen because nobody took a second look - that's more of a problem. Because 6-12 months down the line, there's not a few bugs that need to be fixed. Instead, there's a horrible code base that causes all _future_ development to be a lot slower.
New CEO walks into the office for the first day. Looks at the budget to see what they can do to "Make a mark"
[Budget proposal officer]: "Here is the new cleaning budget"
[CEO]: "looks around the office, the office is clean, why do we need cleaners? much less expensive cleaners"
[Budget proposal officer]: "The cleaners keep the office clean though"
[CEO]: "Nonsense! I read a substack about this, lets get rid of the cleaners"
//Six months later in an ALL hands//
[CEO]: "Look I know that we have had issues, The washing facilities were sub standard, and in some cases people were poisoned by poor hygene. We have insistuted a new mandatory training called `keeping the office clean, you're the first link in the chain` to help keep everyone happy and healthy"
Sorry: is there any evidence for the proposition that staffing was excessive, or that it was ZIRP that led to excessive staffing? The idea is plausible, but was it actual?
Second, is there any evidence for more or less gatekeeping?
Or evidence that there were relatively more "pure-engineering" projects? (Though one would expect that for the new technologies and markets. The green fields migrated from scale to data science and AI.)
Finally, wouldn't more gatekeeping be required when AI reduces the cost of making concrete tech proposals?
This seems not connected to facts or compelling in theory, but it does touch on anecdotal and emotional truths. I believe the writer could do better. (More, I believe HN readers should insist on writers doing better, to raise quality and offer harder challenges to people.)
Apparently ZIRP was the era of abundance and of codebases growing rapidly and:
> with so many engineers running wild, how would they keep their systems from becoming completely unmanageable? Enter the just-say-no engineer.
So before "AI", the just-say-no engineer was a vital part of the system who was preventing it from getting overrun by (human-generated) slop. Good.
If ZIRP had not ended (but with AI):
> this would be a glorious moment for the just-say-no engineers. LLMs would have thrown fuel on the “engineers running wild” problem that the just-say-no engineers were empowered to solve. Tech companies, unable to publicly or privately cast doubt on AI-assisted coding, would have relied heavily on these engineers to prevent the tsunami of AI code from swamping the entire company.
Again, the just-say-no engineered would have been a vital part of the system shielding it from the influx of slop. And apparently this scenario isn't what's happening, because ZIRP had ended. Okay, what next?
> LLMs are adding insult to injury for the just-say-no engineer. They’re forced to watch while other engineers merge AI-generated PRs that would previously have been blocked, and are told to use the tools themselves
So even though ZIRP had ended and we've avoided the slopocalypse, the teams (now reduced by layoffs but augmented with AI) are still adding slop, even the traditional gatekeepers (just-say-nos) are now being actively forced to add slop and suddenly, none of that is a problem?
The hypothesis that companies today need to really focus so they can make money ignores the fact that, in fact, most or the major AI companies are not making money relative to their costs.
I disagree with the analysis, although I liked the opening paragraph. Why separate the economics of interest rates from the economics of AI productivity?
This is perhaps a very American-centric article? I realise that ZIRP was near-global, but "When banks hiked interest rates, almost every tech company immediately laid off 5-20% of their engineers." does not track with my or my friends' experiences.
And, fundamentally, in countries with employee rights, as an employee I do not give two shits about interest rates the company I work at borrows on. My philosophy on software design does not change. You can argue that the company might pick and choose who it makes redundant, and they might value people who produce "more product", but companies have always valued that visibility. It's your responsibility, if you care, to sell your actions in a commercial context. I don't think ZIRP changes that, and I have not personally noticed a change there.
But, I would gently point out that people are actively looking to move away from github because its unreliably
People hate shit when its not working, we are in a bubble where people allow AI products to have shit outcomes, because they either sound human, or do amazing things most of the time (generate that image, sort out that spreadsheet, generate that code or answer that question)
Because, ironically, there is lots of money about to subsidise anything with an AI sheen (how very ZIRP) people are making all sorts of shit with it. Some times it produces value. A lot of the time it doesn't.
If we take a step away from SWE opinion and talked to the product users, I think you'll find they just want that one feature they use your thing to work, they want those bugs to be fixed, and they want your product to work when they need it. They don't give a shit about AI, they fucking hate your redesign, and they really really get pissed off when you move stuff about and re-name it.
I just told a colleague no to a new dashboard she was proposing. In the process of explaining why, we realized that the automated system had a new interesting edge case that we could program it to investigate automatically and report - the same thing she wanted the dashboard for.
A no that turns into a yes is the best kind of no.
First, i dont think the low interest rates did that much for “tech companies” who were already cash cows which is usually the bench most people speak about. Small companies already operated in a no free money era as they never had the capital access to begin with.
Covid had a big hiring spike in tech and then it sloft off once rates went up. More of an excuse than real market conditions although startup, for sure impacted. Lets not even start with the political “org building” that still drives the “no” mindset today.
Second, ai has now been in the mix for at least a year now where it is objectively useful. I have not seen a single project complete faster than it would have pre ai. Stability is a wash trending to worse than pre AI.
The rigor is what is see draining slowly. You can be fast, say yes, and use ai all while maintaining some kind of quality bar.
> 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
People don’t realize the breadth of the impact of the low rates and quantitative easing policies.
This stuff clearly helped navigate the 2008 crisis. But the cost is huge: bubbles everywhere, inequalities through the roof, spiralling government debt.
And while the interest rates have gone up, bank reserves are still nowhere near their pre-2008 levels.
Unfortunately, the way the monetary system works is quite difficult to understand, and is unlikely to ever enter the political debate.
ZIRP was 2008 to 2022? The 2010s were calm and collected, zirp-mania gripped us through the pandemic. You cannot compare 2011 and 2021. Totally different environments.
2021 was the apotheosis of 2011. I'm sure hundreds of examples on this site chronicle how wild and not quite calm nor collected it was, but I liked No Exit by Gideon Lewis-Kraus. (The original WIRED article is paywalled, so here's a specific sub-thread started by tptacek from its discussion: https://news.ycombinator.com/item?id=7644161)
Whatever you want to say the current market is, it's nothing like the early 2010s.
The current market absolutely is much more like 2011 than 2021. If you were working in tech back then, it was easy to raise money for specific types of startup (social was the thing back then like AI is today) but it was nothing like 2021. You could raise money for a ham sandwich in 2021.
The ZIRPmania of 2021 was certainly dependent upon what came before it but it wasn’t a natural outcome, it needed the economic chaos of the pandemic, it would not have happened without the pandemic.
this is a terribly written article that oversimplifies what happened during zirp to the point of absurdity. We have always had just say no engineers-ask anyone with a platform role. They’re still saying no a lot.
There are plenty of slow moving projects that focus on the stability of the codebase if you work for a business that isn't a "tech company" and work on services instead of products.
indeed sweeping industry-wide conclusions are often drawn upon technology. however these generally apply to web/apps only. for example, in this thread we have someone extolling the virtues of not reviewing code. this is probably correct in the context of web/apps, but doesn't hold true otherwise. similarly the linked article talks about the frustration of being forced to merge known bad code - acceptable behaviour when the product is pictures on a screen, otherwise i have not observed this behaviour to be systemic
The article's logic doesn't hold up. The OP argues that "no-engineers" were valuable during ZIRP because companies were over-hiring and adding too much code but that's exactly the situation we're in now with AI. If anything, the analogy strengthens the case for them.
The OP even acknowledges this:
> Ironically, if ZIRP had not ended, this would be a glorious moment for the just-say-no engineers.
But then never explains what ZIRP actually has to do with it. Why does the end of ZIRP change anything?
The article vastly underestimates how often no was said before ZIRP. Getting to yes was very, very, very hard. Zirp moved the default to build it snd they will come.
2022 coincided with a lot of things, such as the time period where R&D tax credits for US tech salaries were allowed to expire (reinstated in 2025)
it also coincided with rate hikes
it coincided with ChatGPT launch, which was incapable of replacing engineers at the time
it coincided with a tech bear market
it coincided with a crypto implosion and web3 bear market as well, which a variety of engineers were involved with or had asset exposure to
the R&D tax credit lapse I think was the biggest one, while the smallest headline. and therefore I think making a whole blog post about the rate hikes exclusively is grasping at straws
I stopped saying No. If management wants to push stupid decisions, so be it. They are getting payed for strategic decisions. If their strategy is bullshit, so be it. If they tank the company, so be it. I am not getting payed for that kind of work. And the more bullshit I hear from upper levels, the less I identify with my company.
I believe quality control is a customer-facing concept and customers aren't who employers optimize for.
This is what the original article and most comments are missing here in my opinion. Theories of value matter: https://en.wikipedia.org/wiki/Value_(economics)#Theories . To some degree I might agree with subjective value theory, so in essence everyone values things differently.
However as a framework it describes outcomes without being able to critique them, so whatever happens in a market gets called efficient by definition, including monopoly rents, regulatory capture and the steady drift of returns from labor to capital.
In my opinion labor theory of value describes the underlying relation correctly. The fundamental relation is between employer and employee and the structural goal of that relation becomes extraction of surplus. Customers and product quality enter only as the means through which surplus gets realized.
Once you see it this way, the just-say-no engineer situation makes sense without bringing ZIRP into it. They were doing customer-facing work, defending product quality, inside a structure that doesn't actually want it. They were tolerated, not central. When tolerance shrank, so did they. Good products are incidental to extraction, sometimes useful for it, sometimes in the way.
> Tech companies are now more focused than at any time in the past two decades
Citation needed. In fact, I find the utter opposite - the pivots are happening hard and fast, planning is taking a major back seat, and it’s a ship with speed and look good and be visible at all costs mentality.
The truth is the guardrails are being ignored in the frenzy. Style is winning over substance. I think if you revisit this hot take in a year it’ll have aged so poorly it will seem like a parody.
I reject the typology. Engineers are expected to do a lot of things, those things are different in different environments, and judgement is usually a key consideration. Pidgeonholing someone as a “type” of engineer can help with shallow comparisons but can’t predict behavior in all situations.
Maybe this article cites a real phenomenon. I don't know. What I find odd though, is that it doesn't even include the question of whether there is merit to the Yes or No of the engineer. Maybe the cynical take is that within many corporations it does in fact not matter, but in the real world if you want to fly to the moon, you will need engineers who say No to ideas that are stupid within the framework of engineering, given the projects budget, time and personal constraints and the goal it tries to reach. You don't need a Yes/No-engineer you need someone who can decide how a reliable well-engineered contraption within those limitations would look like. Sometimes that can be a sophisticated rocket, sometimes it can be a makeshift raft or a band aid slapped on a crumbling structure. A good engineer would be one who understands those constraints, while preventing you from killing people in the process.
Many goals companies want to reach are taking place in the real world. But some are not — and I wonder whether the latter may not sometimes be the actual issue. Money boys playing virtual money games while stopping to care about the real physical world just need someone to go along, so their latest Potemkin village can be painted in the color of the season quickly before Paris fashion week.
In the 1990s (and earlier) and 2000s startups were "rebels", almost countercultural (to Corporate America at least). Think about the famous 1984 Macintosh ad that evoked George Orwell. There's a famous story about Steve Jobs remembering a magazine called the Whole Earth Catalog from the 1970s with a picture captioned "Stay hungry, stay foolish". If you listen to Steve Jobs talk about Corporate America, he talks about John Scully or Xerox where conformity ruled. NOthing really challenged the status quo. Nobody really cared about products. Everything was run by accountants, finance people and sales people.
This attitude persisted into the 2010s. Google was quite famous up until that time for shipping when ready, basically. Decisions were engineering-driven rather than being driven by launch dates, product goals, marketing, finance, sales or quarterly earnings. They famously studied what made teams successful with Project Aristotle [1] and concluded that the number one factor was psychological safety.
In the 2020s we have a vastly different picture of neurodivergence than existed in the 2000s and even the 2010s. A lot of the people who found success at Google. Famous examples include the likes of Urs Holzle who famously wrote a user manual [2] for interacting with him. Many of these people did not or would not survive let alone flourish in Corporate America. Why? Because it's a social/political game almost entirely divorced from output. Google's technical infrastructure remains top-notch to this day. They're still coasting on that inertia and what Urs built, both technically and culturally.
But Google slowly dismantled all that. Careers got formalized into job ladders. Getting promoted got harder (eg compare getting promoted to Staff Engineer in 2010 vs 2025). They added stack ranking, which is just a popularity contest and reeks of the Corporate America social/political capital (and I'll die on that hill).
But worst of all (IMHO) was the change in the 2020s that moved from job security (and thus psychological safety) to Corporate America's "up or out" approach. I'm talking of course of about permanent mass layoffs. I cannot begin to describe to you how toxic of an environment that is by comparison. Nitpickers might point out that engineers always had an "up or out" to Senior SWE but it's not the same.
There were other initiatives too like the new CFO Ruth Porat changing the promotion percentages (because nobody had any visibility into that), reducing discretionary equity, etc.
Did Google need to do any of this? At differen ttimes during all this the annual profit per employee was hovering around $1 million. So the answer is "no".
But the fate of any company is that it gets sufficiently large where the only way to keep growing profits is to raise prices or cut costs and for a tech company, labor costs are a major part of the cost structure.
This isn't a Google-specific issue. Google is just a bellwether for the entire industry. The mass layoffs all started about the same time when interest rates were still zero I might add. It's not the first time the industry has engaged in collusion eg [3].
Google to me feels like the new Boeing. Boeing coasted for many years on the 747 and 737 also became a major defense contractor. That inertia took them a long way but there are cracks. The 737MAX was a debacle. The 787 was an outsourcing shitshow.
And hey look where Intel is compared to even 10 years ago. It would be unimaginable given their decades of lithography and engineering dominance. But it's like the move to 10nm just completely broke them and they never recovered.
So I reject that this was a ZIRP issue of being engineering-driven (which is really what we're talking about here). After all, that wasn't a thing before 2008 either.
Ohhh man wait I have so much to say about the “just say no” engineer.
The "just say no" phenotype of engineers believe these things generally (from my experience)
- thinks cloud is a psyop by the big tech people to fool companies into being locked in
- thinks everything companies do is to fool the stock market and prop up stocks
- thinks tech ecosystem was at its peak during their time and ever since then it has become overly complicated mess
- thinks that AI is hyped and will just becoming a passing thing in a few months
- simultaneously believes both that no new features are required in their product because it complicates things but also thinks layoffs shouldn’t be done (what would employees do?)
- believes in conspiracy theories like “bullshit jobs” but doesn’t realise the irony
- believes in things like “enshittification” and is generally pessimistic about the state of tech
There are lots of good things about these engineers as well to be fair
- generally smarter in a narrow sense and can spot out unneeded complexity
- they are the people to go to for hard technical issues
- they do, to be fair, care about their code base which I see less in others
- though dogmatic at times with dev principles, they bring a father like pseudo wise vibe to the team that makes it feel like a family
They also believe Kubernetes as introduced in their company because of Resume Driven Development. Microservices are also a part of Resume Driven Development to prop up Hashicorp stocks.
They strongly despise NoSQL and think a single MySQL instance is totally okay for their multi billion dollar company with 100k reads and 1k writes per second and NoSQL was a pushed by Big Cloud TM.
Code is a liability. Saying no is because the engineer wants to reduce complexity, not because she/ he is so subjectively “obsessed” with code quality. The term “quality” is nowadays misunderstood by management. It means the right amount of effort to build the product as fast and for as low as cost possible, taking into account a team of engineers that can easily add and modify code.
This description is the better one: https://www.nair.sh/guides-and-opinions/communicating-your-e...
"quality" isn't succinctly definable. Zen and the art of system maintenance quality code is written by an old and wise programmer and any attempt to rigidly codify what it is they did and why is doomed to fail.
[flagged]
Please don't cross into personal attack on HN. You can make your substantive points without that.
https://news.ycombinator.com/newsguidelines.html
p.s. We've had to ask you this before: https://news.ycombinator.com/item?id=47103856. If you'd please review the guidelines and take the intended spirit of the site to heart, we'd be grateful.
You got all that from four words?
Also what's wrong with "code is a liability"? That's just 100 % true. The idea isn't exactly novel or revealing, but it's also really fundamental. Every line of code is a liability from day one.
The comment you replied to used that as a reminder and as an opening to an actual argument, it wasn't just a knee-jerk reaction.
Code is an asset.
Code that enables a company to generate revenue is an asset.
Code is an asset.
Code that can be sold for more than it cost to generate is an asset.
Production code is an asset, its maintenance and obligations are an expense, its risks might become liabilities, and companies shouldn't run more code than they need for the same reason they shouldn't own a larger vehicle fleet or more spare warehouse capacity than they need.
I don't think most engineers really disagree with this. Saying code is a liability is technically incorrect but pithy shorthand to communicate that it comes with the associated baggage of maintenance, obligation, and risk; these things suck up money the same way a liability does. Tech debt is also not real debt. It's a figure of speech.
A building is an immovable asset. It’s also made of things that wear and tear. Its value is derived from its capability to house and the capability to house something extends beyond four walls and a roof.
The asset has inherent liabilities. A codebase can be reasoned about extremely similarly
Note how the longer sentences are significantly stricter than the shorter ones. You could maybe add another condition, in the sense that the code has to generate more revenue than it costs to maintain. Then I'd start to agree.
Also note that even when a line of code is generating revenue, it never stops being a liability in almost every sense of the word. Testing it still costs money and time, understanding it costs cognitive power, having it in the context of your LLM coding agent costs tokens, and that's assuming it's a good line of code. If it's bad code (badly named, badly placed, a logic chain that works but has hidden flaws), the costs increase and reverberate throughout the codebase (and your AI coding sessions).
Yep, that was pretty much the point of my comment.
Code is a liability - yes with an and / no with a but.
I’m sure volumes have been written amount, and there’s roughly an infinite amount of nuance to be talked about over a few drinks and a smoke.
That's an oversimplification. Asset vs liability isn't a binary state but a superposition. An asset can carry liabilities.
Your asset might generate $10k a month in revenue, but at the same time may have a high chance of needing a $100k investment in upgrades and repairs to remain productive.
Nah man. You got to say "no" a lot. Even in the age of AI. Often times features downright make no sense, the time to implement can span weeks and it would actively damage the product in the long term. I work in a ecom startup and I got to say no so many times due to added complexity for little reward.
I think saying no is more important now with AI, as features can be built so quickly now. But there are a lot more costs after the feature has been built. Mostly with AI the code isn’t understood that well, wich incurs a cognitive debt. Then there are extra maintentance and documentation costs. And the costs of carrying around features that add no value.
I can imagine that if you’re a startup and want to try new features quickly, it makes sense to say yes more. But the senior mentioned in the article will also be able to understand that.
Thank you. I was about to reply the same comment but I couldn't say it as concisely.
The funny part is some top comments are saying this article is straw man and the rest of them are just proving the archetype is very real.
The problem with this kind of armchair economy is that you can argue both ways.
"End of ZIRP and the raise of just-say-no engineers": with capital being more expensive companies need to invest it wisely, therefore the need the judgement of the just-say-no engineer to avoid blowing it on unnecessary stuff.
I would add: Either you are an engineer that management trusts and whose judgement they value, or you aren’t. If you aren’t, you’re in a bad position anyway.
There's a good article about it. Saying no is a budget. In other words you don't have enough veto power to stop all bad projects so you need to be strategic about spending this budget.
https://lalitm.com/post/why-senior-engineers-let-bad-project...
If management values your opinion on business operations and forward strategy, then you are an advisor and should be remunerated as such.
This is the right answer. Double down or triple down on this comment.
It's on stories like these where I honestly just love the HN community and the comment threads.
I was reading the article, and as it went on I increasingly thought "This is one of those articles that sounds like it's saying something insightful ('it has all the right lingo! ZIRP era! Just-say-no engineers!'), but then when you dig deeper, it doesn't resonate with my experience at all when I was knee deep in software engineering in those years, nor do I feel that it in any way accurately diagnoses the immense changes that are currently happening with AI." In other words, it sounds like buzzword bullshit to me, and in the absence of a downvote button on stories, I'm glad the community is calling it out.
I see it similarly. Companies have varying time preferences over short-term success vs. long-term success.
Sean might be a good engineer but economy seems out of his arena of expertise
Higher interest rates indicate higher urgency, meaning short term investments with fast payoffs. Throw in LLMs that play into that urgency and you get a mass production of AI slop. It doesn't matter if the AI project is a failure, since it failed fast enough to go and do something else. Doing the right thing from the get go is something that only matters for long term projects with significant initial investment.
> Having half of the company’s engineers enmeshed in an endless loop of proposing changes and being told no was totally fine - they didn’t need to be productive anyway, and this way they weren’t impacting business-critical systems.
Well, it's a take. This is pretty cynical.
There are many stories of FAANG hiring during that era for the purpose of denying talent to competitors. But now that you hired them, what will they do? And how will you keep them from creating problems?
It sounds cynical in retrospect; at the time the same set of facts were explained differently, in a way that didn’t hurt people feelings.
> It sounds cynical in retrospect;
At the FAANG I was at, we were pushed to interview interview interview, and the company tripled in size in two years.
We constantly questioned the motive for more engineers, when we had plenty already, constantly seeking alignment. The rationale was more engineers meant we could make more products more quickly.
It never worked, and caused huge headaches that never really went away. It didn't help that team size was made a specific goal of a number of VPs. So it because a goal to grow team size, rather than a business need
And because the VPs were doing it, a whole bunch of people down the hill started copying then, using team size as a forcing function for power.
Those stories were fanciful at the time, too.
That's a bit silly. Presumably you wanted to deny competitors use of these engineers, because they would build something useful. Just have them build that stuff for you instead?
And if competitors were in the same boat, why bother hiring these people at all?
It's about denial of labour leading to denial of broader competition, rather than a true intent to build a competing product. If you were actually to follow through with building the product you would need a lot more than just engineers to roll out a successful product, effectively an entire company is needed, which would spread the company focus out and the lead to investor questions about your focus and commitment. Then if it's an unproven idea there's significant risk in going to market etc etc.
Cheaper to just lock up the talent and burn the wages. Bit of a ding to your books, big ding to your competitor's capability.
In saying that, it's a terrible practice. Massive waste of time, opportunity, talent and money.
>And if competitors were in the same boat, why bother hiring these people at all?
Suppose an established org (N) got disrupted by a startup (N+1) because the startup was able to do things faster and cheaper. Once the startup becomes the established org themselves and slows down a bit, they are exposed to the same risk, unless they hire all the smart people (who would otherwise be hired by N+2 startup) and buy out all the N+2 companies who actually managed to do something despite having less money. Eventually it becomes too expensive and there is a good excuse to fire all those people. I don't think it's 100% of what is happening, but it could be.
As someone else said, much about the post is simply not testable.
Is someone at Facebook working on the Metaverse a crucial part of prototyping new business models, or are they doing busywork? It'll only be clear in hindsight.
> think of this as the just-say-no engineer, as opposed to the just-say-yes engineer. The just-say-yes engineer is obsessed with moving fast, approves code changes by default, values MTTR over MTBF, and tends to ship a lot of code. The just-say-no engineer is obsessed with quality, is happy to move slowly, and blocks code changes by default.
Love the concept of the 'just-say-yes' engineer vs 'just-say-no' engineer (and corresponding prioritisation of MTTR over MTBF).
I'm definitely a 'just-say-yes' with the caveat that bad architectural choices can be super painful to fix later, and features become a lot harder to fix when they have users as opposed to before launch (so I'm a little bit 'just-say-no', or at least 'just-think-for-a-bit-first').
I also think the balance between 'just-say-yes' and 'just-say-no' really depends a lot on the project. If it's finance or healthcare, perhaps 'no' by default is best. But if it's a silly startup idea, YOLO.
A "just say yes" attitude leads to certain disaster then because the time to fix the product never comes. Demanding the time to clean up is equivalent to saying no. Whoever is in charge of development needs to have the power to do that and actually use it (if they don't ever use it, they effectively don't have it).
> A "just say yes" attitude leads to certain disaster
Disaster's a possibility. But if an idea has a 1% chance of success, "just say no" usually assures failure, whereas "just say yes" is a shot at that 1% chance.
Don’t be an engineer who says “no” with zero alternative solutions. That’s not being a good engineer, it’s being lazy and trying to look good. Often times an engineer will put forth a solution that’s non-ideal due to legacy reasons, but required nonetheless. And no they can’t rewrite the entire system to “do it the right way”. You're not being some super high IQ genius by saying “no” or pointing out the solution is non-ideal.
I remember this exact software dev manager. She knew the system well. She became a manager. She started saying no to many PMs and other devs. In meetings with business people, she was a bully because she knew how to code. The worst was that she offered no alternative when she didn’t agree with the proposal. She was difficult to work with.
I wonder if she is the same ZIRP person this article is talking about.
What a wild take. The straightforward takeaway from the end of ZIRP and the resulting increase in focus would be that you need to say no to more things, not fewer? You have to really contort yourself to argue that actually ZIRP gave rise to an entire class of make-work which then gave rise to a class of folks to keep said make-work under control.
The relevant era wasn't even a good example of (near) zero interest rates. At least when control for inflation. And there are other eras that also had low or even negative real interest rates.
> having more engineers around was beneficial to the stock price ... When banks hiked interest rates ... It was just no longer profitable to keep a bloated engineering staff around to boost the stock price.
Erm, what's known of the mechanism coupling software engineer head count and stock price? Or is it just an empirically observed phenomena?
> … why not keep your engineers and deliver 20x the value?
Probably because there isn’t actually an increase in demand for the capabilities of software, and engineers, product managers, and UI/UX designers are justifying the existence of their jobs by complicating software more than necessary.
Anyway, the essence of the article is that a “just say no” engineer is a person who knows how to use and enforce constraints so that complex systems remain manageable in the long-term; and that companies perceive such engineers to be irrelevant as AI coding tools become more mainstream.
I think that that has definitely happened, even with my own employer, but I think that companies of the same mindset just don’t have strong engineering cultures to begin with, and will be natural selected into oblivion during this wave of disruption, which already coincides with a prolonged period of economic uncertainty to begin with.
AI tools are great, but they are only as good as your people’s discernment. If you’re making AI adoption a KPI in your company, you’ve already lost sight of what your business is really about, and you’ll be bankrupt by your token spending before you can beat your competition.
Doesnt seem very testable of a hypothesis. As a company thats trying to get things done, doesnt it make sense to have someone help you prioritize by telling you when some decisions have long term costs?
There’s this trend that tries to sell the idea that, if LLMs and agents have any shortcomings, instead of them getting better we should lower the standards. Focus on the “MTTR”. Is the code bad? Don’t read it. Don’t review it. Remove the bottleneck (the human in the loop). This narrative is all over the place.
This tech is quite useful, and I wish we focused on how to work with the tool better and improved our processes around it instead of treating the symptoms.
Aren't people working on both? I'm sure the AI labs are working on their end of it. People are building better agents. You can work on skills or tweaking your AGENTS.md.
There no end to what you can do, but the question is how much time you devote to that versus your actual project.
The "Just Say No" engineer is a person who knows what existing tools can do, while more junior people don't know what their tools can do. So junior people are constantly proposing new types of yak shaving (new architecture, new storage backend, new framework, etc) that must be done before solving the problem at hand. This is all wasted resources and time, even if LLMs let you shave yaks faster. A good JSNE focuses your resources on solving problems straight away, not pouring them all into a bottomless pit of busy work.
Beautiful write-up, thank you.
One aspect that still bothers me is that you claim the just-say-no-engineer "was a critical role during ZIRP." I might be in the minority here, but I don't hold that same stance. I wonder if I am alone in that?
I think the "just say no" engineers were massively sidelined during ZIRP
Actually I suspect they are just massively sidelined in software in general because of how few regulations exist
The "just say no" engineer is someone who thrives in regulated environments, because (enforced) regulations are the only things that actually slow down the growth at all costs minded PMs in the world. And even then only sometimes
I think that's it. LLMs infected companies with the Rage Virus and now they're running mindlessly at anything that moves. A "just say no" engineer has no air in such an environment. It is FOMO of the most diffuse kind, with absolutely nobody knowing what the what is we're missing, but everybody (and that includes myself) knows something is going to change.
We like to dress up in suits, but we're all apes afraid of shapes in the clouds.
> It used to be that they only had to say no to more junior engineers’ handwritten PRs, but now they have to say no to a barrage of AI-generated code, some of it generated by managers and VPs who are politically difficult to say no to.
Holy cow. I worked at a big tech firm but left the industry prior to the emergence of InstructGPT et al., so I haven't experienced LLM code generation from the inside. Is this really happening -- upper managers and VPs proposing code changes they generated with LLMs? I don't think I'd survive.
Yes, this is happening. A friend of mine was telling me about a 25k LoC PR that was submitted by a product manager that he had to content with. And the politics are real - you can't just be like "no", but it's pretty tough to meaningfully review a 25k line PR, let alone from someone who knows fuck all about what they're doing and can't answer questions you might have.
The CEO of Shopify is filing PRs against their public repos: https://github.com/Shopify/liquid/pull/2056
(To be fair, he did build liquid and much of Shopify himself at the start of the company so he's not exactly inexperienced, but still.)
I skimmed that PR briefly and it appears a) not to be slop and b) to be very reviewable as its structured as a series of small commits that each make one small change. This is far from the sort of management PR I'd fear.
There's no reason for engineers to be under more pressure to accept technical debt (which is what we're really talking about with the yes-or-no framing) after the end of ZIRP. Quite the opposite: right now debt is expensive and programmers are cheap, it's a good time to have high quality standards and build robust infrastructure that will position you to catch the next growth wave. It really is AI (or rather AI hype) making the difference.
the difference IMO is that now businesses have to find a product-market-fit faster. you can't spend 5 years building the perfect system. you get to spend 1 year building a system somebody will pay to use.
>Quite the opposite: right now debt is expensive and programmers are cheap, it's a good time to have high quality standards and build robust infrastructure that will position you to catch the next growth wave.
Uhm, no? You got it exactly backwards. Tech debt isn't the same as interest payments, tech debt is a future productivity decline, whereas interest payments require you to pay more than the initial money you borrowed.
If debt is expensive, then your goal is to pay it off quickly, since debt scales with the remaining principal and grows with interest. This means that you want to cut corners everywhere and incur tech debt. You do not want a long term investment in high quality standards and build robust infrastructure. Doing that will delay the payoff day. Each early payments reduce the principal, which reduces future interest payments.
In other words, it's a terrible time to have high quality standards and build robust infrastructure. There also won't be a "next growth wave", because the growth wave is now. You're about to miss it if you invest in the long term.
You pay tech debt with compounding interest at exorbitant rates.
Another way to look at it is to say that like any analogy applied to software development it is weak. It is not like normal debt at all because you must start paying back immediately one way or another. So you can't just pile hack on hack and wait for a year to pay back. You will start having to pay back for the hacks within a couple of months because of the bugs you have to fix and how hard it is to work with the messy codebase. In some cases you may even grind to a halt before you get anything substantial out to the customer. This doesn't mean that you should never hack stuff in. But in general it's cheaper to pay off the debt quickly instead of paying for the debt.
Ah indeed. As monetary debt becomes more expensive it makes tech debt relatively cheaper - fixing your code in the future is cheaper than fixing it now.
I've seen the "just say no" thing institutionalized through SRE, where they can use the "banhammer" to stop the deployment of new features or whatever hasn't passed their various "reliability checklists" and such (if they're responsible for on-call)
I'm sure this won't be popular but a lot of "SRE" teams were definitely ZIRP phenomenon, heh.
as someone on the other side who has had to deal with deploys that go from 5PM to 2AM due to bad code changes, and being on call with 40+ pages a day, there's a reason why SREs are just say no when they're the first responders to outages caused by poorly implemented features. I'm not saying just say no is the right mentality but I can see why many develop the cynical anti-change mentality
Would you want to be on call for someone else's garbage though? There's a very obvious and real tension here.
It's a classic case of power vs responsibility. Generally SREs get all the responsibility but little power. Even if developers are also suffering on-call shifts, the first strike always hits SREs.
Super interesting to link these two concepts.
Another great post on this blog. I need to go back and read some other posts I've missed / that didn't make the front page of HN.
The cost of writing code dropped but the cost of maintaining it didn't. If anything that makes saying no more important, not less.
I agree with the author that engineers need to recalibrate and say yes more often but the zirp connection is a stretch and unnecessary.
Good engineers will say yes and no thoughtfully and will adjust to the new reality anyway. So it feels kind of pointless since no one is really a just say yes or just say no person, though it is well written.
Nah. In the era of LLMs the ability of saying no to bad features that are easy to implement but add no value is more important than ever.
LLMs aside, being able to say no is important when resources are scarce
> 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?)
in some orgs it was a good excuse to cut the underperformers. these folks wouldnt deliver 10x value with AI, they would either deliver 0x or -10x (with contributions that the just say no engineer would have normally said no to)
What else will we blame interest rates for? I believe we're applying it as an explanation for far too many things. It is but one factor of many changing the mechanics of tech since ~2020: AI coding; big tech capex spending on AI; pandemic over-hiring hangover (mostly done); slowing growth of digital ad spending; TCJA section 174 (partly repealled, but still a thing).
> 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?)
I guess not every service or product needs 20x the value. That depends on the market segment, market maturity, and actual demand.
Who is their right minds would be wedded to an identity of saying "No"? Code quality puritans are annoying but if they do their job right they actually speed-up the development process because they don't let technical debt accumulate. Ultimately saying "No" is protecting your codebase. In the era of LLMs, saying "No" is much easier because you don't have to worry about the author feeling bad.
The whole zero-interest rate narrative I see used in a variety of context is a bit silly. Real interest rates were seldom close to zero. During much of that time they were negative, for example. And during many other times, when we had rather high positive nominal rates, real rates were closer to zero (because of inflation), and the author doesn't say anything weird happened then.
There’s also section 174, which happened to end in 2022.
Earlier submission: https://news.ycombinator.com/item?id=48245331
I count six submissions of this article on https://news.ycombinator.com/from?site=seangoedecke.com - but today's is the one that's getting the comments.
There's no discussion there.
Making up a guy to get mad at.
...the article seems quite supportive and appreciative of this guy?
Making up a guy to be supportive and appreciative of is still making up a guy.
I agree with this take for experienced and capable engineering teams. Three times over the last three years, I have told my senior engineers to skip code review, and nothing catastrophic happened, and recovery from bugs was rapid. Three times I have been told by engineering management to reimplement code review. Now that management is either gone or about to be gone.
It is a bit frustrating when you want to do risk based approach but then it is much more work to explain it to people who don’t know better but they want a checkbox or read on the internet “that’s proper way of doing things”.
Another example is password complexity rules, we try to use latest recommendations with no forcing of PW change, no requirements beside length - but then there will be customer that will make fuss that we don’t have it as as it is compliance check box to have complex PW.
Skipping code reviews and the bugs it causes can be a problem, or it can be easily solvable later when the bugs are found. It varies a lot.
Skipping code reviews and the poor code that can happen because nobody took a second look - that's more of a problem. Because 6-12 months down the line, there's not a few bugs that need to be fixed. Instead, there's a horrible code base that causes all _future_ development to be a lot slower.
Few times bugs causes unrecoverable data - and code review are needed again.
You have engineers that can say “hey this DB change might be risky let’s take second person to review it”.
No one is forbidding reviews.
But if you have a junior pushing code that can cause unrecoverable data loss his code should be reviewed.
New CEO walks into the office for the first day. Looks at the budget to see what they can do to "Make a mark"
[Budget proposal officer]: "Here is the new cleaning budget"
[CEO]: "looks around the office, the office is clean, why do we need cleaners? much less expensive cleaners"
[Budget proposal officer]: "The cleaners keep the office clean though"
[CEO]: "Nonsense! I read a substack about this, lets get rid of the cleaners"
//Six months later in an ALL hands//
[CEO]: "Look I know that we have had issues, The washing facilities were sub standard, and in some cases people were poisoned by poor hygene. We have insistuted a new mandatory training called `keeping the office clean, you're the first link in the chain` to help keep everyone happy and healthy"
Sorry: is there any evidence for the proposition that staffing was excessive, or that it was ZIRP that led to excessive staffing? The idea is plausible, but was it actual?
Second, is there any evidence for more or less gatekeeping?
Or evidence that there were relatively more "pure-engineering" projects? (Though one would expect that for the new technologies and markets. The green fields migrated from scale to data science and AI.)
Finally, wouldn't more gatekeeping be required when AI reduces the cost of making concrete tech proposals?
This seems not connected to facts or compelling in theory, but it does touch on anecdotal and emotional truths. I believe the writer could do better. (More, I believe HN readers should insist on writers doing better, to raise quality and offer harder challenges to people.)
I feel like the article is pretty contradictory.
Apparently ZIRP was the era of abundance and of codebases growing rapidly and:
> with so many engineers running wild, how would they keep their systems from becoming completely unmanageable? Enter the just-say-no engineer.
So before "AI", the just-say-no engineer was a vital part of the system who was preventing it from getting overrun by (human-generated) slop. Good.
If ZIRP had not ended (but with AI):
> this would be a glorious moment for the just-say-no engineers. LLMs would have thrown fuel on the “engineers running wild” problem that the just-say-no engineers were empowered to solve. Tech companies, unable to publicly or privately cast doubt on AI-assisted coding, would have relied heavily on these engineers to prevent the tsunami of AI code from swamping the entire company.
Again, the just-say-no engineered would have been a vital part of the system shielding it from the influx of slop. And apparently this scenario isn't what's happening, because ZIRP had ended. Okay, what next?
> LLMs are adding insult to injury for the just-say-no engineer. They’re forced to watch while other engineers merge AI-generated PRs that would previously have been blocked, and are told to use the tools themselves
So even though ZIRP had ended and we've avoided the slopocalypse, the teams (now reduced by layoffs but augmented with AI) are still adding slop, even the traditional gatekeepers (just-say-nos) are now being actively forced to add slop and suddenly, none of that is a problem?
I'm simply not following.
I couldn't understand either until I remembered appearances matter more than substance.
So if your goal is to deliver as much features as possible - regardless of the quality or roi - gatekeepers are an obstacle to remove.
The hypothesis that companies today need to really focus so they can make money ignores the fact that, in fact, most or the major AI companies are not making money relative to their costs.
The article is weird, but I wouldn’t take the major AI companies as being representative of companies in general.
I disagree with the analysis, although I liked the opening paragraph. Why separate the economics of interest rates from the economics of AI productivity?
This is perhaps a very American-centric article? I realise that ZIRP was near-global, but "When banks hiked interest rates, almost every tech company immediately laid off 5-20% of their engineers." does not track with my or my friends' experiences.
And, fundamentally, in countries with employee rights, as an employee I do not give two shits about interest rates the company I work at borrows on. My philosophy on software design does not change. You can argue that the company might pick and choose who it makes redundant, and they might value people who produce "more product", but companies have always valued that visibility. It's your responsibility, if you care, to sell your actions in a commercial context. I don't think ZIRP changes that, and I have not personally noticed a change there.
This is certainly an opinion.
But, I would gently point out that people are actively looking to move away from github because its unreliably
People hate shit when its not working, we are in a bubble where people allow AI products to have shit outcomes, because they either sound human, or do amazing things most of the time (generate that image, sort out that spreadsheet, generate that code or answer that question)
Right now a lot of people are designing https://www.wired.com/2014/07/homer-simpson-car/ thee homer simpson car.
Because, ironically, there is lots of money about to subsidise anything with an AI sheen (how very ZIRP) people are making all sorts of shit with it. Some times it produces value. A lot of the time it doesn't.
If we take a step away from SWE opinion and talked to the product users, I think you'll find they just want that one feature they use your thing to work, they want those bugs to be fixed, and they want your product to work when they need it. They don't give a shit about AI, they fucking hate your redesign, and they really really get pissed off when you move stuff about and re-name it.
I just told a colleague no to a new dashboard she was proposing. In the process of explaining why, we realized that the automated system had a new interesting edge case that we could program it to investigate automatically and report - the same thing she wanted the dashboard for.
A no that turns into a yes is the best kind of no.
I low key disagree with the majority of this.
First, i dont think the low interest rates did that much for “tech companies” who were already cash cows which is usually the bench most people speak about. Small companies already operated in a no free money era as they never had the capital access to begin with.
Covid had a big hiring spike in tech and then it sloft off once rates went up. More of an excuse than real market conditions although startup, for sure impacted. Lets not even start with the political “org building” that still drives the “no” mindset today.
Second, ai has now been in the mix for at least a year now where it is objectively useful. I have not seen a single project complete faster than it would have pre ai. Stability is a wash trending to worse than pre AI.
The rigor is what is see draining slowly. You can be fast, say yes, and use ai all while maintaining some kind of quality bar.
> 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
And there it is.
That line stuck out to me too.
Engineers have known that bad engineering cultures cause tiny errors and imprecise code to compound into systemic problems.
Why is this suddenly not a problem? If your AI agent is wrong 5% of the time, what do you think happens when you run it a 1000 times?
Good article.
People don’t realize the breadth of the impact of the low rates and quantitative easing policies.
This stuff clearly helped navigate the 2008 crisis. But the cost is huge: bubbles everywhere, inequalities through the roof, spiralling government debt.
And while the interest rates have gone up, bank reserves are still nowhere near their pre-2008 levels.
Unfortunately, the way the monetary system works is quite difficult to understand, and is unlikely to ever enter the political debate.
ZIRP was 2008 to 2022? The 2010s were calm and collected, zirp-mania gripped us through the pandemic. You cannot compare 2011 and 2021. Totally different environments.
2021 was the apotheosis of 2011. I'm sure hundreds of examples on this site chronicle how wild and not quite calm nor collected it was, but I liked No Exit by Gideon Lewis-Kraus. (The original WIRED article is paywalled, so here's a specific sub-thread started by tptacek from its discussion: https://news.ycombinator.com/item?id=7644161)
Whatever you want to say the current market is, it's nothing like the early 2010s.
The current market absolutely is much more like 2011 than 2021. If you were working in tech back then, it was easy to raise money for specific types of startup (social was the thing back then like AI is today) but it was nothing like 2021. You could raise money for a ham sandwich in 2021.
The ZIRPmania of 2021 was certainly dependent upon what came before it but it wasn’t a natural outcome, it needed the economic chaos of the pandemic, it would not have happened without the pandemic.
No Exit, written in 2014, recounts that infamous time a team (trio?) of founders were funded before they had a business idea.
this is a terribly written article that oversimplifies what happened during zirp to the point of absurdity. We have always had just say no engineers-ask anyone with a platform role. They’re still saying no a lot.
This is trivially incorrect outside of SV.
There are plenty of slow moving projects that focus on the stability of the codebase if you work for a business that isn't a "tech company" and work on services instead of products.
indeed sweeping industry-wide conclusions are often drawn upon technology. however these generally apply to web/apps only. for example, in this thread we have someone extolling the virtues of not reviewing code. this is probably correct in the context of web/apps, but doesn't hold true otherwise. similarly the linked article talks about the frustration of being forced to merge known bad code - acceptable behaviour when the product is pictures on a screen, otherwise i have not observed this behaviour to be systemic
I wish it was easier to find this sort of business and work my way into one
I'm so tired of startups.
what's this glorious "do whatever you want" era???
The article's logic doesn't hold up. The OP argues that "no-engineers" were valuable during ZIRP because companies were over-hiring and adding too much code but that's exactly the situation we're in now with AI. If anything, the analogy strengthens the case for them.
The OP even acknowledges this:
> Ironically, if ZIRP had not ended, this would be a glorious moment for the just-say-no engineers.
But then never explains what ZIRP actually has to do with it. Why does the end of ZIRP change anything?
The article vastly underestimates how often no was said before ZIRP. Getting to yes was very, very, very hard. Zirp moved the default to build it snd they will come.
2022 coincided with a lot of things, such as the time period where R&D tax credits for US tech salaries were allowed to expire (reinstated in 2025)
it also coincided with rate hikes
it coincided with ChatGPT launch, which was incapable of replacing engineers at the time
it coincided with a tech bear market
it coincided with a crypto implosion and web3 bear market as well, which a variety of engineers were involved with or had asset exposure to
the R&D tax credit lapse I think was the biggest one, while the smallest headline. and therefore I think making a whole blog post about the rate hikes exclusively is grasping at straws
I stopped saying No. If management wants to push stupid decisions, so be it. They are getting payed for strategic decisions. If their strategy is bullshit, so be it. If they tank the company, so be it. I am not getting payed for that kind of work. And the more bullshit I hear from upper levels, the less I identify with my company.
What if management pushes stupid decisions and blames you for the second order effects? Happens often.
This is a nice narrative, but without real world test cases, reads like yet another fanfiction on the internet.
Just-say-no is a Quality Control mechanism.
You need someone to say: this shit is not going to prod, unless its value is obvious to everyone
I believe quality control is a customer-facing concept and customers aren't who employers optimize for.
This is what the original article and most comments are missing here in my opinion. Theories of value matter: https://en.wikipedia.org/wiki/Value_(economics)#Theories . To some degree I might agree with subjective value theory, so in essence everyone values things differently.
However as a framework it describes outcomes without being able to critique them, so whatever happens in a market gets called efficient by definition, including monopoly rents, regulatory capture and the steady drift of returns from labor to capital.
In my opinion labor theory of value describes the underlying relation correctly. The fundamental relation is between employer and employee and the structural goal of that relation becomes extraction of surplus. Customers and product quality enter only as the means through which surplus gets realized.
Once you see it this way, the just-say-no engineer situation makes sense without bringing ZIRP into it. They were doing customer-facing work, defending product quality, inside a structure that doesn't actually want it. They were tolerated, not central. When tolerance shrank, so did they. Good products are incidental to extraction, sometimes useful for it, sometimes in the way.
> Tech companies are now more focused than at any time in the past two decades
Citation needed. In fact, I find the utter opposite - the pivots are happening hard and fast, planning is taking a major back seat, and it’s a ship with speed and look good and be visible at all costs mentality.
The truth is the guardrails are being ignored in the frenzy. Style is winning over substance. I think if you revisit this hot take in a year it’ll have aged so poorly it will seem like a parody.
That's what focus looks like to a just-say-yes engineer. They're just focused on shipping, not tinkering.
I reject the typology. Engineers are expected to do a lot of things, those things are different in different environments, and judgement is usually a key consideration. Pidgeonholing someone as a “type” of engineer can help with shallow comparisons but can’t predict behavior in all situations.
Maybe this article cites a real phenomenon. I don't know. What I find odd though, is that it doesn't even include the question of whether there is merit to the Yes or No of the engineer. Maybe the cynical take is that within many corporations it does in fact not matter, but in the real world if you want to fly to the moon, you will need engineers who say No to ideas that are stupid within the framework of engineering, given the projects budget, time and personal constraints and the goal it tries to reach. You don't need a Yes/No-engineer you need someone who can decide how a reliable well-engineered contraption within those limitations would look like. Sometimes that can be a sophisticated rocket, sometimes it can be a makeshift raft or a band aid slapped on a crumbling structure. A good engineer would be one who understands those constraints, while preventing you from killing people in the process.
Many goals companies want to reach are taking place in the real world. But some are not — and I wonder whether the latter may not sometimes be the actual issue. Money boys playing virtual money games while stopping to care about the real physical world just need someone to go along, so their latest Potemkin village can be painted in the color of the season quickly before Paris fashion week.
> desperately chasing new capabilities and features that can make money
Ah yes. And.. where are those?
I don't agree with this argument.
In the 1990s (and earlier) and 2000s startups were "rebels", almost countercultural (to Corporate America at least). Think about the famous 1984 Macintosh ad that evoked George Orwell. There's a famous story about Steve Jobs remembering a magazine called the Whole Earth Catalog from the 1970s with a picture captioned "Stay hungry, stay foolish". If you listen to Steve Jobs talk about Corporate America, he talks about John Scully or Xerox where conformity ruled. NOthing really challenged the status quo. Nobody really cared about products. Everything was run by accountants, finance people and sales people.
This attitude persisted into the 2010s. Google was quite famous up until that time for shipping when ready, basically. Decisions were engineering-driven rather than being driven by launch dates, product goals, marketing, finance, sales or quarterly earnings. They famously studied what made teams successful with Project Aristotle [1] and concluded that the number one factor was psychological safety.
In the 2020s we have a vastly different picture of neurodivergence than existed in the 2000s and even the 2010s. A lot of the people who found success at Google. Famous examples include the likes of Urs Holzle who famously wrote a user manual [2] for interacting with him. Many of these people did not or would not survive let alone flourish in Corporate America. Why? Because it's a social/political game almost entirely divorced from output. Google's technical infrastructure remains top-notch to this day. They're still coasting on that inertia and what Urs built, both technically and culturally.
But Google slowly dismantled all that. Careers got formalized into job ladders. Getting promoted got harder (eg compare getting promoted to Staff Engineer in 2010 vs 2025). They added stack ranking, which is just a popularity contest and reeks of the Corporate America social/political capital (and I'll die on that hill).
But worst of all (IMHO) was the change in the 2020s that moved from job security (and thus psychological safety) to Corporate America's "up or out" approach. I'm talking of course of about permanent mass layoffs. I cannot begin to describe to you how toxic of an environment that is by comparison. Nitpickers might point out that engineers always had an "up or out" to Senior SWE but it's not the same.
There were other initiatives too like the new CFO Ruth Porat changing the promotion percentages (because nobody had any visibility into that), reducing discretionary equity, etc.
Did Google need to do any of this? At differen ttimes during all this the annual profit per employee was hovering around $1 million. So the answer is "no".
But the fate of any company is that it gets sufficiently large where the only way to keep growing profits is to raise prices or cut costs and for a tech company, labor costs are a major part of the cost structure.
This isn't a Google-specific issue. Google is just a bellwether for the entire industry. The mass layoffs all started about the same time when interest rates were still zero I might add. It's not the first time the industry has engaged in collusion eg [3].
Google to me feels like the new Boeing. Boeing coasted for many years on the 747 and 737 also became a major defense contractor. That inertia took them a long way but there are cracks. The 737MAX was a debacle. The 787 was an outsourcing shitshow.
And hey look where Intel is compared to even 10 years ago. It would be unimaginable given their decades of lithography and engineering dominance. But it's like the move to 10nm just completely broke them and they never recovered.
So I reject that this was a ZIRP issue of being engineering-driven (which is really what we're talking about here). After all, that wasn't a thing before 2008 either.
[1]: https://psychsafety.com/googles-project-aristotle/
[2]: https://codenote.net/en/posts/6191/
[3]: https://en.wikipedia.org/wiki/High-Tech_Employee_Antitrust_L...
Ohhh man wait I have so much to say about the “just say no” engineer.
The "just say no" phenotype of engineers believe these things generally (from my experience)
- thinks cloud is a psyop by the big tech people to fool companies into being locked in
- thinks everything companies do is to fool the stock market and prop up stocks
- thinks tech ecosystem was at its peak during their time and ever since then it has become overly complicated mess
- thinks that AI is hyped and will just becoming a passing thing in a few months
- simultaneously believes both that no new features are required in their product because it complicates things but also thinks layoffs shouldn’t be done (what would employees do?)
- believes in conspiracy theories like “bullshit jobs” but doesn’t realise the irony
- believes in things like “enshittification” and is generally pessimistic about the state of tech
There are lots of good things about these engineers as well to be fair
- generally smarter in a narrow sense and can spot out unneeded complexity
- they are the people to go to for hard technical issues
- they do, to be fair, care about their code base which I see less in others
- though dogmatic at times with dev principles, they bring a father like pseudo wise vibe to the team that makes it feel like a family
They also believe Kubernetes as introduced in their company because of Resume Driven Development. Microservices are also a part of Resume Driven Development to prop up Hashicorp stocks.
They strongly despise NoSQL and think a single MySQL instance is totally okay for their multi billion dollar company with 100k reads and 1k writes per second and NoSQL was a pushed by Big Cloud TM.