> But the code quality is speed

No it’s not. Code quality is just code quality. It's a subjective measure. eg how do you define one thing is of greater "quality" than another? Is it CPU ops? Memory footprint? Code readability? And how do you measure readability? By who? What I find readable someone else might not, and visa versa.

If you’re making choices to improve development throughput then that’s fine. But so often I see developers architecting code for what they mistakenly think will improve their throughput but ultimately they spend longer on writing those abstractions than any time they have saved when using them.

XKCD parodies this problem with their pass the salt sketch: https://xkcd.com/974/

Sometimes this comes down to developer vanity, sometimes it comes down to poor alignment of goals and/or communication between the product teams and development teams. And sometimes it’s just because solving problems is fun so naturally we’ll look for problems to solve. But whatever the reasons, I’ve personally seen this happen (as well as being a victim of it myself) enough times to know it is an underestimated problem.

> I find this very scary. Somebody unable to perceive capabilities and tech-debt. If you can not perceive that- you should not be let near executive decisions or code-base evaluation.

This is a rather insulting assumption. I've been a tech lead for around 2 decades now and have worked on plenty of brownfield projects in that time. I know what tech debt looks like.

The problem with "tech debt" is it can mean anything from "this is ugly code that takes 5 minutes longer to read but it works well" to "this in a insecure/unstable pile of horse manure and customers will start to notice".

The latter is where time should be spent. The former is a vanity project that doesn't bring the business any value.

That's not to say that developers shouldn't ever spend time on the former examples of tech debt, just that it's of a lower priority than getting the project working.

This is one of the reasons I got away from writing commercial software and now only write code as a hobby.

To me, the code itself is the product. I want the code to look like a beautiful painting—the fact that it does something for the user is secondary. I’ll sit there for hours working on things like const correctness, and making sure each class has the bare minimum amount of state/instance variables, even though it has no effect on user-visible bugs or runtime performance. I’m the kind of person that paints the back of the cabinet. Even though no user will see it, I will know it is there.

Obviously this mentality is at odds with commercial software’s imperative to shit out barely working spaghetti code as fast and cheaply as possible, so I opted out.

Thanks for saying this! I completely agree with everything you said!

There’s far, far too many people who confuse code quality for speed of development and start treating code quality as the product for customer base in the hundreds and active customers in the dozens and for most features to be basically unused.

The reality is that tech debt as a concept these days is hardly real: to be in debt means previous decisions or a previous implementation makes current work extremely hard or impossible, but, the truth is that the human factors such as knowing what to build, team collaboration and even speaking to customers matter far more and can get you “in debt” so so much faster than code alone. At least in your typical SaaS company.

If you ship code in a way that you let tech debt pile up to the point that customers notice it, you have an organisational problem, not code issues per se.

The fact that a lot of people don’t get this is really baffling to me.