It’s contextual of course. The vast majority of code isn’t executed millions of time but is bootstrap to the primary kernel of execution. This kernel of execut

It’s contextual of course. The vast majority of code isn’t executed millions of time but is bootstrap to the primary kernel of execution. This kernel of execution tends to be fairly small in LOC space while dominating CPU time. Likewise most of the energy in software goes into the less expensive logic that configures the “interesting work” dominating the CPU. Readable code would take the bitflipping raw execution code and wrap it in an abstraction that’s easy to reason about as black box. Further, I’d say human time, velocity, and code agility is considerably more important than CPU time. CPUs are machines. They exist to do work and can do it without tire indefinitely. Being correct for the task is almost always (almost!) more important than being computationally optimal. That’s specifically why the metric stops there - even if I have to scale my farm by a factor of 10 due to inefficiency in the abstractions, it’s still a fraction of the cost of one engineers effort in a year. Obviously this breaks down at a certain point and at certain scales and at certain tasks. Finally making it work, right, fast, small by no means don’t write readable code at any let alone all stages. There’s very rarely any reason working, right, fast, small code is unreadable (aka unmaintainable). They are orthogonal concepts because readable code is about human ergonomics and work, right, fast, small is about architectural and runtime optimization phases.