[brunooliv]

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.

[21asdffdsa12]

Im talking about the speed of mental model building, understanding concepts, relations and organizational concepts.

Good codebases sort of read themselves. You can guess where things are, how they are sorted and how they work, by understanding and relying on the authors ideas.

[hnlmorg]

“Good” code makes trade offs. While readability is an important constraint, it’s far from being the only constraint. And there are plenty of occasions where objectively better code is subjectively harder to read because other constraints trump human parserability, such as using CPU-friendly memory layouts, SIMD-instructions in tight mathematical loops, and so on and so forth.

Not to mention that readability is entirely dependent on the readers familiarity with particular coding styles. Eg someone unfamiliar with SQL would find ORMs easier to read, whereas I find SQL easier than ORMs. Same is true for any other paradigm, eg for functional vs imperative.

And this is why I hate when people generalise about human readability being the definition of “good code”. For one thing, there will never be a consensus on what is more readable. And external constraints might require subjectively less readable code.