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

21–30 of 140 posts

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

#21

Post by d--b »

Good article.

People don’t realize the breadth of the impact of the low rates and quantitative easing policies.

This stuff clearly helped navigate the 2008 crisis. But the cost is huge: bubbles everywhere, inequalities through the roof, spiralling government debt.

And while the interest rates have gone up, bank reserves are still nowhere near their pre-2008 levels.

Unfortunately, the way the monetary system works is quite difficult to understand, and is unlikely to ever enter the political debate.

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

#22

Post by RHSeeger »

breckenedge wrote: post #10

I agree with this take for experienced and capable engineering teams. Three times over the last three years, I have told my senior engineers to skip code review, and nothing catastrophic happened, and recovery from bugs was rapid. Three times I have been told by engineering management to reimplement code review. Now that management is either gone or about to be gone.

Skipping code reviews and the bugs it causes can be a problem, or it can be easily solvable later when the bugs are found. It varies a lot.

Skipping code reviews and the poor code that can happen because nobody took a second look - that's more of a problem. Because 6-12 months down the line, there's not a few bugs that need to be fixed. Instead, there's a horrible code base that causes all _future_ development to be a lot slower.

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

#23

Post by layer8 »

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.

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

#26

Post by fontain »

Apocryphon wrote: post #14
fontain wrote: post #11

ZIRP was 2008 to 2022? The 2010s were calm and collected, zirp-mania gripped us through the pandemic. You cannot compare 2011 and 2021. Totally different environments.

2021 was the apotheosis of 2011. I'm sure hundreds of examples on this site chronicle how wild and not quite calm nor collected it was, but I liked No Exit by Gideon Lewis-Kraus. (The original WIRED article is paywalled, so here's a specific sub-thread started by tptacek from its discussion: https://news.ycombinator.com/item?id=7644161 ) Whatever you want to say the current market is, it's nothing like the early 2010…

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 chaos of the pandemic, it would not have happened without the pandemic.

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

#27

Post by layer8 »

j2kun wrote: post #24

The hypothesis that companies today need to really focus so they can make money ignores the fact that, in fact, most or the major AI companies are not making money relative to their costs.

The article is weird, but I wouldn’t take the major AI companies as being representative of companies in general.

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

#30

Post by nomilk »

> 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 (and corresponding prioritisation of MTTR over MTBF).

I'm definitely a 'just-say-yes' with the caveat that bad architectural choices can be super painful to fix later, and features become a lot harder to fix when they have users as opposed to before launch (so I'm a little bit 'just-say-no', or at least 'just-think-for-a-bit-first').

I also think the balance between 'just-say-yes' and 'just-say-no' really depends a lot on the project. If it's finance or healthcare, perhaps 'no' by default is best. But if it's a silly startup idea, YOLO.

Post reply on HN