Umpteenth take on "Programming As Theory Building" One thing I haven't thought to mention until now, in all the conversations about this paper. Between 2019 and 2021 I had perhaps the influential experience of my dayjob career. I got reorged to take over a legacy codebase, and after some initial struggles became expert with it to the extent it felt like my baby, something I'd written myself. And it wasn't just me; I gradually became the tech lead for the team, helped others understand it, and for a while[1] the team was able to own it and make improvements to it. Factors that made this possible: • The codebase was relatively recent, just like in OP. • The codebase was well-designed, just like in OP. • One of the original authors was still in the company, and welcoming to questions. This one is not like OP. And it was crucial. [1] What happened after? The company decided it was old, banned changes to it, chased a new shiny thing and let it decay. Companies find many, many ways to fail.

You know...I've had similar experiences in the past as well, and I think what drew me to Programming as Theory Building was less the argument that it was impossible to gain a theory of the program without it being passed person to person from the original authors and more just a description of the idea of 'becoming an expert with it to the extent that it feels like your baby'. More that it puts words and an explanation to that concept where you gain an intuition for how the machine will work with different inputs, if there's a bug, having an intuition for where it likely is, and how to make changes to it quickly and safely...

There's probably a through-line here about how software engineers are primarily communicators. Even when we do not identify as designers, our actual tasks are to identify needs, get buy-in, and cultivate trust.

Huh, interesting...that second sentence wasn't where I thought you were going with that thought...I immediately went to thinking about how you may write code in a particular way in a particular place to communicate something specific about it to future readers...and I don't think I've seen much about that concept

There should be more rhetoric of code for sure, for sure.

I had an experience in the past where one of my teammates was working on a PR for another team's library and recognized an opportunity for a really clean refactor...but since the other team didn't know us really well, we decided to pare the change way back and just hint at the refactor in the PR by subtly making our code also work really easy with that potential refactored interface...giving them the chance to recognize it and decide whether to go in that direction or not...

I see 2 distinct tasks here: (1) control a machine, (2) communicate to other human programmers what was intended. This sounds like 2 languages, one for each task. And, a tool to tie the two together. Programming languages attempt to do a union of both tasks which just makes the problem harder.

Hm I'm not sure if you can actually split them out...or at least (1) contains a lot of (2) whether you intend it to or not.

I agree, but, I think that this is a problem. Conflating 2 concepts generally makes the solution 10x harder. We must use assembler to program CPUs, but, we don't actually need to be using sequential coding languages for anything higher level than that.