Related concepts in Peter Naur's "Programming as Theory Building" [0] or Gerald Sussman's "Problem Solving by debugging-almost Right Plans" [1]

[0] https://pages.cs.wisc.edu/~remzi/Naur.pdf [1] https://www.youtube.com/watch?v=2MYzvQ1v8Ww

I mostly agree, however experienced a different challenge exactly for the very reason of consistency:

I used to work within the Chromium codebase (at the order of 10s of million LOC) and the parts I worked in were generally in line with Google's style guide, i.e. consistent and of decent quality. The challenge was to identify legacy patterns that shouldn't be imitated or cargo-culted for the sake of consistency.

In practice that meant having an up to date knowledge of coding standards in order to not perpetuate anti-patterns in the name of consistency.

How about “We sell a computer called the tinybox. It comes in two colors + pro.

tinybox red and green are for people looking for a quiet home/office machine. tinybox pro is for people looking for a loud compact rack machine.” [0]

[0] https://tinygrad.org/#tinybox