[madsbuch]

Exactly my thoughts.

The reason why good code is code that is easy to read, is because products evolve, and so does the code.

Suddenly the taxonomy of that enum starts to shift, and the name that was perfect yesterday does not make sense tomorrow.

These changes happen gradually and a basic acceptance of the code base not being on par with the product understanding is necessary in order to have any kind of velocity on not only spend time refactoring.

[m463]

I disagree.

"good code is easy to read" - that does not work.

I can write a bubble sort instead of quicksort and that code will be bad.

Maybe you can do the same thing with privacy policies. Most complicated privacy policies are bad, so they make them hard to read so that people do NOT understand them and give up.

But you could have a privacy policy that is bad and easy to read. "We can do anything".

I think good code is primarily easy to read. And I think it should not attract attention through bad behavior, so it should additionally not come under scrutiny for that.

[madsbuch]

Of course your code should live up to requirements and be correct, for it to be good - The requirements can also be performance requirements.

If you have a list of maximally 10 elements that needs to be sorted and you opt for quicksort over bubble sort in a context where bubble sorts time/space guarantees perfectly solved the requirements, well, then you absolutely wrote bad code.

This is what a more senior developer understands, where a junior would jump in and write worse code.