This is so true, but so shallow too. I think the big mistake is to treat the code as "the main thing" when in reality it's just a model (a golem) mimicking some

This is so true, but so shallow too. I think the big mistake is to treat the code as "the main thing" when in reality it's just a model (a golem) mimicking some "other thing" We're missing an entire set of code characterizations. Yes we have a "pattern language" but there's not much to characterize it structurally wrt "code distance" from one part of the code to the other (e.g. in call stack depth as well as in breadth). And again all of this needs to happen wrt the "abstraction" not the code itself. Having 10 methods 90% duplicated in a single file with 10% pecent difference is many times better than trying to abstract it. Having the same "unit conversion" function duplicated in 3 parts of the code can be disastrous. These two examples are very easy to see and understand, but in reality you're always in a continuous state in between. And "code smells" like passing too many parameters or doing "blast radius" for certain code changes are only watching for side-effects of a missing "code theory". An interesting book on the topic is "Your code as a crime scene". The bottom line is we're trying to fix these problems over and over again without having a good understanding of what the real problem is and this leads to too many rules too easy to misinterpret unless you are already a "senior artist"