--- description: What if knowing stuff and having good taste is secretly a valuable thing lastmod: 2026-06-11 slug: theoryholders title: Theoryholders --- There is a handwavy concept that I've been discussing on and off with some of my coworkers for a while now so it's probably time to write it down somewhere. An essay that I like and recommend a lot is Peter Naur's ["Programming as Theory Building"](https://pages.cs.wisc.edu/~remzi/Naur.pdf). It's mostly a riff on Gilbert Ryle's [The Concept of Mind](https://en.wikipedia.org/wiki/The_Concept_of_Mind) which contains lots of [philosophical stuff](https://utf9k.net/blog/big-words/). Thankfully, the essay more or less sums up one of the key ideas in the section titled "Ryle's Notion of Theory". Ryle's "Notion of Theory" essentially says if someone is doing an activity like following a recipe step by step, they're doing it without any greater understanding. If someone is doing an intelligent activity like doing standup comedy, they are doing a bit more than just that thing. If someone were to give you a list of rules on how to make jokes and you followed them exactly, you probably wouldn't be very funny. There are probably all sorts of unhandled edge cases that the rules don't cover as well. A comedian holds a "theory" of how to be funny because they have all this internal knowledge about comedic timing, how to recover if there's an awkward pause, what makes something funny and so on. They can't really provide a set of complete, coherent rules to follow but there is still some sort of "bigger picture" that they're able to see. You could ask them specific questions and get specific answers but for building a complete picture, it'd be like seeing a 2-dimensional slice of a 3-dimensional image. Spend enough time as their understudy, read enough material and fail a bunch, and you too will probably build out your own fully fleshed out theory of how to be a comedian. In this sense, a theory is more than just [pattern matching](https://en.wikipedia.org/wiki/Pattern_recognition_(psychology)) or random chance. It requires some level of introspection to be able to rationalise what works and what doesn't. There could also be other dimensions such as time, having an idea of what doesn't work now but might work later on and vice versa. It may also, optionally, involve developing and making use of [your own good taste](https://utf9k.net/blog/publish-old-works/). In the way that Naur used it, he essentially says that programming is theory building in that code itself is only an expression of what presently works. In the most literal sense, it's an English language expression[^english] of how a program should behave. Programs are mostly a positive space of the end state that you want to get to, and maybe a little bit of the negative space if you have clauses to [capture behaviour that shouldn't be possible](https://developer.mozilla.org/en-US/docs/Glossary/Invariant). What generally is not captured is a whole realm of stuff like what was tried but didn't work, what could be tried in future, what would be ideal but could never be possible, what customers would appreciate but is technically hard, what customers would hate but would make for better DX and so on. It also does not capture what is "good", whether it's aesthetically pleasing, a pleasant API to interact with or an intuitive UI. Some of this may be written in documentation, even more might be posted via chat software but the full "theory" generally only lives in the head of those who work on this software and evolve it over time. If the program and document itself is a sort of positive representation then you could say that what is missing is a "negative" representation because... it isn't recorded anywhere! You can't "see" any of it looking at the thing in front of you. It's only earned through time and effort. Naur was of the opinion that the only way to truly get someone new up to speed was to have them work alongside developers who already hold these theories for a given system and through osmosis, they'll come to understand and inherit these theories, and perhaps pick and choose to develop their taste of what's good (and bad) as well. If you were to lose all of those held theories such that you have to build a team from scratch with no transition period, you would effectively be left with dead software. It still exists in the form of code but all of the missing bits of theory have to be redeveloped from the ground up. Worse, these theories may be entirely different as to how this software should work, what makes it good and so on. That road leads to [Frankenstein's monster](https://en.wikipedia.org/wiki/Frankenstein%27s_monster) type software that seems to be designed by a committee that has no understanding of the end user. There's something to be said for the idea that code itself is not the complete story and that you need to go further to have some sort of idea of how a piece of software should work in order for it to flourish. The idea of being [In good hands](https://stephango.com/in-good-hands) comes to mind when I think of software that is delightful to use because it really feels like the creators have a great theory about what it should, and importantly should not be. To do this requires having good taste on what things should exist, what things should be merged together, what things are temporary and should never see the light of day and so on. Taste is also a handwavy concept but I think it's kind of an important factor when it comes to good software, or really good design in general. What is considered "good taste" is different across everyone but paired with having a theory, it helps you choose what should be done and what shouldn't. You don't want everything to be a [wobbly clock](https://somethingorotherwhatever.com/wobble-clock/) but you don't want users to be digging around in nested submenus 20 levels deep either. One of the double-edged swords of programming is that while it requires you to develop theories about whatever domain you're working in, you also end up developing [theories about systems](https://en.wikipedia.org/wiki/Systems_thinking) in a meta-sense. If you're working on say; retail software, you'll be developing good taste about eg; what makes a good point of sale system but also generally what's a good way to orchestrate a codebase or documentation or interaction between teams and so on. It's probably not much of a surprise then that you end up with founders who go on a [spree](https://www.harpercollins.com/products/the-prize-dale-russakoff?variant=39936061833250) [of](https://archive.is/oVHal) [interfering](https://en.wikipedia.org/wiki/Tham_Luang_cave_rescue#Elon_Musk) [with](https://www.theguardian.com/commentisfree/2026/feb/02/jeff-bezos-destroy-washington-post) [things](https://edition.cnn.com/2019/12/29/media/marc-benioff-time-magazine-reliable-sources) that might seem like a straight-forward systems problem, only to overlook that they don't have any taste about the actual domain itself. With all this in mind, this brings me to the use of LLMs for software development[^llms]. In an industry that has rapidly moved from the "old world" of manually writing code to the "new world" of [automatic programming](https://antirez.com/news/159)[^move], I think theories will matter more than ever. There's this idea that software engineers will become completely interchangeable because you can "just get the LLM to read the codebase" but as we discussed, the codebase is only part of the story. Purely from an agent point of view, the entire negative space of decisions is not available to parse because it's not captured down anywhere tangible. It could probably infer its own theory based on what it sees combined with the broader knowledge available to the model but such a theory probably would trend towards the average. Such a theory would be reconstructed from scratch for every new session, where it may be more or less detailed each time. You could commit it to a document but then you're dealing with the aspect of time. As rules are developed and iterated on, they may not be entirely discarded when found to be wrong or they may be taken too literally. Accumulate enough of this and you may end up with a hamstrung agent. I've witnessed variations on this problem a bunch of times in the past. Agents are not fully autonomous of course, having a human operator. Are all operators the same? An operator with a strong theory will probably have a great time because they can inform an agent on what "good" looks like, what to ignore and what to focus on. They can also recognise when an agent is completely off course, inventing theories of its own that are nonsense or just straight up hallucinating. Importantly, they can also perform experiments, getting an agent to generate new things they haven't seen while being able to rely on their existing theory and taste to decide which of these new things are actually good and which things suck. Inversely, someone without any of these theories will likely have a rough time if they just blindly accept whatever an agent tells them is good based on its own invented theory. Personally, I do think there will be a bit of a "rising tide lifts all boats" type of scenario where operators with zero theories will get closer towards having something to work with, just based on agents trending towards the average. That still isn't the same thing as actually holding a theory, and you'd struggle to develop a coherent one without knowing what responses from an agent are factual and which are hallucinations. You can somewhat work around that by asking for cited sources, which you then verify first hand but that in itself is a meta-skill that requires taste in the first place to know when to be skeptical, especially when you're out of your depth. It really irks me whenever I give LinkedIn a scroll out of morbid curiosity and see wild claims that everyone will be generating their own software. This reminds me of a Web3 talk that I went to back around 2016 where a speaker said that everyone will be acting as their mini-power plant selling electricity back to the grid in exchange for crypto. [I dunno](https://www.theverge.com/podcast/917029/software-brain-ai-backlash-databases-automation), that sounds like a lot of work when instead I have a life and why don't we all just pay the one person in town who really finds electricity fascinating. They can start a company and hmm, I guess it'd look a lot like what we have today. There's nothing wrong with non-software developers experimenting with [creating their own software](https://www.robinsloan.com/notes/home-cooked-app/), this isn't really a post about that, but ideas are cheap and you very quickly find out that what seemed like a good idea in your head is actually rubbish in execution. Execution itself is the hard part and you can get a long way if you have a strong theory and great taste about what would make a good piece of software, but if you don't, you'll probably end up having a rough time because nothing makes sense and you're just pattern matching at best. In some sense, I'm just advocating that expertise still matters but further than that, expertise combined with good theories and taste is what I think will prove to be valuable for a long time to come. Good theories and taste spread throughout organisations, slowly and with a lot of effort on the part of theoryholders, but wielded well, they can [lead to some impressive results](https://www.versaedits.com/article/obsidian-built-350m-app-3-engineers). Theories are your real asset, not the code that you're writing by hand or generating. It'll be interesting to see what happens when there's [no one around to inherit and cultivate them](https://finance.yahoo.com/sectors/technology/articles/99-ceos-planning-ai-layoffs-110000014.html). [^english]: At least, across most programming languages, keywords are written in English regardless of what actual language you speak. Comments can be in whatever language you prefer of course. [^llms]: I don't actually think I've talked about LLMs in any of my posts to date but broadly, I'm fine with generating text but I could do without image (or video) generation existing and I would rather commission an artist and support their work. There are an ocean of ethical questions from water and electricity usage, data centre spending, [circular financials](https://storage.googleapis.com/web-content.oanda.com/images/AI_circular_deals_Bloomberg_News_8_Oct_2025.original.png) and more but the status quo in the software industry is broadly using LLMs to speed up development. They are genuinely useful for software development, arguably being better at software development than I will ever be. Speed does not equal productivity or value however, and there are a variety of secondary side effects that are out of scope of this post. [^move]: Most engineers I've talked with from other workplaces are all using LLMs in some capacity. I can't recall the last time I ran into someone in the industry who isn't using them, which includes a [recent conference](https://aws.amazon.com/events/summits/sydney/) I attended.