The just-say-no engineer was a ZIRP phenomenon

[-]

mwobey@reddit

This entire article is built upon a mountain of false premises.

In this environment, having a very senior engineer whose only job is to say no to things was actually quite valuable to the company.

I would argue it is always valuable to a company to have quality review at all stages of the development pipeline, but in what magical unicorn company was this role ever valued. Even during the height of ZIRP we got slogans like "move fast and break things"; startup culture has always valued velocity to the exclusion of efficiency, maintainability, and scalability, so the just-say-no guy has always been fighting an uphill battle.

Worse still, the AI tooling mostly works.

...does it, though? If so, why are several high-profile open source projects talking about a tsunami of junk PRs and hallucinated bug reports coming from AI. Why is instability and shipping outright broken features at an all time high in many prominent AI-forward companies? (The multiple recent Windows updates that just delete your hard drive or brick your OS say hi.)

During the ZIRP era, tech companies did a lot more pure work (for instance, building React), and tended to treat even impure work like pure work.

Again, what magical companies were you working at oh noble author? Because what I saw was the opposite: even "pure work" greenfield development being treated like impure work, where the timeline was prioritized over setting a strong foundation to build on.

Also, all us "just-say-no" engineers can all tell that that first part of your summary section was cut-pasted in straight from an AI, and that the second half was an outline for additional content you were too lazy to write into actual paragraphs.

[-]

Iggyhopper@reddit

I always tell people who ask about how good AI is at code:

"You've seen AI generated photos with missing limbs or wrong fingers? Or videos where the cars are facing the wrong way, or the street disappears?"

"Yeah."

"Nothing has changed. The difference is the format."

[-]

dangerbird2@reddit

Difference is that AI code gets real-world feedback in a way AI "art" doesn't. It can hallucinate as much codeslop as it wants, but if it doesn't pass the test suite, build, and linters, it has to try again. Of course, AI won't do this (well) on it's own, so you need a basic understanding of software engineering and architecture best practices. But it's certainly not rocket science; it really only becomes a problem when you have people with no real world software experience start shipping vibecoded nonsense.

[-]

pavilionaire2022@reddit

Difference is that AI code gets real-world feedback in a way AI "art" doesn't. It can hallucinate as much codeslop as it wants, but if it doesn't pass the test suite, build, and linters, it has to try again.

Who writes the tests? AI.

[-]

PassTents@reddit

