Or maybe “code quality” really means how visually pleasing the code is, or maybe it means it takes up the least amount of disk space, or what if it means code that doesn’t use the letter ‘e’?

This is why the pursuit of “high quality code” is pointless; you are not an artist, you are aligned to solve a problem. If you do that, code or not, you are doing good work as an engineer. If you are not, you are not. Whether the code fits some arbitrary definition of “good” separate from your ability to solve a problem doesn’t play into it.

You refuse to define the problem in a comprehensive way in the first place. That's the meta-problem :)

The second issue is that you think it is impossible to define an "abstract good" in code quality given a specific context (team, product, market). The "abstract good" stems on its own for the given internal culture and market situation. Through some common sense examples, it is easy to see how "abstract good" wields influence on "practical parameters" critical to business survival/thriving.

As an analogy, I can say the "body is healthy". I am aggregating a bunch of metrics to say - "this is healthy". It doesn't mean the term "healthy" is meaningless. The term "healthy" has useful meaning although not at a mathematically precise level. One could even argue that the term "healthy" captures something even precise mathematics cannot capture (it's abstracted at a higher level). Apply similar argument to the term "code quality".

Edit: Maybe it is better to explore the idea of code quality "via-negativa". Find what's actively harming beneficial outcomes. And remove it. If you cannot find many harmful things, then it has high code quality.

You’re falling for the trap I’m suggesting you avoid. Stop caring about platonic ideals of what Good Code ought to be, and start focusing on how well the code solves the problems it was built to solve.

You can call that good code if you want, but my argument is to stop caring about the code’s “quality”, as a value it carries independent of the problem.

It's not platonic, my argument is empiric.

The physician - operates "via negativa". He tries to find faults with the given body, tries his best, and when can't find - he calls it "healthy".

The engineer/businessman can look at the code from an empirical point of view.

If onboarding is bad -> code is bad

If understandability is bad -> code is bad

If deployment is bad -> code is bad

And so on. As you eliminate these issues, your "code quality" increases (just like as you eliminate disease, the body becomes more healthy).

Look into say, Taiichi Ohno's Toyota Production Management - one associates "zero defect" ~= "quality". So, the term quality alludes to a continuous elimination of faults and shortcomings.

The aggregate placeholder/banner term 'code quality' stems from very firm practical sources, that can be inspected, amended and improved.

Sure, but you are in agreement with what I’m saying; good code implies specificity towards the line-by-line writing and structuring of the language (that’s what “code” is, more or less), and I argue that’s useless, as do you here by citing examples of how the code solves the larger problem in the system.