Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The just-say-no engineer was a ZIRP phenomenon

seangoedecke.com

Post reply on HN
Print view View original

91–100 of 140 posts

Re: The just-say-no engineer was a ZIRP phenomenon

#91

Post by loeg »

shermantanktop wrote: post #40
loeg wrote: post #2

> 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.

Those stories were fanciful at the time, too.

Re: The just-say-no engineer was a ZIRP phenomenon

#92

Post by nomilk »

gmueckl wrote: post #86
nomilk wrote: post #30

> 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 (a…

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.

Re: The just-say-no engineer was a ZIRP phenomenon

#93

Post by frevib »

sevenzero wrote: post #80
simianwords wrote: post #67

Earlier quoted context omitted.

[flagged]

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.

Re: The just-say-no engineer was a ZIRP phenomenon

#94

Post by andwur »

thrownthatway wrote: post #85
Toutouxc wrote: post #82

Earlier quoted context omitted.

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.

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.

Re: The just-say-no engineer was a ZIRP phenomenon

#95

Post by rTX5CMRXIfFG »

> … 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.

Re: The just-say-no engineer was a ZIRP phenomenon

#97

Post by praptak »

layer8 wrote: post #23
praptak wrote: post #13

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...

Re: The just-say-no engineer was a ZIRP phenomenon

#98

Post by grodriguez100 »

> 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.

Re: The just-say-no engineer was a ZIRP phenomenon

#99

Post by pyvpx »

thrownthatway wrote: post #85
Toutouxc wrote: post #82

Earlier quoted context omitted.

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.

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

Re: The just-say-no engineer was a ZIRP phenomenon

#100

Post by Toutouxc »

thrownthatway wrote: post #85
Toutouxc wrote: post #82

Earlier quoted context omitted.

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.

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).

Post reply on HN