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.
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.
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.