On Programming Pedagogy
A Response to Carson Gross
I've been watching the videos coming out of the Software Should Work conference. They've mostly been mostly good. Carson Gross gave a talk called AI & the University. Shockingly, I have opinions. Although they're not, specifically, about AI. Instead, they're about programming pedagogy.
Through a bunch of the talk, starting at about 8:30, Gross starts digging in on the question of whether computer science departments ought to teach students to code. He ventriloquizes Donald Knuth and a kind of vague cloud of pointy-headed academics, sketching a straw-man position that CS should not include---or at least, not centrally focus on---programming. Computer science, according to this straw-man, deals in theory and formal methods, not the mundane business of munging bits around inside actual machines. Of course, Gross is on the side of teaching coding in CS departments.
This is, these days, a bit of a lukewarm take. There's a group of people who are eagerly predicting the end of coding as a human activity because LLMs are now, apparently, the moral equivalent of compilers. (Oh my god, fuck Elon Musk so hard. I won't link to that.) To be sure, I agree with Gross that computer science departments really should teach coding. And while I dislike slop, I do quite like his (vibecoded) BDP-1, a 16-bit pseudo-x86 emulator. Visualizing things is great! And this kind of tool makes is rather easier for students to build up a mental model of how computers work (at least in principle). Gross seems like a really good teacher.
But while I think that CS education should absolutely include learning to code, I do not think that programming belongs only in CS departments. Moreover, programming pedagogy should not be tied very directly at all to employment as a working programmer. Gross's talk is at once about AI and pedagogy and also about the appropriate response for CS departments to the upheavals LLMs and their uptake have visited upon industrial programming activity. Id est, it's very hard to get an entry-level programming job as a newly-minted CS grad. I think this too narrowly construes the problem.
I keep returning to a passage from Abelson and Sussman's Structure and Interpretation of Computer Programs, the textbook from the 1980s developed in MIT's famed introductory computer course, 6.001:
Underlying our approach to this subject is our conviction that “computer science” is not a science and that its significance has little to do with computers. The computer revolution is a revolution in the way we think and in the way we express what we think. The essence of this change is the emergence of what might best be called procedural epistemology—the study of the structure of knowledge from an imperative point of view, as opposed to the more declarative point of view taken by classical mathematical subjects. Mathematics provides a framework for dealing precisely with notions of “what is.” Computation provides a framework for dealing precisely with notions of “how to.” (xxiii)
Computer scientists need to learn how to program, but programming is not of interest only to computer scientists. It should, rather, be of interest very broadly, so broad as to represent procedural epistemology.
A few pages before, channeling their mentors, Seymour Papert and the deeply disgraced Marvin Minsky, they write,
[A] computer language is not just a way of getting a computer to perform operations but rather that it is a novel formal medium for expressing ideas about methodology (xxii).
In other words, computer programming is not only a tool for theoretical computer scientists, nor even one mostly useful for people working to build industrial software. Code, as a medium of expression for knowledge, has a scope of application far broader than what Gross presents in his talk.
Now, to be sure, I doubt Gross would object to a plan to expand the proportion of university students who get the opportunity to learn to code.
In the back-and-forth about MIT's move to retire 6.001 and replace it with a very different approach, we see a repeated complaint from employers: MIT's computer science graduates did not know how to code. I honestly have difficulty imagining that. Of course, I'm perfectly willing to believe that MIT's CS graduates didn't know how to write industrial code, code that exists within a particular economic and bureaucratic context. Gross, quite reasonably, points out that most computer science undergraduates never go to graduate school, and vanishingly few go on to be researchers. Most CS grads are indeed workaday programmers, and it's probably a good idea to teach the kids how to use git. (I am, myself, still a little fuzzy on git.)
Computer science is not software engineering, and university is not trade school, and employers actually need to train their entry-level employees, no matter how much school they've had. The relationship between academic study and professional practice is, like, really fucking fraught across just about every department in the university. Humanists, perhaps, must have a more honest assessment of the relevance of our teaching to how our students will spend their lives: we just don't know.
I digress: my point is rather that programming should belong neither to computer science departments nor to employers of coders. If programming really is a novel medium of expression, we ought to teach and learn and use and futz and play and make with it to see what we can get it to do. I see no reason at all to concede that either theoretical computer science or the economic interests of the software industries ought to organize what we do with code.
At the time I started my first assistant professor job, the digital humanities were on their upswing. I was surprised to learn that I, having done digital media studies for something like a decade, was actually also a digital humanist! One thing that started happening---and it hasn't really stopped, although the energy has waned, somewhat---was an impulse to want to teach humanities students how to code. In my experience, most of the time that happened, the idea was to teach programming on a STEM model. Computer scientists knew how to teach people to code, right? And anyway, DH sometimes tried to renovate or replace qualitative, experiential, and/or hermeneutic---humanistic---modes of knowing with quantified facts, often understood to be closer to STEM modes of knowing (but often really bad imitations of such knowing).
But "new" media artists had been teaching artists to write code for a long time. And artists tend to have a really robust understanding of the way their tools constrain and enable their modes of feeling, knowing, and expressing. In other words, the spaces where code as a distinct and still-novel medium of expression were being worked out were as likely to be in the art or music departments as the computer science department.
I think there's still a lot of things we can do with code that we don't really grasp yet. I'm not sure we even really understand what programming is, despite how much programming there is in the world. But I'm not at all willing to cede programming to the LLM. (Not that I think that's actually plausible, but what I think about the future is worth every bit you paid for it.)
Programming, like all modes of expression, expresses and embodies human desiring, fantasying, making and unmaking, meaning and nonsense and exhilaration and fear. And it seems to me that using code---and learning to use code---in all the ways we express ourselves, or could imagine expressing ourselves, is a project that deserves a much broader, wider, and weirder constituency than it has to date.