Much of the quality of any software project can't be verified with tests. There's infinitely many sequences of tokens that will pass build/lint/test but a much smaller set that would be considered by anyone to be readable or maintainable. When pressure comes from top-down to ship faster with AI code (and there's nobody to say no), even experienced developers start to turn a blind eye toward quality. I'm watching devs on my team right now lie, saying they've read the code in their own PR or, god forbid, run it. Maybe they skimmed the diff and it seemed "good enough". Pushing back in code review isn't popular, but increasingly feels necessary to keep the train on the tracks. Now every PR on an all-senior team has to be nitpicked like it was written by a junior. It's a mess.

[-]

jack-of-some@reddit

This is a needlessly narrow view that misunderstands both technologies at work. Further correctness can be defined for code. It can't be for art.

[-]

yojimbo_beta@reddit

Again, what magical companies were you working at oh noble author?

Sean Bullshitter is a staff engineer at GitHub. So perhaps we can infer the outcome of "just-say-yes"

[-]

onan@reddit

I would argue it is always valuable to a company to have quality review at all stages of the development pipeline, but in what magical unicorn company was this role ever valued.

I have seen it valued--indeed, treasured--at multiple companies.

Probably the most prominent of these was Google in 2000s, when SRE first coalesced as a discipline. Bogdan in particular was famous for saying no to almost everything, so much so that Google's private fork of the linux kernel included a /proc/bodgan that, when cat'd, would return a random string from a short list that was something like:

No.
Too risky.
No.
We already tried that.
No.
No.
Maybe.

But even aside from that particularly notable example, I have seen many engineers whose primary function was to say no to unwise things, and whom company leadership deeply valued for this. During some decades of my career I have been that engineer, so I can assure you from firsthand experience that it has been a thing.

[-]

truedima@reddit

> "move fast and break things"; startup culture has always valued velocity to the exclusion of efficiency, maintainability, and scalability, so the just-say-no guy has always been fighting an uphill battle.

In my experience, "the art" of staff-engineers and other tech leaders was to basically moderate the process of move fast, weighing in on whether we are moving fast into the right direction vs just creating fun debt. So, in reality it was never a pure "say-no" role, and more a "lets talk about what the value is, and what options we have to solve this vs what's presented" etc. And this was indeed valued in FANG-ish circles, where the ego of Product and VP people was separated out somewhat, but ofc always a bit at odds.

[-]

barvazduck@reddit

The just say no engineers existed since before the internet, even at times when interest rates were high. When software was distributed by discs (floppy/CD) updating was a huge pain so whatever was distributed had to be the final quality. This has lead to waterfall planning and many "just say no" engineers, testers and managers that pushed back any risk. They persisted all along gating mission critical projects no matter the economy, Linus Torvalds is famous for being one.

[-]

pietryna123@reddit

Well, personally I believe that OTA is among the top things that has reduced quality of the software delivered.

[-]

falconfetus8@reddit

OTA?

[-]

hiddenhare@reddit

I think it's been roughly net zero for the quality seen by users. Bugs show up much more often, but they're fixed much more quickly. There are irritating bugs in offline desktop software which I've been tolerating for years, just because I can't be bothered to hit the "update" button.

However, behind the scenes, rolling updates have been catastrophic for code quality. When a codebase is allowed to constantly deliver bugs, no market force will prevent it from becoming undisciplined and messy. Everything is a crumbling ruin, because when bits fall off, you can superglue them back on before most users notice.

At the risk of sounding like an old man, I'm genuinely concerned that this has been eroding the knowledge required to write maintainable software. Old-school enterprise software was overengineered to hell, but at least that came from a genuine effort to improve the craft. That energy seems to have leaked away; whenever I see somebody trying to fix things, their angle is usually "everything has become too complex, let's naively simplify it", rather than looking for new ways to organise essential complexity and eliminate incidental complexity.

[-]

barvazduck@reddit

The expectation from software is much higher than the past. The UI needs to be intuitive and sleek, it has to be multilingual, accessible, multi platform and work on drastically different screens (size/resolution).

These days most 80+ yr olds use software (through their phone), 20 years ago many avoided it. Most blue collar jobs have software as part of their daily work, not in the past.

There are horror stories of popular old software: sql injections, bad encryption, random number generators that return non random numbers (Excel), memory leaks, crashes, data loss. Putting old software on an imaginary pedistle is frutile.

I've worked on 30 year old codebases written by some of the best programmers around, their code surviving through all the requirement changes is a testament to their skills. Yet the same code would have been much better written today, it would have been more maintainable, debuggable, stable and often performant.

[-]

hiddenhare@reddit

I broadly agree, but I think most of those improvements have come from language, hardware, telemetry, library and platform improvements, especially the Web platform.

In terms of codebase health, we've badly deteriorated. We can make software which is startlingly high-quality, but within the first few years, its code will have rotted to the point that it can no longer be edited safely. Most five-year-old companies are burning enormous effort on rewriting software which they could have got right the first time - and then the rewrites rot, because they didn't fix the culture.

[-]

phillipcarter2@reddit

I think the reason it’s deteriorated (let’s assume that’s true) is what OP said though, expectations are far higher than they were two or more decades ago. When your userbase expects to interact across different form factors, be “always on”, have changes they make instantly reflected elsewhere, and have more features delivered quickly, there’s no way around the complexity. And it’s almost never a winning proposition to tell your customers that they don’t want what they want.

[-]

hiddenhare@reddit

Software which is not feature-rich has caught the same cultural disease. The Windows team is openly discussing its ongoing attempt to fix serious performance issues in Windows Explorer. Apple's recent roll-out of Liquid Glass was a buggy mess. Last month, a minor cosmetic change in Photoshop shipped many obvious UX bugs to production. Quality control is in freefall across the entire industry.

I've seen people blame this on AI, and I agree that AI might be throwing fuel on the fire, but I can trace this trajectory back for at least a decade.

[-]

hibikir_40k@reddit

It's a matter of rate of change, plus internal incentives. We all know that systems are most reliable around christmas, when most people are on vacation instead of committing breaking changes. The fact that so many companies are stack ranking with guaranteed PIPs just guarantees reckless behavior, as the people at actual risk try to close things fast enough to not be the one laid off, when they are the last people that should go fast if defect rates were seen as important.

As for incidental complexity... everyone says that the complexity they introduce is essential, and the one other people do is incidental. I've only seen that kind of analysis pushed by people using it as a disguise for "do things my way". It sounds nice, but the practical applications are minimal.

[-]

docgravel@reddit

Software used to ship mostly working, but if it was broken it would stay broken forever. If it was working it would work forever.

Now software ships mostly broken, but can be fixed but will eventually die and stay broken forever.

[-]

headykruger@reddit

It’s the top thing that increased security for users. Wild take

[-]

pickle9977@reddit

This is just so twisted and wrong it’s not even funny.

The just say no engineer as you described them is what is actually an engineer, one with a different perspective, the one that includes time and technical debt.

The just say yes engineer is a just an engineer that is too scared to ask why, which is the most important question any one should be asking when building anything, not to gate keep but to understand what you are building.

If you can’t answer the why you are not solving a problem, and if you are not solving a problem you are just wasting time.

And wasting time is what 99% of engineers do today, turning out a constant stream of features copied from anyone and everyone else in a vainglorious attempt to drive whatever metric the guy with the money concocted to measure their supposedly better mouse trap.

And it’s a better mouse trap because it’s got [new tech everyone is excited about], so it’s different and better, but it also does everything everyone else’s mousetrap does just slightly differently and it none of it really works, that all comes in version two.

And version two never comes because the just say yes engineers are too busy yelling at everyone that we need to swap out this new tech for that old tech so we don’t get left behind, the whole old tech is on the verge of being deprecated.

Meanwhile none of these systems works consistently, everything is ALWAYS breaking, even the biggest stuff fails constantly, AWS’ us-east-1 region can’t go a year without taking half the internet with it, and that’s the best availability anyone in that region can achieve, it’s all downhill from there.

We forget that systems are supposed to be available, stable and dependable.

All of which applied to things like communications networks, power grids, trading systems and transaction systems when we spent time to design, engineer and build our systems to have those properties.

[-]

MantisShrimp05@reddit

I guess this is something you could point to. But from my experience of doing it in non-tech, private company, I saw these same dynamics and continue to see them change.

I think management was always impatient and now that they can spew out a "prototype" with a tool they feel this sense of "that was eassy! What's taking you so long?" And have no sense that actual engineers have constraints they think through and mistakes to check for.

I think the only right answer to some degree is embrace the slop, let them see the outcomes of their actions and in the meantime dont let yourself get bullied to meet unrealistic deadlines. Now more than ever we have to remember we don't get profit from these systems we don't need to worry about the outages really.

Either this era ends when they realize this is dumb or you find a place that isn't crazy. Im not trying to be minimizing there may be a level where its legit better than sticking around an absolute dumpster fire.

[-]

airbornejim32@reddit

The real shift isn't ZIRP. It's that shipping bugs and fixing them later became culturally acceptable once everyone had high speed internet. You didn't need a senior engineer saying no because you could just patch it tomorrow. That eroded the whole discipline. Now we're surprised when nobody knows how to build stable systems anymore. The just say no engineer was a symptom of an era when you only got one shot. Now we get infinite shots and everything is always on fire.

[-]

lIIllIIlllIIllIIl@reddit

I've worked with some "always-say-no" engineers, and it was infuriating.

It's passivity and obliviousness disguised as wisdom. Whenever I would try to explain my reasoning and the tradeoffs I was making, they'd reply something cryptic like "It's just not how we want to do it" without actually pointing out the flaws in my approach or the benefits of an alternative approach. They just oppose stuff because they don't want to be held accountable and it gives them social points for appearing wise.

Perfect is the enemy of good. As engineers, our job is to make the right trade-offs to solve real problems. Our job is not to build a perfect piece of software nirvana; it is a goal we will never reach it. I'm not arguing for AI slop either, just for more nuance.

[-]

yojimbo_beta@reddit

Our job is not to build a perfect piece of software nirvana; it is a goal we will never reach it.

So here's my counter to that. When you look around and see

flagship operating systems full of bugs (Windows)
major outages becoming commonplace (GitHub)
increased bloat and adware (any website)

...is your takeaway that developers are saying no too much?

[-]

phillipcarter2@reddit

Yeah this was my experience with most in this archetype. Occasionally you get someone who actually does have a theory of why slowing down or stopping something now benefits us in the long run though, and they do tend to be worth listening to.

[-]

dr1fter@reddit

I was "just say yes" for most of the 15-or-whatever years of my big tech career. I came in young and didn't feel empowered to say no. Sure I had plenty of dissenting opinions with direction/product/strategy all along, but voicing them never once did me any favors. The features and fixes, people cared about. Besides, I've always been IMHO exceptionally fast to come up with & code a solution to some vague problem in a way that still evolves to accommodate future requirements... better just stick to the assignment and demonstrate how well I can execute. I'll warn if it's hard, and if it's impossible I'll push back; but if leadership wants me to grind on a hard problem anyways, at least no one could be too disappointed with the results I'd deliver. They're the ones who ultimately weigh the parameters I suggest, and they don't appreciate hearing too much lip, either.

And FWIW I subscribe to a "refactor as you go" strategy -- i.e. an intentional functional change should have obvious logic in an isolated CL, and if that's not possible, lead with some pure refactorings until it is. In my experience, if you have a supportive process/peers, applying that policy continually is usually enough to ensure maintainability, at least where it counts, without derailing the project in the name of more substantial/higher-risk "cleanup efforts" later (unless things are already really, terribly bad). I'd even go so far as to say that it's often a better use of time than upfront "planning." My idea of a "quick and dirty solution" still leaves the code better than I found it. I'm not doing harm by saying yes.

An old manager once told me to consult with a much-more-senior technical peer for mentorship, who explicitly advised me to "just say no." Fair point, in my more-important responsibilities I was constantly overburdened with interruptions by stakeholders who wanted to track progress on some detail of their pet project, yet no one ever actually cared that I did a great job on those things. I could've focused more on work that either absolutely needed to be done, or else at least looked really good. I believed it "wasn't my fault" if I was assigned a risky task that met neither of those criteria; he said it was, actually.

So I tried it a little, and probably benefited sometimes (but my codebase certainly didn't). In my peer's advice, he meant saying no to everything unnecessary -- no to features, no to fixes, no to cleanups. Just don't accept work onto your schedule unless it meets your personal standards, even if you know you could do a good job at it. It never really sat right with me as someone who wants a sense of "product ownership" -- I can always tell you why some technical task will be easy or hard, but I find it hard to say it can't be done when I know that I personally could do it, if I really had to (and so it's just "how bad do you want it?").

But I did eventually start getting bad performance reviews for not making an unwritten quota on the same kind of "incidental" contributions I used to crank out like 3x faster than my peers.

TLDR: you can't win. Or... I can't, I guess. "Blame the banks" is a new take I'd never considered.

[-]

omniuni@reddit

We need more "just say some" engineers.

Engineers that take apart the request and say "yes" to the parts that make sense, "no" to the parts that don't, and then propose the glue to keep it all together.

[-]

Twirrim@reddit

With the most effective senior engineers I know, who have an amazing track record of stopping stuff going ahead that really shouldn't, it's exactly this.

They learn how to balance their "no", when to push back, and what actually matters vs isn't such a big deal.

They also display a firm grasp of the XY problem. They don't tend to say no, so much as ask the right kind of "why?" questions to get a chance to redirect.

I would say one of the hardest things I find engineers struggle to grasp is that they're employed to help the business meet it's strategic goals. That's the entirety of your role. You might be hired to work on a thing, but that's only because that is what the business believes its strategy requires at that time, and it is your role to recognise both what you can do to align what you're working on with the strategic needs, or to recognise when it's no longer fit for purpose. You might have particular skills and expertise, but that's only useful for the company for the purposes of meeting its goals.

Sometimes the business strategy is going to be one you disagree with, like vibe coding everything. You can, and should, push back with your reasonable concerns, and try to help redirect the focus in more productive ways (for example, about half the reason I see love of vibe coding from leadership where I work is that they think it'll enable us to move faster, while they're failing to recognise that speed of coding isn't the problem there, it's everything but the coding.). Some of the most effective engineers pushing back on slop code are the ones that have worked directly with leadership, slop coding a solution to a problem of particular interest to them, and then involved them in the long process to bring something new to production.

[-]

gimpwiz@reddit

For sure. If we're employed by someone and paid to do things other than speculative and/or academic research, ie, 99.x% of us, our job is to improve the bottom line. Directly by increasing revenue or decreasing costs, or indirectly by improving efficiency or reducing risk or doing compliance, etc. There's a lot of craft and pride in the work but eventually what we're paid for is to ship solutions. Aligning your goals to business (or other organization) needs may not be fun or feel amazing but it's what feeds us, and it's effective.

Pushing back should usually be framed as being due to the idea or method not being beneficial to the organization's direction and mandate, rather than personal pique, ... even if that's the underlying reason; or due to ethical or legal concerns, if relevant. Saying you don't want to do something because it's butt-ugly doesn't sell to purse-string holders. Explaining that this butt-ugly solution will cost more in both the short and long term and cost the company more, and bring in less money, than doing it right, sells better.

And remember that if you're an employee, it's not really truly your problem unless it affects you. Management all in on vibe coding and they don't care what you say? Fuck it. Vibe code that shit up. Half-ass it. Go home, play with your kids, brush up your resume and interview around. They want you to vibe code it and also fix all the issues? Give it an honest try to see if it can be done better. It can't? Don't stay at work late because they fucked it up. Tell them: Don't have enough resources; technical issues too many; let management figure out how to deal with that. Shrug.

[-]

vips7L@reddit

and to ensure that as little code gets written as possible (since code is a liability).

It's crazy that we've forgotten this in the age of slop.

[-]

ub3rh4x0rz@reddit

Not even remotely a good take. If anything, AI adoption is reducing the impulse to say no, for the wrong reasons. The reasons to say no are getting more nuanced and executives haven't been spoon fed updated guides on what reasons for "no" they should be sensitive to yet.

[-]

hiddenhare@reddit

The author's theory is that, when tech startups lost access to much of their investment income, leaders of tech startups became less willing to listen to the type of senior engineer who prevents unnecessary work. Yesterday's cash-rich startups hired too many engineers, gave them too much freedom, and relied on these seniors to limit the damage; today's cash-poor startups are starved of engineering time, so the leaders are running a tighter ship, and they don't appreciate the senior engineer who says "no" to direct requests from management.

Couldn't we tell the exact opposite story, though? When engineering becomes more expensive, I'd expect tech leaders to become more spendthrift. Juniors with big dreams haven't gone anywhere, so the senior who tells them "please stop micro-optimising this internal CRUD app which has ten users" should be more useful than ever.

[-]

phillipcarter2@reddit

This isn’t tech startups though. The biggest tech companies played even more financial tricks in ZIRP because money was so cheap, and much of the covid over-hiring came from them.

[-]

truedima@reddit

For leadership to become more "thrifty" in the right way they'd have to have been good engineers previously. 95% of the time they are not, so they become thrifty in the way of "move faster, reduce quality, it hasn't harmed us" and then pile dealing with the fallout onto the formerly "liked" "say-no-engineer" (still often the most sensible person in the room, hopefully), but now he's getting an existential depression and looks for ways to go and farm goats or start a microbatch brewery.

[-]

gjosifov@reddit

It is quite opposite
ZIRP produces more software, because big tech promoted based on what you build
that is why every 2-3 months there was new JS framework with MIT licences (I don't care licence) and this was confirm by the ex-tech lead, ex-*
it was also confirm from George Hotz when he went to work for twitter for 3-4 months

as a matter of fact - nobody is rewarding maintaining a software, improvements in performance, availability, readability, reliability or proper documentation of a software

I know only that only the JDK team and the windows team in the whole IT industry has perfect record for backward compatibility from which the JDK team has step-by-step guide on how to create your own Java, maybe there are other software teams and they need more exposure

and the result of this is - the software is so bad that even normal, no-coding people are noticing

there isn't such thing as just say no engineer, but there a lot of people in IT who don't understand computers or have any idea on how to build software and a lot of them don't know how to build a PC on a budget - they just buy laptops

[-]

cran@reddit

That whole article is full of made-up nonsense.

[-]

xiaopewpew@reddit

wow, so I need to blame the interest rate environment? i have always thought I say no a lot because im a lazy bum.

[-]

AmoebaDue6638@reddit

The real problem was never saying no, it was that ZIRP let you say no without consequences. Now every pushback needs receipts.

[-]

decoderwheel@reddit

The source article this blog is based on is nonsense, because the author of *that* article needs to watch "Simple Made Easy". They do *not* understand where complexity comes from in software development. So, not a good start.

I know both the "just-say-no" or "just-say-yes" archetypes by another phrase: "not very good at their jobs". As a senior, your job is to walk the tightrope between those two instincts, and bring everyone along with you. To be the person who says "let's run this experiment" but also, "no, we don't need a queue in this solution" and "everyone's feeling a bit nervous about this, what's the smallest version of this we could attempt quickly?"

[-]

MoreRespectForQA@reddit

Im usually loath to chalk up to AI what can be adequately explained by ZIRP and people do it way too much but I really think that in this case the author is for once making the mistake in reverse.

[-]

hu6Bi5To@reddit

I'm seeing this play-out in real-time.

Half the teams where I work have got the message and are all "we added $$$,$$$ value this iteration". The other teams haven't, and are all "we need to decide whether semi-colons are allowed in PR descriptions or not".

Try as I might to appeal to the better nature of both to not be quite so eager to poison the communal well, it's not getting me anywhere. Both see me as an agent of The Other Side and not to be trusted.

[-]

stagedgames@reddit

I feel like in addition to the end of ZIRP, there's a growing desire to deprofessionalize most career paths, and the boot camp culture of the last decade only served to accelerate and encourage that. It's not just engineering, in our lifetime we've seen teachers be deprofessionalized, and its currently impacting CS, nursing, veterinary clinics, and probably many more fields. It's genuinely concerning because that tends to be a death knell for the quality of life for that profession and the quality of output for the industries that profession serves.

[-]

UXUIDD@reddit

well i did it much to many times and made me not too popular, and as early as pre-responsive layouts.

".. move this logo more to the right, make it bigger and more red.. " -

Well im not gonna do that as it make no sense, i design too

[-]

radozok@reddit (OP)

[-]

beebeeep@reddit

Just-say-I-told-you-so engineer