Deploying more code faster is admirable. Deploying useful features is essential. Don't optimize the former at the neglect of the latter.

A very sound and thoughtful article, Bilgin. As for building a theory of a codebase, I like to think of it this way: every such theory serves to represent the set of significant design decisions that shape the form and function of a system. Simply put, this is the system's architecture. In any software-intensive system, while the code is the truth and is therefore the ultimate manifestation of all such decisions, there is a loss of information from human design making to code and therefore one cannot fully capture those decisions, their context, and their rationale. Documentation sometimes fills the gap, but in practice, these are things that become part of the project's institutional memory. For complex systems with low turnover, those decisions the very atmosphere which all the developers breathe and so it is rarely spoken of, it just is. For complex systems with high turnover, this is why so-called elders are revered and consulted. Local work can proceed with vibrant pace by small teams because their work in general will not disturb the load-bearing decisions, decisions that are so very much baked in to the codebase. For these souls, a theory of the codebase is not particularly relevant, for they can reach the next mountain without needing to know about the tectonic plates that formed the peaks in the first place. Now, mind you, in the fullness of time, architectural drift will happen: technology changes, requirements change, the market market changes, and so there will come a time of reckoning. But if you are in a high turnover place, well, that's not your problem, it's a problem for someone else (and honestly, that's ok). I will also observe that there's another way to group the developers you see vocal on social media. Many are those seem to be engaged in the front end of web-centric systems with apps that are not meant to be enduring. There's another equally valid group of souls who I find unrepresented here, people who build systems such that if they fail, people die, organizations crumble, and civilizations are in peril. For this latter group, having a theory of the code base is far more important. But this is the wonderful thing about software: the field is so broad, their domains are so varied, such that its hard to generalize and it is certainly dangerous to generalize based on heat and light from social media. By way of full disclosure, I will report that @claudeai is my go to coding partner: I use it daily on several programming projects.

I made a thing.

The Greeks spoke of Talos, a giant bronze automaton crafted by Hephaestus and powered by ichor, the golden blood of the gods. Al-Jazari's The Book of Knowledge of Ingenious Mechanical Devices proposed the creation of humanoid automata. Su Song used water to power his cunning devices. da Vinci envisioned autonomous mechanical knights commanded by ropes and pulleys. Babbage envisioned computation with gears, although his aspirations were constrained by the realities of contemporary precision metal production and Lovelace's reminders of the limits of computing. Wiener explored feedback mechanisms inspired by organic systems. Newell and Simon used the power of pure logic. Feigenbaum pioneered the use of rules. From McCulloch and Pitts to Minsky to Hinton and Hassabis and many more, neural systems ruled. I posit these things: - sentience is an exquisite and inevitable consequence of the laws of physics - intelligence, consciousness, and sentience are suitcase words that are full of historical and emotional baggage and therefore have little meaning - brains are astonishingly complex, having evolved over millennia - the mind is computable - we are generations away from devising non-organic minds with commensurate flexibility, resourcefulness, and reliability That notwithstanding, the journey therein is valuable, for it may not only yield systems of utility it also challenges us to consider what it means to be human.