I don’t entirely subscribe to the first paragraph – I’ve never worked at a place so dear to me that spurred me to spend time thinking about its architecture (beyond the usual rants). Other than that, spot on
I agree; I prefer a “hammer and chisel” strategy, I tend to leave things a little less precisely organized/factored earlier in the project and then make a some incremental passes to clean things up as it becomes more clear that what I’ve done handles all the cases it needs to handle.
It’s the same vein as the “don’t prematurely optimize.”
Minimizing responsibilities of individual functions/classes/components is the only thing that I take a pretty hard line on. Making sure that I can reason about the code later and objectively say simple sentences like “given X this does Y.” I want all the complex pieces to be isolated into their own individual smaller pieces that can be reasoned about.
All of the code bases I’ve been in where I go “oh my god why”, the typical reason is been because that’s not true; when I’m in the function I don’t know what it does because it does a lot of things depending on different state flags.