Read Programming as Theory Building
codeutopia.net
codeutopia.net
This is discussed in the "Ryle's Notion of Theory" section of the original essay.
It may destroy many foundational assumptions that humans have had for thousands of years.
Theory building for a program? That's less important. But you give up any chance of a human ever being able to work well on it. That may be an important loss; we'll know in 5 or 10 years.
The larger and more varied projects that you have designed from scratch, the more you start to understand what programming/designing is really about.
Perhaps automated tests?
Perhaps?
Automated tests are a powerful tool for theory building both when creating and maintaining a codebase:
Doing automated tests well enough to get the value; that is not common knowledge.
You need to make your agent witness every test fail before it’s allowed to pass (this is red-green testing, if you’re researching it that’s what it’s called online.)
Good tests should never do I/O or test third-party code (so they stay fast, so you can run them more often). You should have tests to verify behavior that’s not explicitly in the logic, verify behavior that’s obscure or hard to test manually, and tests that prevent future engineers removing the fix that saved a customer’s butt at 3am by documenting the desired behavior of the fix - in an executable way, so the test fails if someone undoes the fix, and if the test is removed, questions can be asked in review.
Automated tests are trustworthy because they are exercised on commit and on deploy. They describe (almost) enough about how the thing is supposed to work that your coding agent can explain to you what it does and how, often it can explain why, and it can tell you where the skeletons are. Start now, it’s a great investment.
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.