I think about it a bit differently. Code is an *interface* between humans and those little doors. As such, it has two ends, a human end (the human legible code) and a machine end (the compiled output). Often bad code is not particularly bad at the machine end. There aren’t too many doors or inefficiently arranged doors. It’s the human end that’s the problem. Lots of hard-coded values are bad code, but they have no effect on efficiency, only on maintainability. Often it is better for the code to be “good” at the human end at the expense of being a little worse at the machine end because of the cheapness of computer power compared to engineering hours! I find this double ended view of code to be a helpful perspective in terms of understanding code quality - both ends need to be considered.