💾 Archived View for dcreager.net › 2023 › 09 › 28-graydon-code-should-be-readable.gmi captured on 2023-11-04 at 11:37:27. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
2023-09-28
Interesting toot from Graydon Hoare (quoting in full):
Re last boost: I hear this sentiment ("code is meant to be read more than run") a lot among programming communities and I've even repeated it myself but lately I wince seeing/hearing it repeated. I increasingly think it serves to obscure the economic realities of our occupation. Like it's a story we like to tell ourselves to try to elevate us from proletarians to poets or something (see also the "dabblers and blowhards" essay). It's related to, but a little loftier than, all the stories about entrepreneurialism / founders / solitary geniuses and so on.
And I think it's actually not very true. Code _can_ be written for reading, among people interested in that practice, but it's mostly written for running, and even more-mostly written by someone being paid by someone else very interested in minimizing the cost of going from "nothing running" to "great, something is running" (often though not exclusively in order to facilitate "firing people and replacing them with programs that run 24/7 without complaint").
Virtually none of the people paying for software ever want to _read_ it. They also usually don't want anyone _else_ to read it, because it's as low quality as they could get away with -- again, "just good enough to run" -- and carries embarassing traces of that fact inside itself. Most parties involved in the production of software would prefer if it were something better behaved and more economically fungible: say, a shipping container full of iron pellets or plastic nurdles that accomplished the same task.
I think the most realistic (secondary) sense in which most code is "meant to be read" -- at least the great majority that is meant primarily for running -- is as a matter of solidarity with future maintainers. A relative of right-to-repair and so on. Keep the thing navigable so people with different future needs can modify it / fix bugs in it.
(notably also this is the supposed origin story of the free software movement: fixing a broken printer, not conveying important knowledge or expressing oneself)
Graydon Hoare, 2023-09-28 [types.pl]
References this toot from Steve Crawford:
Steve Crawford, 2023-07-12 [mastodon.social]
Slide comparing comments in Apollo 11 and Quake III source code
I...don't know what to make of this. I think Graydon is correct in questioning whether code _actually is_ meant to be read more than run, in the sense of what economic processes caused that code to be written in the first place. And if I'm writing code to put food on the table, I can see the suggestion that we shouldn't delude ourselves about the actual “intent” of that code. But I chafe at the idea that that is what I should care about!
And I guess that's exactly the tension that Graydon is trying to call out. We view ourselves as crafters, and structure our internal monologue around that. But are we really? Is it a folly to try to infuse craftsmenship into what is, at the end of the day, a transactional exchange?
He mentions towards the end the “secondary sense” of code being meant to be read as a proxy for being maintainable or malleable to future needs and bug fixes. And that's where I feel that folly resolve itself. The people working on software as a consumable, or only service of a Job To Be Done, might consider maintainability a secondary sense. But I think that's short-sighted, because of all of the usual arguments about how common bugs are, and how that makes it a virtual certainty that changes will be needed at some point down the line.
Or maybe that's just what I tell myself to sleep better at night?
