[kyshoc]

To split this hair a bit, I think “code quality” has two definitions:

1. the degree to which the code can be trusted to operate correctly and in a fault-tolerant way (i.e. “yeah that API endpoint will give you a 5xx about 2% of the time, sorry about that, just retry!”)

2. the degree to which the code optimally models the problem it’s solving, as well as how flexible it is as priors/needs change in the future and whether optimal languages/frameworks/patterns are used to solve the problem expressively.

The former has obvious customer implications — if your webapp craps out every ~20min of usage, or your API silently drops data when it can’t persist something to a data store, that’s bad, you will lose customers (and you deserve to!). Conversely, lacking in the latter could slow you down as you iterate, but you’re just as likely to not need to touch that code for a while if you’re off building new views/features/what-have-you.

I think the “don’t worry about code quality” folks are generally trying to beat it into technical founders/builders’ heads that the thing they’re building is ultimately being judged as a product, not as an engineering project... but that doesn’t mean that reliability and performance aren’t part of what may make your product valuable.

[JamesBarney]

To expand on something you hinted at. I think it's a very important insight to realize that your code base doesn't have to be homogenous, and you can make different trade offs in different parts of the app.

If you have an accounting app for instance, if it crashes every once in a while users will accept that. If it calculates your taxes incorrectly leading to an IRS audit, that is unacceptable and an existential threat to your company.

In that scenario UI could be messy but your tax crunching code has to be the cleanest and best tested code you can write.

[girvo]

Of course the latter can lead into the former, and now you have two problems!