Live data from Hacker News

The just-say-no engineer was a ZIRP phenomenon

seangoedecke.com

81–90 of 140 posts

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

#81
2022 coincided with a lot of things, such as the time period where R&D tax credits for US tech salaries were allowed to expire (reinstated in 2025)

it also coincided with rate hikes

it coincided with ChatGPT launch, which was incapable of replacing engineers at the time

it coincided with a tech bear market

it coincided with a crypto implosion and web3 bear market as well, which a variety of engineers were involved with or had asset exposure to

the R&D tax credit lapse I think was the biggest one, while the smallest headline. and therefore I think making a whole blog post about the rate hikes exclusively is grasping at straws

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

#82
post #58

Code is a liability. Saying no is because the engineer wants to reduce complexity, not because she/ he is so subjectively “obsessed” with code quality. The term “quality” is nowadays misunderstood by management. It means the right amount of effort to build the product as fast and for as low as cost possible, taking into account a team of engineers that can easily add and modify code. This description is the better on…

[flagged]

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.

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

#83
The "Just Say No" engineer is a person who knows what existing tools can do, while more junior people don't know what their tools can do. So junior people are constantly proposing new types of yak shaving (new architecture, new storage backend, new framework, etc) that must be done before solving the problem at hand. This is all wasted resources and time, even if LLMs let you shave yaks faster. A good JSNE focuses your resources on solving problems straight away, not pouring them all into a bottomless pit of busy work.

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

#84
post #56

> 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. The truth is the guardrails are being ignored in the frenzy. Style is winning over substance. I think if you revisit this hot tak…

That's what focus looks like to a just-say-yes engineer. They're just focused on shipping, not tinkering.

I reject the typology. Engineers are expected to do a lot of things, those things are different in different environments, and judgement is usually a key consideration. Pidgeonholing someone as a “type” of engineer can help with shallow comparisons but can’t predict behavior in all situations.

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

#85

Earlier quoted context omitted.

[flagged]

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.

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

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

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

#88
post #58

Code is a liability. Saying no is because the engineer wants to reduce complexity, not because she/ he is so subjectively “obsessed” with code quality. The term “quality” is nowadays misunderstood by management. It means the right amount of effort to build the product as fast and for as low as cost possible, taking into account a team of engineers that can easily add and modify code. This description is the better on…

"quality" isn't succinctly definable. Zen and the art of system maintenance quality code is written by an old and wise programmer and any attempt to rigidly codify what it is they did and why is doomed to fail.

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

#89
post #23
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.

If management values your opinion on business operations and forward strategy, then you are an advisor and should be remunerated as such.

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

#90
> 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?)

in some orgs it was a good excuse to cut the underperformers. these folks wouldnt deliver 10x value with AI, they would either deliver 0x or -10x (with contributions that the just say no engineer would have normally said no to)

Post reply on HN