It may destroy many foundational assumptions that humans have had for thousands of years.
This is discussed in the "Ryle's Notion of Theory" section of the original essay.
The larger the project the more ways there are that you could decompose it, but only some of these are going to have good outcomes in terms of things like a concise flexible implementation, easy to read/write, debug and extend etc.
You are mentally exploring the alternatives trying to find the ideal factorization that minimizes complexity, keeps interfaces between parts simple and friction-free, and results in an implementation where the code almost reads like a high level description of the requirements, with additional levels of detail only exposed as you descend each level of the implementation.
I can't off the top of my head think of a super pithy way of expressing it, but optimizing the factorization and representations being exchanged between parts (the two go hand in hand) is the key. How do you reduce the requirements into a design with the fewest moving parts and simplest interfaces between parts. It's kind of co-evolution in a way.
Design needs theory to be intentional. It can of course be accidental (”seems to work, I guess”) or intuitive (”i know in my guts this is right but cant explain it”).
While both can end up with functional systems, if you cant vocalize the design journey the system is not very maintainable in the industrial sense (hence - theory is the vocalization of the design and the forces that influenced it).
In the sense that you seem to be using "theory" I'd somewhat agree, else all you really have is an artifact, not a intentional design. You could say the design is what-it-is, while the theory is why-it is, and both are certainly useful to document.
Where I'd tend to disagree, is whether the processs of programming is well described as "theory building" in this sense. The process is not the same as the destination, and the rationale for the destination is not always going to honestly reflect the process of getting there. I would also say that the process is not really about building/evolving these design-specific theories, although others may disagree.
For me, what drives the programming/design process is more the things I mentioned - at least as much general principles of software design, decomposition, factorization, orthogonalization, decoupling, minimal interfaces, etc, as it is about problem-specific design and theory. One does of course also have an evolving mental model of the parts of the problem and how they inter-relate (how one might break the problem down into modules and classes, etc), but I think that when things "click" and you go "Aha! I like this!", it's often more about generic design principles, and familiar design patterns, than it is about some problem-specific "theory" that you are evolving.
It's very hard, if not impossible, to describe the exact mental process of software design. I seems it has to be, like all reasoning and learnt-skill based behavior, a process of of subconscious pattern matching and doing what worked before. Biological RL if you like. I think it's possible to understand some of the patterns involved, such as these generic software design principles, but it'd be post-hoc rationalization to claim that some specific design rationale had been driving the whole process.
It seems it's the same for experts in any domain, e.g. chess - they can probably not tell you exactly why they selected a particular move, or why they intuitively ignored other potential lines, but can post-hoc provide endless theory and analysis of why it nonetheless made sense!
Most of my posts have aged terribly in the age of AI (especially the ones I didn't finish...so long, extended discussion of how to use a lab notebook when debugging, we hardly knew ye. Claude fixes our bugs now) but one job that engineers still have is the collection and retention of context that AI doesn't have and can't easily get.
The larger and more varied projects that you have designed from scratch, the more you start to understand what programming/designing is really about.