> The paper also talks about what happens when all the people who have a theory of a given program stop working on it. It dies. Yikes. It’s claimed that we can’t rebuild a theory from code and documentation.
In the text above word "theory" are used instead of "understanding". Not sure why. Anyway, what exactly the hell Im doing in the last 10 years supporting legacy system mostly without documentation...
The “software as theory” idea is helpful - thanks OP. Right now I’m dealing with some devilishly difficult GPU code, and I now understand that I’ve been working to reverse engineer the authors’ theory from their code. With much effort, I achieved a gratifying epiphany, and the code suddenly became clear! (Perhaps I developed a theory related to but not identical to that of the original authors.) Fortunately, I have an enlightened manager, and he was patient with the “theory building” process. Software degrades to garbage when a series of successive developers apply changes to it without a cogent theory. The process is self-reinforcing; the more degraded it becomes, the harder it is to develop a useful and accurate theory.
Hello! I wrote this article.
I want to say something about the pop-ups, which to have been much more discussed than what I wrote. (UX disaster as engagement bait?)
My desire in showing was to make the site feel more “alive” and to make the reader aware that other people had been there. I was trying to build a vibe of website as public space. Clearly this was not an approach that handles hacker news traffic and attitudes very well.
Secondly, I wanted to make readers aware of how much data is visible about them just from visiting a website.
I wanted it to feel like when you land on a drop shipping site that occasionaly tells you “Alice in Norwich just bought a widget. They're selling fast!”. You slowly realise that the data is real, and that the site actually can see where you live, who provides your internet. Etc. It was meant to be creepy.
Anyway, I've removed the feature now. It was clearly causing usability issues for some people, which was not what I intended. I'll think about other, better ways to get the effect that I had hoped for.
Finally, I'll say that it was at least interesting for me to see things like
“Someone else just connected to Johncom. They're in Kansas City, US, 64121 and are connecting with Spectrum”
“Someone else just connected to Johncom. They're in Cape Town, ZA, 8001 and are connecting with airmobile.co.za”
I got to learn about some new places, postcode formats, and ISPs.
For reference I think this probably partly explains my reluctance to use A.I. to help me code.
If I ask e.g. ChatGPT to just code something for me then the code it outputs is a black box, and there is no 'theory usage' in the parlance of the article. [Or I guess I'd have to recover the theory from the code it writes].
I've accepted by now that I'm putting myself at a disadvantage by not using A.I. at work however. Maybe another way to think about it would be that A.I. allows us to use our higher level theoretical understanding when we interact with codebase.
> The closest we can get to transferring a theory is to demonstrate the expression of the Theory to someone over and over again until they build their own theory. That theory won't be the same as ours.
This already has a term: "derived meaning". Derived meaning is what's actually created and stored in your head, and represents your particular brain's understanding of... something. It could be a thought, it could be a procedure, it could be a memory, it could be an emotion. But it can't be transferred to other brains; you can only hope that, by communication, you can reach some form of mutual understanding that at least fits the communication.
I appreciate the author explaining this.
I have had a Theory of what software is myself, mostly based on "Programming as Theory Building," but it is good to see it put into words.
I struggle to build "theory of mind," which means I can't read code written by other people.
This means I can't get or keep a software job, so it sucks.
At the same time, it is a superpower in personal projects because I can somehow document my own theory of mind. It's counterintuitive, but my inability to build a theory of mind about other people causes me to assume less about what they know, which translates into good Theory docs.
My best example is [1].
[1]: https://git.gavinhoward.com/gavin/bc/src/commit/22253a3a64db...
You'll get a lot of out systems thinking then! Essentially the formalization of thinking in parts ("theories") and their interactions
https://en.wikipedia.org/wiki/Systems_thinking?useskin=vecto...
I tried reading this but the pop ups are so annoying that I couldn’t get past the first paragraph.
If it becomes, or is deemed, necessary to have, or recover, a theory of an implementation of an automation, then you have already lost. What is necessary is the theory of the business. If you do not have that -- and practically no one has that -- then your automations are towers of guesswork, and there is no way to determine whether they are correct.
To me, programming is all about designing things in such a way that the "theory" (using this particular meaning of the world) mostly already exists.
I see a lot of programmers start with an idea, and then they implement it. I prefer at least a little bit of cargo cult approach.
I don't re I start researching what tools are already out there and what others do in similar cases before I have any more than a vague idea of what I want to do.
There's this seminal paper by Peter Naur called "Programming as Theory Building" that arrived at the exact same conclusion when it comes to programming:
https://gist.github.com/onlurking/fc5c81d18cfce9ff81bc968a7f...
I agree with the programming as theory building. Not an epiphany for me but it is something I realised for the last 20 years. I am however glad that other people can explain it better than myself. For another good explanation of this read “founders at work” where Steve Wozniak talks about how fast it is to develop when you keep all the code (theory) in your head
Just a quibble, but that usage of “theory” is entirely correct. Nevertheless the point is taken that often in general usage “theory” means “scientific theory.” Anyhow, with some small consideration it should be clear that the latter is merely a subset.
I find the relationship between software, code, computers and humans endlessly fascinating. The epistemological discussion here is incredible in both substance and in noticing how fast some people derail it into semantics.
If he replaced the word "theory" with "model" it would be much easier to understand the point.
(I think I'm the only on-topic comment so far.)
Replace theory with abstraction/mental model/concept and then the blog becomes quite obvious.
Yes, grokking code is hard, especially low level code where the WHAT to do is intertwined with the HOW.
Very interesting article, thank you for sharing your epiphany. The only thing missing was an attempt to come up with a better term than "theory" ;).
Nuked the notification stream with UBlock: `##section > ol`
It's an interesting observation on the reason behind something that's understood fairly well in management circles from its impact: Retention of software engineers is really important!!!
I never really had a conceptual model for the period in a project where I can't really effectively write code outside of exploratory exercises. Building a theory of the solution to a problem is absolutely the most difficult part of any project that I've worked on.
In brownfield projects I will usually start out with a manual linting pass. I read code deeply enough to understand it to a point where I feel like I can make delinting changes to it. This helps me build up a theory of the solution space that those who came before me, the act of delinting, commiting, and pushing stands as something of a mental proxy for having written the code myself.
Greenfield projects are much more difficult as you have to synthesize this theory from whole cloth rather than learn it by reading the musings of coders that came before. IMO, this is incredibly valuable as very few devs I've met have the capacity, even if they have the experience.
In many ways I think that past successes in founding companies is used as a proxy signal for this skill by investors when making a bet on a venture by tenured tech founders.
What an incredibly annoying popup. Sorry, can't read that.
Well, this is a rare case of a professional-looking site rendered completely useless thanks to a single design decision made for no apparent reason at all.
For everyone talking about the notifications at the bottom:
After the page has loaded, use “reader mode” in your browser. Most browsers have this. That shows you only the text of the post, and not the notifications on the bottom.
Or, read a copy of it here:
https://web.archive.org/web/20231118211242/https://johnwhile...
Top tip; I used my thumb to cover up the bottom part of my phone, which allowed me to read it!
I expect that 99% of the time it's a perfectly fun little pop up, but right now with the post on HN it is amazingly annoying
Look the popup is bad, but consider he probably usually gets way less visitors, so in testing it’s probably not that bad for him. Maybe a few per article usually, but with hacker news it blows up.
Let’s not roast the guy too much, we’re all human and like cool stuff. This would be cool with a little more work, I think.
Also, the article is great. It puts together a definition for the theory of what software is in a succinct way. Software is code, but any specific software is an artifact of the theories in the developers brains. Makes a lot of sense to me.
I got here, read the comment threads and thought, "Why is everyone going against HN guidelines to toss out low effort comments about the site design? How bad can it be?"
Then I went to the page. So distracting. I just closed it and agree with everyone else. I'd recommend the author get rid of that.
Good outline of the idea of theory building. I especially appreciated that the author has added a feature to scare off simpletons.
[dead]
This is actually a great article even though the popups are terrible and I found the first sentence very off-putting.
What the heck are all the notifications on this site?
You might understand software, but you clearly don't understand web design.
Made with PartyKit if anyone wants to make their own :P
what in the world is going on at the bottom of the site, it’s crazy distracting.
OP, I bet that popup is turning away traffic
Copyright law protects computer programs as the expression of an idea. One idea has many expressions. If you want to modify or extend it, you need to know the idea.
[webpage text follows]
The podcast in question was episode 61 of Future of Coding. It is essentially a read-through/review of two papers with which I was unfamiliar, but which I believe are actually quite famous and influential.
Why did listening to this feel like an epiphany? Well, I suddenly felt like I understood what the deal is with software. Why is it that when you join a company, the engineer who's been there for years seems like an incredible genius? Why do some teams that I've been on struggle while others manage to get everything right? Why is everyone always so keen to rewrite things?
The two ideas that the podcast expresses are:
The concept of what a “Theory” is, according to Gilbert Ryle.
That being a programmer is doing “Building theories” in the Ryle sense of the word.
I recommend listening to the podcast and reading the paper. But if you don't want to do that, I'm going to try and explain the two points.
strange What is a Theory, According to Gilbert Ryle?
When Ryle says theory, he doesn't mean anything like what other people mean when they say theory. Annoying. He should have just come up with a new word. What he means is the thought object that exists in our minds which allows us to do things.
I, for example, know how to cook pasta. When I cook pasta, that's a certain expression of this knowledge. When I try and explain to you how to cook pasta, that's a different expression of it. Neither of those expressions contains everything I know about cooking pasta. And in fact, there are parts of what I know that I can't really express in any way. This knowledge is what Ryle would call a theory. I have a “Theory of how to cook pasta”. This theory is not something that exists in language or action - it’s a something that we can never fully express. The closest we can get to transferring a theory is to demonstrate the expression of the Theory to someone over and over again until they build their own theory. That theory won't be the same as ours. What Does it Mean that Programming is Theory Building?
It means that the code base we create is not the true product of our work. The real product is the mental theory of that code base which:
Allowed us to create it in the first place.
Allows us to diagnose problems with it and fix them.
Allows us to modify it easily.
Someone has been there for a long time, since the start of whatever code base/feature we work on.
Other team members have joined slowly, and had a chance to work with the people who know more.
The area of focus does not change. We haven't been reassigned to a random existing project, or asked to fix some other team’s work.
This model explains a few curious phenomena:
What “legacy code” actually is - it’s a code base which is no longer maintained by people who have a theory of it.
The solo engineer who can make a better product than a team of equally competent professionals. The solo engineer has spent the time to build a complete theory of their program, the professionals move between projects regularly - and only have theories of what they've worked on.
Why getting up to speed with unfamiliar projects is so much harder than just rebuilding the thing. To truly build a theory, you need to mentally rebuild the existing code base anyway.Holy crap, I tried to read this article but could not get over the constant motion in the corner. Can you please add a way to suppress this?
Epilepsy warning.
Title is a bit overblown for the actual epiphany which is more about the necessity of programmers having a robust mental model of a system to be able to maintain, let alone improve the system. I don't see anything particularly unique to software in this thesis, as complex physical systems also have the same characteristic.
I also think this is way off base:
> It means that the code base we create is not the true product of our work. The real product is the mental theory of that code base which
This is manifestly not the case. The value of computers is that you can write code once, and the computer can execute it repeatedly ad infinitum. As a programmer, your mental theory of the code base has value to its owners, but it's not the product. The code base is also not the product. The product is whatever output is created and consumed by the relevant stakeholders.