Keen to explore ideas and methods from the emerging field of critical code studies (CCS) with a wider pool of researchers, PhD students Claire Carroll and Orla Delaney took it into their own hands to create a collaborative, hybrid space for just that. The Cultural Politics of Code reading group successfully launched in October 2023, with over 140 participants signed up from across the world. Following a term’s worth of discussion, Orla and Claire sat down together to reflect on how the reading group went and what topics kept recurring in its discussions. An abbreviated version of their conversation is below.

Orla: We said when we started out that a reading group would only be worthwhile insofar as it might give the two of us new perspectives on an area we’d already been reading about – do you feel like that happened? Was there anything about running the reading group that surprised you?

I found it interesting just how difficult it was to talk about code while sticking close to the code itself. Some of this was to do with how we organised it, but a lot of it felt like a lack of fluency. Obviously we were doing this from within an English department, and not everyone who came to the group was a coder, but it still felt as though we were lacking some facility that was essential to code critique: having quite general conversations rather than specific ones. At the same time, you could argue that CCS is a means of accessing the general through the specific?

Claire: I think the problem was maybe a lack of intent. We came to the code samples and readings with broad questions (e.g. what are code aesthetics?), and thus the discussions we had around them were generalised. The benefit of a reading group rather than just writing a paper, I think, is that it helps you tap into an overview of the scholarly landscape to identify which questions and niches are individually interesting. I think we achieved an overview of CCS, but now it’s up to individuals to take back a bit of control. I’d like to imagine we could run the same reading group again, even with the same people and have new things to say; the conversation is never over, the code can always be executed again.

What do you think about using CCS to try and tackle Large Language Models (LLMs), an inherently opaque database-driven pursuit? I feel like every conversation in literary digital humanities is suctioned towards ChatGPT. We talked about visible data sources (like Wikimedia), but considering the impact culturally and environmentally of these buzzy AIs, I think we have to find ways to use what we’ve learned from CCS to explore them, through affect and intent.

O: I like the idea of a recursive reading group – fittingly cybernetic, but also a pleasingly weird pedagogical idea. Reading groups are beneficially general, though we work in an environment where close readings of texts happen in groups every single day, and there definitely is value to stepping through a piece of code in a group, right? Programmers collaborate very routinely in their practice, and a lot of work in CCS is richly collaborative, but talking about CCS often felt for me like a deferral of the analytical responsibility of actually doing CCS: even with my programming and Digital Humanities (DH) experience, I never felt like I was going to do the “right” analysis.

I want to suggest (tentatively!) that my personal experience of participating in the reading group nudges at the limits of the characterisation of computer code as a text. Speaking from within the institution of Cambridge English, with its focus on practical criticism, I would say close reading implies an ability to isolate the text from its contexts that cannot exist for code. But the idea of use is always humming in the background of a piece of code, and it would be hard to derive meaning from that code without some gesture towards its purpose. Does CCS have a sufficiently robust definition of the object of its analysis? Does its claim to quasi-textual analysis need to be accountable to debates within literary theory about the nature of a text?

As for LLMs, I’m a fan of Nick Seaver’s ethnographic work on black boxed algorithms. I like anthropology’s view that digital infrastructures are unavoidably social. LLMs have a relatively insular set of developers, so understanding their cultural world is surely a valuable line of analysis.

C: To me, talking about CCS critically has to be a part of the reading group (Critical Critical Code Studies?). You’re right that Cambridge English loves practical criticism, but I don’t think the discipline seeks isolationism (anymore). CCS and most sorts of software studies wouldn’t expect scholars to only look at the code. Mark C. Marino writes about trying to interview developers alongside textual and cultural analyses. I’d say normal development practices don’t think about who is doing the development and the potential impact of those identities, however collaborative they are. They’re trying to solve a problem or create art or break something; even if code is a communicative tool, during development it is ultimately a tool.

I don’t think of code as a text, but I do think of code as performative language; that’s the wrong phrase; I think of code as potential-action language. Just like a theatrical script or a musical score. Some people can read it in its unrealised form and have an idea of what the functional execution might look like. The written code isn’t the purpose of the language, but it’s not a byproduct either.

Why do you want to do critical code studies? What do you hope to look at? I think, in practice, CCS is probably most useful as one methodology in a bouquet. Do you plan to use CCS in your short-term research?

I like Seaver’s model, but maybe I’m imagining things as less black-box than they are. To me, we know (largely) what these sorts of algorithms look like and we know (generally) what datasets they’re drawing from. We can analyse them. But it’s the same generalisation problem as before; if ChatGPT can do everything from write your cover letter to teach you to build a bomb, then how can we analyse it as a singular cultural object? It’s the opposite of the close reading problem and one I don’t quite know how to overcome.

O: I suppose what I’m trying to get at when I ask about code’s ability to behave and be analysed as a text is that it can be unclear what differentiates CCS from software or platform studies, other than the use of textual analysis. I think a comparison between code and, say, a theatrical script works well, though I worry it’s at risk of stressing functional significance over extra-functional, and thereby refusing to put CCS under pressure to actually deliver on its promise of a thoroughgoing analysis of what code is and does. Much of the interpretative work of theatre comes from people turning the script into a performance; in the case of code, that work is done by a computer, whose interpretations are only ever a literal execution of the code. In that scenario the burden of finding extra-functional significance is entirely on the critic, which is why I think sticking quite closely to the “text” is necessary.

I’m planning to do a little bit of code critique in the next month or so within my research, and I think it will be a much less complicated intellectual exercise than I’ve made it out to be here: in reality, it’s a method that I feel is intuitive, essential to my research toolkit, and analytically useful when integrated with the rest of my work.

C: I’m not sure we need to decide how much code resembles a text or require CCS to supersede all other methodologies in order to use it; I don’t think CCS promises anything other than a mechanism for putting different coding projects, languages, and conventions in conversation.

I’m a well-trained close reader, but I find myself trying to pan out; I think because I still find a performance model the useful one. In the example of a theatrical script, the audience-member often isn’t privy to the interpretive work of the actor and director; they are only able to form their own conclusions or receive the interpretations of the critic. Similarly, the user isn’t seeing how the compiler/hardware achieved or contorted the written goals of a program; they can perceive the functional output or listen to analysis. If we can reframe the role of the critic from a privileged position to that of another node in a network of sense-making collaborators, then we’re probably off to a good start.

Orla and Claire invite collaborators to continue the discussion at Code as Conversation: Transmedia Dialogues Around Critical Code Studies, a one-day conference at Cambridge Digital Humanities, which takes place on Saturday 1st June 2024 at the University of Cambridge. Check out the Call for Papers here and be sure to send in abstracts in by the deadline of Friday 15th March, 5:00pm GMT.

Cambridge Digital Humanities

Tel: +44 1223 766886
Email enquiries@crassh.cam.ac.uk