I could never quite put my finger on it - but some of the best programmers I’ve worked with illustrated this. They seemed equally open to simplifying systems as towards extending them. Not “time for this week’s rewrite” kind, but they weren’t afraid of “losing” all or part of what had already been built.

I have a two step process for building a software system; I haven't got to the second step in practice, but some day...

Step 1: Build a proverbial "ball of mud", adding things left and right until all the shifting requirements are met.

Step 2: Write a minimal description of all the logic from scratch, by surveying the existing code, and then, essentially, write an interpreter for it.

If I got to step 2, and did a good job, future projects would become much easier.

This is surprisingly relevant to audio engineering, where amateurs tend to layer too many sounds and end up with a "muddy" mix, and pros are very good at selectively removing elements/frequencies to make the rest of the sounds extremely clear and coherent

The cognitive load result is interesting and might explain why technical debt is such a problem in our industry. I’m thinking that it might also be easier to simply add to an existing structure rather than understand the entire thing to realize where you can subtract.

In an arbitrary structure

  if a
    if b
      ...
    else
      ...
    end
  else
    case c
      ...
    when y
      ...
    when z
      ...
    else
      ...
    end
  end

Rather than understand how everything works and literally 'factor' out a new aspect, any structure can, without understanding, be incrementally be amended by changing all the relevant leaves with additional, duplicated substructures. Of course it looks clear and obvious here, but usually the structure is distributed across many classes, methods, and strategy patterns, etc. The 'factoring' work that needs to be continually done is at a higher conceptual level rather than the mindless 'deduplicating' refactorings that tend to get done.