Live data from Hacker News

The just-say-no engineer was a ZIRP phenomenon

seangoedecke.com

131–140 of 140 posts

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

#132
post #92
post #86

Earlier quoted context omitted.

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.

If there us a 99% chance if faulure, the rational response is no unless the rewards are absolutely, insanely huge (at least about 200x the cost of every resource used) and the org can take the failure.

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

#133
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…

And in the agentic world, that liability is both minimized and amplified. Teams that successfully mitigate AI risks will be able to churn out massive amounts of sustainable code.

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

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

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.

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

#136

Earlier quoted context omitted.

I think the "just say no" engineers were massively sidelined during ZIRP Actually I suspect they are just massively sidelined in software in general because of how few regulations exist The "just say no" engineer is someone who thrives in regulated environments, because (enforced) regulations are the only things that actually slow down the growth at all costs minded PMs in the world. And even then only sometimes

I think that's it. LLMs infected companies with the Rage Virus and now they're running mindlessly at anything that moves. A "just say no" engineer has no air in such an environment. It is FOMO of the most diffuse kind, with absolutely nobody knowing what the what is we're missing, but everybody (and that includes myself) knows something is going to change. We like to dress up in suits, but we're all apes afraid of sh…

Personally I'm an ape afraid of being left to starve now that they have invented a mecha ape that can hunt more food faster than I can, and won't leave any food left for me.

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

#137
post #26

Earlier quoted context omitted.

The current market absolutely is much more like 2011 than 2021. If you were working in tech back then, it was easy to raise money for specific types of startup (social was the thing back then like AI is today) but it was nothing like 2021. You could raise money for a ham sandwich in 2021. The ZIRPmania of 2021 was certainly dependent upon what came before it but it wasn’t a natural outcome, it needed the economic cha…

No Exit , written in 2014, recounts that infamous time a team (trio?) of founders were funded before they had a business idea.

That's been YC's modus operandi since long before 2014. Reddit, from the first YC batch, came about because Paul said (paraphrasing) "I like you kids but your idea sucks, forget about it and you can join YC". Nothing to do with ZIRP.

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

#138
I have this graph I like to show with "risk to company posed by changes" and "benefit to company posed by changes" on the y axis and "company entrenchment" on the x axis. The "benefit" graph starts out nearly vertical but quickly levels off. The "risk" is the inverse, starts off horizontal but quickly ramps up to infinity.

So I think that ZIRP has little effect on the "just say no" phenomenon, that's more about company size.

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

#139

Earlier quoted context omitted.

indeed sweeping industry-wide conclusions are often drawn upon technology. however these generally apply to web/apps only. for example, in this thread we have someone extolling the virtues of not reviewing code. this is probably correct in the context of web/apps, but doesn't hold true otherwise. similarly the linked article talks about the frustration of being forced to merge known bad code - acceptable behaviour wh…

That's also just as untrue. Why wouldn't most B2B services outside of SV be web-based? There's a much bigger and broader economic world out there than HN usually discusses these past few years. We used to hear more about it before LLMs flooded the front page.

my point was a lateral move from yours, I didn't intend to associate business outside of SV with non web based business

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

#140
post #73
post #54

Earlier quoted context omitted.

The CEO of Shopify is filing PRs against their public repos: https://github.com/Shopify/liquid/pull/2056 (To be fair, he did build liquid and much of Shopify himself at the start of the company so he's not exactly inexperienced, but still.)

I skimmed that PR briefly and it appears a) not to be slop and b) to be very reviewable as its structured as a series of small commits that each make one small change. This is far from the sort of management PR I'd fear.

Am I going crazy? Is a PR with 94 commits that adds 1,600 LoC actually considered "very reviewable"? Please someone tell me if I'm crazy?
Post reply on HN