121–130 of 140 posts
Good engineers will say yes and no thoughtfully and will adjust to the new reality anyway. So it feels kind of pointless since no one is really a just say yes or just say no person, though it is well written.
There's no reason for engineers to be under more pressure to accept technical debt (which is what we're really talking about with the yes-or-no framing) after the end of ZIRP. Quite the opposite: right now debt is expensive and programmers are cheap, it's a good time to have high quality standards and build robust infrastructure that will position you to catch the next growth wave. It really is AI (or rather AI hype)…
>Quite the opposite: right now debt is expensive and programmers are cheap, it's a good time to have high quality standards and build robust infrastructure that will position you to catch the next growth wave. Uhm, no? You got it exactly backwards. Tech debt isn't the same as interest payments, tech debt is a future productivity decline, whereas interest payments require you to pay more than the initial money you bor…
Another way to look at it is to say that like any analogy applied to software development it is weak. It is not like normal debt at all because you must start paying back immediately one way or another. So you can't just pile hack on hack and wait for a year to pay back. You will start having to pay back for the hacks within a couple of months because of the bugs you have to fix and how hard it is to work with the messy codebase. In some cases you may even grind to a halt before you get anything substantial out to the customer. This doesn't mean that you should never hack stuff in. But in general it's cheaper to pay off the debt quickly instead of paying for the debt.
LLMs aside, being able to say no is important when resources are scarce
There's no reason for engineers to be under more pressure to accept technical debt (which is what we're really talking about with the yes-or-no framing) after the end of ZIRP. Quite the opposite: right now debt is expensive and programmers are cheap, it's a good time to have high quality standards and build robust infrastructure that will position you to catch the next growth wave. It really is AI (or rather AI hype)…
>Quite the opposite: right now debt is expensive and programmers are cheap, it's a good time to have high quality standards and build robust infrastructure that will position you to catch the next growth wave. Uhm, no? You got it exactly backwards. Tech debt isn't the same as interest payments, tech debt is a future productivity decline, whereas interest payments require you to pay more than the initial money you bor…
A no that turns into a yes is the best kind of no.
I feel like the article is pretty contradictory. Apparently ZIRP was the era of abundance and of codebases growing rapidly and: > with so many engineers running wild, how would they keep their systems from becoming completely unmanageable? Enter the just-say-no engineer. So before "AI", the just-say-no engineer was a vital part of the system who was preventing it from getting overrun by (human-generated) slop. Good.…
So if your goal is to deliver as much features as possible - regardless of the quality or roi - gatekeepers are an obstacle to remove.
I've seen the "just say no" thing institutionalized through SRE, where they can use the "banhammer" to stop the deployment of new features or whatever hasn't passed their various "reliability checklists" and such (if they're responsible for on-call) I'm sure this won't be popular but a lot of "SRE" teams were definitely ZIRP phenomenon, heh.
Would you want to be on call for someone else's garbage though? There's a very obvious and real tension here.
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]
Because I think in most regular situations, code-without-adjectives, uncertain commits, or any number of things might be rightfully justified as a literal legal liability for business cases.
I get that you don't like how flat it is, but on a business website, in a world forecasted to be full of black box code, the statement is correct.
Code in a vacuum may not be a personal liability, but it is a professional one in 2026 where there's a gulf between slop and secure code
This is trivially incorrect outside of SV. There are plenty of slow moving projects that focus on the stability of the codebase if you work for a business that isn't a "tech company" and work on services instead of products.
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…
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.