I think you're missing the author's thesis

  > Is speed the greatest virtue?

If speed is the greatest virtue then yeah, all that stuff will happen. But if it isn't, then that stuff will happen at a much lower frequency. Because, all the stuff mentioned is just tech debt. Debt doesn't go away, it accrues interest.

If speed is all that matters then you need exponential output, as your output needs to offset the debt. If speed is a factor but isn't the only factor, then you need to weigh it against the other things. Take on debt wisely and pay it off when you can. But it does seem like there's a trend to just take on as much debt and hope for the best. Last I checked, most people aren't really good at handling debt.

▲ lbriner 5 days ago | parent [-]

I think you are misusing the phrase "tech debt" like many people do.

Not everything that is not perfect is Tech Debt, some of it is just pragmatism. If you end up with two methods doing the same thing, who cares? As long as they are both correct, they cost nothing, might never need any maintenance attention and will never be paid down before the codebase is replaced in 10 years time.

Same with people writing code in a different style to others. If it is unreadable, that isn't tech debt either, it's just a lack of process or lack of someone following the process. Shouldn't be merged = no tech debt.

Adding some code to check edge cases that are already handled elsewhere. Again, who cares? If the code make it unreadable, delete it if you know it isn't needed, it only took 10 seconds to generate. If it stays in place and is understandable, it's not tech debt. Again, not going to pay it down, it doesn't cost anything and worse case is you change one validation and not the other and a test fails, shouldn't take long to find the problem.

Tech debt is specifically borrowing against the right way to do something in order to speed up delivery but knowing that either the code will need updating later to cope with future requirements or that it is definitely not done in a reliable/performant/safe way and almost certainly will need visiting again.

	▲	darkwater 5 days ago \| parent \| next [-]
		> Tech debt is specifically borrowing against the right way to do something in order to speed up delivery but knowing that either the code will need updating later to cope with future requirements or that it is definitely not done in a reliable/performant/safe way and almost certainly will need visiting again. Thing that many people do without even realizing they are incurring in tech debt. This kind of developers are the one that will just generate more tech debt with an LLM in their hands (at least now).
	▲	whilenot-dev 5 days ago \| parent \| prev \| next [-]
		Code that demands to pay off its dept isn't non-working code, it's rather code that exceeds one's ability to maintain it properly (your mention of "unreadability" included). Whether a PR introduces debt isn't always known and often times has to be discovered later on, depending on how fast its maintainers fluctuate and the ecosystem advances. That said, tech debt isn't paid by developers individually, it's paid by organizations in developers time. Only in rare cases can you make a deliberate decision for it, as it grows organically within any project. For example, most python2 code today that used niche libraries with outdated docs that have been taken offline in the meantime has to be considered expensive tech debt nowadays.
	▲	godelski 5 days ago \| parent \| prev [-]
		I'm a bit confused because you start by disagreeing with me but then end up agreeing with me. `> If you end up with two methods doing the same thing, who cares? As long as they are both correct, they cost nothing` To be clear, tech debt isn't "code that doesn't run". It's, like you later say "borrowing against the right way to do something in order to speed up delivery", which is what I said the authors thesis was. No need for perfection. Perfection doesn't exist in code. The environment is constantly moving, so all code needs to eventually be maintained. But I also want to be very very clear here. Just because two functions have the same output doesn't mean that they're the same and no one should care. I'll reference Knuth's premature optimization here. You grab a profiler and find the bottleneck in the code and it's written with a function that's O(n^3) but can be written in O(n log n). Who cares? The customer cares. Or maybe your manager who's budgeting that AWS bill does. You're right that they're both logically "correct" but it's not what you want in your code. Similarly, code that is held together with spaghetti and duct tape is tech debt. It runs. It gives the correct output. But it is brittle, hard to figure out what it does (in context), and will likely rot. "There's nothing more permanent than a temporary fix that works ", as the saying goes. I guess I'll also include the saying "why is there never time to do things right but there's always time to do things twice?" Code can be broken in many ways. Both of those situations have real costs. Costs in terms of both time and money. It's naïve to think that the only way code can be broken is by not passing tests. It's naïve to think you've tested everything that needs to be tested. Idk about you, but when I code I learn more about the problem, often with the design changing. Most people I know code this way. Which is why it is always good to write flexible code, because the only thing you can rely on with high confidence is that it's going to change