Sometimes when developers talk about code. You will find that some people may say "code quality doesn't matter" or even "quality is subjective". First I want to example why people land here, why I think its likely the wrong way to think of code, and that there are some basic principals of software that's objectively good or bad.

I want to make an very important distinction between "quality code" and "clean code". The term clean code gets tossed around a lot. And since it is the title of a very popular book, there is a connotation associated with the term. Let's be very honest. "Clean code" is more of a preferred coding style where the expected side effects are suppose to be maintainable code. Notice I said "maintainable" and not "readable".

So what is quality code? Simple. It is code that has clarity, less congitive overhead, and can be reasoned about. Cognitive load is objective. If I need to hold more code concepts in my head, or I'm tracking functions/variable names across many files in the project. This is more of a cognitive load than just reading something from top to bottom. This isn't always possible to just have everything locally in one file, but the less jumping around the better. This is why I feel quality code tries to reduce indirection.

Clean code is about code organization. But that "organization" comes at a cost in that it forces indirection. Which we know is cognitively expensive. So what clean code hopes to achieve is "code adjustments without needing to understand the broader code base". You just modify a interface, and then system "takes care of it". But this is only the byproduct of ultra ultra mature software. I feel a software industry that is all about narrower, software never reaches maturity like it do 20-30 years ago. Hence clean code applied to teams with no real discipline just feel like over-engineering.

I think quality code is understanding an entire code base. And understanding an entire code base requires reasoning about it not to be cognitively expensive. This also means the code can be modified, and you are able to understand the side effects based on your knowledge of the code base. So it requires thoughtfully managing complexity. But you don't manage it until the complexity becomes so overwhelming. Managing complexity is only through emerging behavior and architecture. Not something you impose on a code base from the top down.

The friction of code quality will always come from adding new features. Code quality is very important in these scenarios. Because the longer a system runs, the more aggressive business teams are about pushing features and deadlines. And when you need to reason about a poorly construct code base, code adjustments feel risky. They also take more time because they become harder to test and debug. So quality code is code that is simple as the system allows it to be. Simplicity is used a lot, but not all systems can be incredibly simple. That is why I say "as simple as the system allows". And that balance is hard, but necessary to not only deliver faster, but not cause latent and hidden bugs in your software.