> 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.
Right, and it’s just the wrong, maybe weirdest correlation to suggest, and I’m someone that loves to find unexpected connections between things. ZIRP had nothing to do with this “no-man” phenomenon, it predated ZIRP.
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 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.
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 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.
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.
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.
>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.
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.
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.
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.
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.
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.
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.
> 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.
I disagree with the analysis, although I liked the opening paragraph. Why separate the economics of interest rates from the economics of AI productivity?
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.
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.
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.
69 comments
[ 3.3 ms ] story [ 62.1 ms ] threadWell, it's a take. This is pretty cynical.
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.
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?
Ah yes. And.. where are those?
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.
"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.
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.
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.
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.
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.
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.
You need someone to say: this shit is not going to prod, unless its value is obvious to everyone