Don’t be an engineer who says “no” with zero alternative solutions. That’s not being a good engineer, it’s being lazy and trying to look good. Often times an engineer will put forth a solution that’s non-ideal due to legacy reasons, but required nonetheless. And no they can’t rewrite the entire system to “do it the right way”. You're not being some super high IQ genius by saying “no” or pointing out the solution is non-ideal.
The just-say-no engineer was a ZIRP phenomenon
101–110 of 140 posts
Re: The just-say-no engineer was a ZIRP phenomenon
#102Earlier quoted context omitted.
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…
Yep, that was pretty much the point of my comment.
Code is a liability - yes with an and / no with a but.
I’m sure volumes have been written amount, and there’s roughly an infinite amount of nuance to be talked about over a few drinks and a smoke.
Re: The just-say-no engineer was a ZIRP phenomenon
#103Sorry: is there any evidence for the proposition that staffing was excessive, or that it was ZIRP that led to excessive staffing? The idea is plausible, but was it actual?
Second, is there any evidence for more or less gatekeeping?
Or evidence that there were relatively more "pure-engineering" projects? (Though one would expect that for the new technologies and markets. The green fields migrated from scale to data science and AI.)
Finally, wouldn't more gatekeeping be required when AI reduces the cost of making concrete tech proposals?
This seems not connected to facts or compelling in theory, but it does touch on anecdotal and emotional truths. I believe the writer could do better. (More, I believe HN readers should insist on writers doing better, to raise quality and offer harder challenges to people.)
Re: The just-say-no engineer was a ZIRP phenomenon
#104Earlier quoted context omitted.
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 cha…
No Exit, written in 2014, recounts that infamous time a team (trio?) of founders were funded before they had a business idea.
Re: The just-say-no engineer was a ZIRP phenomenon
#105Don’t be an engineer who says “no” with zero alternative solutions. That’s not being a good engineer, it’s being lazy and trying to look good. Often times an engineer will put forth a solution that’s non-ideal due to legacy reasons, but required nonetheless. And no they can’t rewrite the entire system to “do it the right way”. You're not being some super high IQ genius by saying “no” or pointing out the solution is n…
I remember this exact software dev manager. She knew the system well. She became a manager. She started saying no to many PMs and other devs. In meetings with business people, she was a bully because she knew how to code. The worst was that she offered no alternative when she didn’t agree with the proposal. She was difficult to work with.
I wonder if she is the same ZIRP person this article is talking about.
Re: The just-say-no engineer was a ZIRP phenomenon
#106Earlier 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.
Production code is an asset, its maintenance and obligations are an expense, its risks might become liabilities, and companies shouldn't run more code than they need for the same reason they shouldn't own a larger vehicle fleet or more spare warehouse capacity than they need.
I don't think most engineers really disagree with this. Saying code is a liability is technically incorrect but pithy shorthand to communicate that it comes with the associated baggage of maintenance, obligation, and risk; these things suck up money the same way a liability does. Tech debt is also not real debt. It's a figure of speech.
Re: The just-say-no engineer was a ZIRP phenomenon
#107Earlier quoted context omitted.
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.
That's a bit silly. Presumably you wanted to deny competitors use of these engineers, because they would build something useful. Just have them build that stuff for you instead? And if competitors were in the same boat, why bother hiring these people at all?
>And if competitors were in the same boat, why bother hiring these people at all?
Suppose an established org (N) got disrupted by a startup (N+1) because the startup was able to do things faster and cheaper. Once the startup becomes the established org themselves and slows down a bit, they are exposed to the same risk, unless they hire all the smart people (who would otherwise be hired by N+2 startup) and buy out all the N+2 companies who actually managed to do something despite having less money. Eventually it becomes too expensive and there is a good excuse to fire all those people. I don't think it's 100% of what is happening, but it could be.
Re: The just-say-no engineer was a ZIRP phenomenon
#108Code 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]
Please don't cross into personal attack on HN. You can make your substantive points without that.
https://news.ycombinator.com/newsguidelines.html
p.s. We've had to ask you this before: https://news.ycombinator.com/item?id=47103856. If you'd please review the guidelines and take the intended spirit of the site to heart, we'd be grateful.
Re: The just-say-no engineer was a ZIRP phenomenon
#109The article's logic doesn't hold up. The OP argues that "no-engineers" were valuable during ZIRP because companies were over-hiring and adding too much code but that's exactly the situation we're in now with AI. If anything, the analogy strengthens the case for them.
The OP even acknowledges this:
> Ironically, if ZIRP had not ended, this would be a glorious moment for the just-say-no engineers.
But then never explains what ZIRP actually has to do with it. Why does the end of ZIRP change anything?
Re: The just-say-no engineer was a ZIRP phenomenon
#110The 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 see it similarly. Companies have varying time preferences over short-term success vs. long-term success.