> 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.
What's known of the mechanism coupling software engineer head count and stock price? Or is it just an empirically observed phenomena.
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.
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.
> 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.
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?
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.
> 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.
> 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.
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.
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.
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?
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.
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.
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
> 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.
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.
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.
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.
I disagree with the analysis, although I liked the opening paragraph. Why separate the economics of interest rates from the economics of AI productivity?
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.
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.
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.
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 systematic
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.
Ohhh man wait I have so much to say about the “just say no” engineer. Here are some characteristics I have noticed
- 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
This article confidently spouts explanations for huge society wide phenomena without any evidence, just trust me bro. I don't buy most of his argument.
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.
What's known of the mechanism coupling software engineer head count and stock price? Or is it just an empirically observed phenomena.
"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 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.
Well, it's a take. This is pretty cynical.
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.
And if competitors were in the same boat, why bother hiring these people at all?
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.
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.
(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.)
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.
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.
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?
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
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.
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.
There no end to what you can do, but the question is how much time you devote to that versus your actual project.
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 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.
No one is forbidding reviews.
But if you have a junior pushing code that can cause unrecoverable data loss his code should be reviewed.
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.
Whatever you want to say the current market is, it's nothing like the early 2010s.
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.
You need someone to say: this shit is not going to prod, unless its value is obvious to everyone
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.
I'm so tired of startups.
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.
- 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
Ah yes. And.. where are those?
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.