“Reading Code”?

An otherwise productive morning of dissertation work (coordinating the published letters of John Quinn, Margaret Anderson, and Ezra Pound with the censorship of Ulysses) was (not for the first time) interrupted by interesting things happening on my twitter feed–in this case, things from the Digital Humanities ’09 Conference (#dh09). In particular, a conversation that grew out of a panel on “Critical Code and Software Studies” panel. (The full conference schedule is available here.)

The question first began when Matthew Kirschenbaum (@mkirschenbaum) noted a question asked by DH09 keynote speaker, Lev Manovich, at a panel on “Critical Code and Software Studies”:

(This panel seems to have produced quite a bit of interest. At least one related conversation between @sramsay and @triproftri was occuring simultaneously, which you can trace by beginning with this comment by DH09 presenter Kathleen Fitzpatrick (@kfitz) and following the “in reply to” links back.)

Much hangs here on the word “read.”

Now I am fundamentally unqualified to comment here. I’ve written a very little code, never worked on any massive piece of software, and my familiarity with Critical Code Studies does not extend beyond a few tweets and some material on the CCS blog.

My basic, unqualified intuition, however, was that the size and complexity of “reading” code (to which Manovich-via-@mkirschenbaum brings our attention) is not necessarily an objection to CCS’s desire to “read” code. That is, the nature of reading code would make even large and complex pieces of software tractable to such practices because the very practice of reading would be very different from what we normally associate with reading in the humanities; Manovich’s challenge was not as insuperable a hurdle as it might initially appear. One can, for instance, compile and run the code to see how it works, or run it through a debugger. An exhaustive reading of every line that is compiled or interpreted to produce the executed program would therefore be unnecessary.

In this sense, it seemed intuitively to me, that reading code is very different from reading “literature.” Or, as I put it in a series of tweets to Julie Meloni (@jcmeloni):

• It is a completely different practice of reading tho, including skills not normally invoked (in humanities esp) by “reading,” no?
• To be a Joyce scholar means, among other things, having read of all of ULYSSES (we won’t talk about FW); one must “read” it all. Whereas…
• To be an expert on the Linux kernel, one doesn’t need to “read” each line of code (though one must understand the whole). (This admittedly is conjecture; maybe kernel hackers really carry parts of kernel code in bound volumes as dog-eared and annotated as my Norton Edition of Modern Poetry).

At the bottom of this messy little bit of thinking is the, I think, uncontroversial claim that a Joyce scholars would be thought less of by his peers were he to confess that he had never finished Ulysses. “Reading” in the context of literature studies requires reading the entire text. (Jane Gallop, among others, has pointed to the importance of “seeing for ourselves” with respect to close reading and its prominence in literary study, in her short piece in Profession [2007]).

(There is, however, something touchingly naive about this conviction. Very few essays or discussions of a text address it in such a way that they represent a “complete” reading, taking in the text “as a whole.”)

But @jcmeloni was skeptical of my distinctions. And, under the pressure of her questions (and, later, Matt Thomas’s, @mattthomas), the distinction began to fall apart. What started as an intuition started to feel like a series of false starts, of wrong ways of addressing an interesting question.

In the cramped confines of 140 characters, @jcmeloni put it this way:

Basically, I see ways of reading literature mapped directly onto ways of reading code; failures on both sides w/o scaffolded knowledge?

“Scaffolded knowledge” is an interesting phrase indeed; and while exactly how reading literature maps onto reading code is something too complex to address, I think I basically agree.

I might reframe (rescaffold?) the same point in terms of what constitutes competency within a field. CCS does not exist yet as an established, coherent interpretetive community (to adapt Stanley Fish’s endlessly useful phrase); but software engineers and developers do. And perhaps I can sum up my own sense of things that by noting simply a difference in standards of competency. At a literature conference a necessary but insufficient condition, quaint and messily imperfect though it might appear upon closer inspection, is exhaustiveness–having read the text in question completely. Completeness still seems a less relevant value to developers and programmers and therefore less vital to CCS insomuch as it is attempting to mediate between these two communities. Manovich-via-@mkirschenbaum’s initial question might seem like a problem because it applies an old scaffolding to a new building.

I may indeed be wrong in this conjecture. Writing this up, however, has made me realize, if nothing else, that my initial objection may have too quickly been foreclosing a deeper continuity between these modes of “reading”–as @jcmeloni was suggesting all along.

And particularly shocking, I may have fallen into the trap of imagining that “reading code” would be the more dynamic, less self-evident process, whereas reading “literature” was entirely straightforward and obvious. This is not to collapses all differences, but merely to echo yet once more:

Book space, like digital space, is a field of simulations, and in each case the machine–the book or the computer–is capable of connecting itself to a host related, equally complex information networks. (Jerome McGann, Scholars Art 167)