Fully agree. I think this is something that takes some time/experience to appreciate though. Junior engineers will spend countless hours writing pages of code that align with the “design patterns” or “best practices” of the day when there’s a simpler implementation of the code they’re writing. (I’m not saying this condescendingly—I was once a junior engineer who did that too!)

It’s impossible to know what “good” looks like when you’re new and haven’t seen a few codebases of varying quality and made some terrible mistakes

Most commonly, code should optimized into being easy to change.

That's almost entirely coincidental with being easy to read. But even easiness to read is a side effect.

I agree with this. Easy to change often means good tests too.

I worked in Perl. Yes it has a reputation for being hard to read, but that was not the problem. Our scripting was pretty basic and easy to read. It's the loose typing, the runtime evals, the lack of strict function parameters, no real IDE, “Only perl can parse Perl” - the fact you can load a module from a network share at runtime, import it, and call a function, based on a certain run flag - and so on. Refactoring was always a mine field and there was a lot I wanted to do in my old job but could not justify it due to the risk.

I think it's fair to say that between behavior and maintainability, one is inflexible and the other hangs from it in tension.

"Side effects" are not the same as "less important traits."

Side effects are usually unrelated or unwanted.