Read Programming as Theory Building

skydhash

The only reason I recommend this paper is because I encounter so many people that have a very myopic view of the software that they’re building. They are focused on individual features and how to quickly made them happen regardless of what happens to its cohesiveness. You start to talk about interfaces and contracts and they’re like a deer blinded by a car’s headlights.

msteffen

I wrote a series of blog posts about this a few years ago: https://creating.software/essays/theory_of_a_program/ , some of the few I ever actually finished, lol. 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.

jinwoo68

You should read it especially now when more and more code is written by LLM. The important thing is not the code itself but your mental model of the software you're building. Sadly we seem to be moving away from it. We're accumulating more and more code that we don't understand or haven't even read.

HarHarVeryFunny

The name "theory building" doesn't really resonate with me - I think effective design ("programming" if you will) is more about things like decomposition, factoring and representations. 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.

TACIXAT

This is helps describe my biggest pain point when engineering a program with LLMs. They do not have the full theory of the program, which makes things difficult. Additionally, the more hands-off approach to programming (even when I try to maintain involvement as much as I can) means that I lose the clear conceptualization of that piece code. I'm still trying it to see if it can work, but it is definitely a vibe shift from making 20 micro-architectural decisions in every function.

vatsachak

By the curry-howard correspondence, this is literally true.

cadamsdotcom

> If you think of things like “good code” or “maintainable code”, what is it that comes to mind? It’s probably things that make code easier to understand, ... Perhaps automated tests. 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.