The just-say-no engineer was a ZIRP phenomenon

The engineer who says no all the time is a real role model among senior and staff engineers. Their role is to slow things down, block the development of features that increase complexity, and ensure that as little code as possible is written (because code is a liability).

We can just think of it as an engineer saying no^{Unlike the engineer who just says yes. The just-yes-saying engineer is obsessed with moving fast, approving code changes by default, valuing MTTR over MTBF, and shipping a lot of code. The just-say-no engineer is obsessed with quality, happy to move slowly, and blocks code changes by default. Most engineers are somewhere in the middle of the spectrum. By “just-say-no engineer”, I’m talking about the group of engineers who identify most strongly with that archetype.}

In the age of AI, ‘nay-saying’ engineers are facing a tough time. It used to be that they only had to say no to the handwritten PRs of more junior engineers, but now they have to say no to reams of AI-generated code, some of it generated by managers and VPs who find it politically difficult to say no. For the first time in his career, he is under a lot of pressure to lower his standards and start saying yes. However, It’s not because of AI. The reason for this is the end of ZIRP.

ZIRP and the no-nonsense engineer

ZIRP, or “Zero Interest Rate Policy”, is a shorthand for the era of software development between 2008 and 2022 when banks were allowing companies to borrow money at near-zero interest rates. During this period, investors were throwing away borrowed money. AnythingWhich meant that tech companies were incentivized to continually hire engineers for low-risk, high-reward projects.^{. Successful companies will routinely grow from tens of engineers to thousands, working on all sorts of things: tangential open-source projects, endless technology migrations, rewriting in other languages, etc.}

It was a great time to be a software engineer. We had a lot of bargaining power, and we could get paid top dollar to do almost anything. The owners largely didn’t care, because (a) the teams were growing so fast that they couldn’t pay attention, and (b) having more engineers around was beneficial to the stock price, which was the main thing they cared about. But tech companies faced a problem: With so many engineers running wild, how would they keep their systems from becoming completely unmanageable? Enter the just-say-no engineer.

In this environment, having a very senior engineer whose sole job was to say no to things was actually quite valuable to the company. There are a few reasons for this:

• It was perfectly fine for half the company’s engineers to be stuck in an endless cycle of proposing changes and being told no – they didn’t need to be productive anyway, and thus weren’t impacting business-critical systems.
• It also solved the problem of the 5% of engineers who would get drunk on their technical freedom and make absurd proposals like migrating to hand-rolled databases.
• Having a reputation for very high technical level is a positive thing for hiring (and remember, during ZIRP every tech company was always hiring)

End of ZIRP

When banks raised interest rates, almost every tech company immediately laid off 5-20% of their engineers. It was no longer profitable to retain a large engineering staff to boost stock prices. Instead, companies actually had to make money.^{. However, this was not a good public explanation for the layoffs, because it seemed weak to admit that you were paying hundreds of engineers to do unprofitable work. Fortunately, the end of ZIRP coincided roughly with the rise of ChatGPT, so tech companies were able to blame their layoffs on the power of AI. Saying “With this transformative new technology, we are able to deliver 10x the value with half the engineers” is a very strong message, even if it doesn’t mean much (if that’s true, why not keep your engineers and deliver 20x the value?)}

A somewhat similar dynamic is happening with a nay-saying engineer. Tech companies are now more concentrated than at any time in the last two decades. They’re not just spewing random nonsense anymore; Instead they are eagerly pursuing new capabilities and features that can make money (mostly built on AI for obvious reasons). This is a new environment actively hostile For the just-say-no engineer. It’s like a shark was pulled out of the deep sea and dropped into a fast-flowing river: what was once a powerful apex predator is now disoriented and flailing.

This type of engineer received indirect (albeit distant) support from his management. If someone complained, they were often told “that engineer knew what they were doing, if they didn’t, I wouldn’t trust them”. Now that support has ended. The engineer who just-say-no is now being criticized and actively written off by his management. They’re being told to be a team player, finding a way to say yes, or not being consulted (with the company’s blessing) on ​​important decisions. They are getting bad reviews for the exact same behavior they were rewarded for before 2022^.

None of this depends on AI. If LLM had not progressed this decade, we would still be seeing the same cultural shift in the industry. Companies may still be laying off engineers, and engineers whose job it is to say no to something will still be upset and confused as to why they are now being punished for saying no.

Aye

The irony is that if ZIRP had not been killed, it would have been a proud moment for the engineers who said no. LLM would have given rise to the problem of “engineers running wild”, which only the nay-saying engineers were empowered to solve. Tech companies are unable to publicly or privately cast doubt on AI-assisted coding^{would have trusted Heavy These engineers are charged with preventing a tsunami of AI code from overwhelming the entire company. They were paid even better and were respected like kings.}

Instead, those saying no to LLM are adding insult to injury for the engineer. They are forced to watch other engineers merge AI-generated PRs that were previously blocked, and are asked to use the tools themselves: to become the kind of engineers they have spent their entire careers fighting against.

What’s worse, most AI tooling works. It’s not (yet) causing any havoc^{. The code isn’t as clean, and it’s a little less understood, but it’s good enough (especially in a world where companies are trying a lot of new things and abandoning the ones that fail). So the nay-saying engineer faces a threat not only to his livelihood, but also to his entire self-identity: He must either insist that the apocalypse is just around the corner, or accept that his technical role depended on it. really weird Economic environment in the technology industry.}

pure and impure engineering

Will the engineer who just says ‘no’ become extinct? No, they no longer fit every single tech company, but there are domains where they are needed. In pure and impure software engineering I distinguished between “pure” engineering, which has a good scope, largely technical goal (like creating a compiler or language runtime) and “pure engineering”, which has a bad scope, largely customer-driven goal (like trying out a new feature you’re not sure will work). During the ZIRP era, tech companies did a lot of pure work (for example, building React), and there was a tendency to treat even impure work like pure work. The bus-sayer-no is an engineer Great For pure work, because pure codebases have a much higher bar for quality and can tolerate slower development cycles.

Most tech companies are still doing some form of pure work, especially in their core infrastructure. It’s essential work, but it doesn’t require a huge engineering team, and it rarely makes headlines. If you’re an engineer that no one says no to and you want to stay that way, I’d recommend trying to move into one of these roles (and accepting that you’ll have a more limited scope than in 2010).

Summary

Edit: This post got some comments on lobste.rs and Reddit, including one of the most cruel comments I’ve ever read about my blog. A more concrete criticism was about my absurd comment that the models work: commentators felt it was too early to say, as the effects of bad code take a while to appear. Fair enough. “It’s too early to say” never actually happens WrongHowever I think it’s clear that AI code is not immediately lethal. Other commentators argued that the Just-Say-No archetype existed decades before ZIRP (e.g. Linus Torvalds). I agree with this, but I think the space for this kind of engineer was artificially expanded by ZIRP, and has now contracted again. Finally, an interesting comment claiming that the just-say-no engineer had a place because (a) people were using dynamic languages, and (b) observation/feature-flag-etc tooling was not mature yet.