Scott Dexter Department of Computer and Information Science Brooklyn College of CUNY Brooklyn, NY USA [email protected]

Toward a Poetics of Code What does knowledge do—the pursuit of it, the having and exposing of it, the receiving again of knowledge of what one already knows? How, in short, is knowledge performative, and how best does one move among its causes and effects? — Eve Kosofsky Sedgwick

James Hixon, reflecting on these questions, notes that, “Sedgwick encourages us to think about knowledge as something that does, rather than something that is.” But software is easily, if incompletely, understood as a kind of crystallized knowledge; most of our study of software, in computer science and beyond, is predicated on an understanding of it as a thing that does, with relatively little attention paid to what—or how—it is. In this project, we propose to ignore what it is that software does. Instead, we focus on what software is and the nature of its making: its poetics. Thus, the locus of our study is not software-in-execution but software-in-creation, or source code.

1. Introduction: Suspicion and Revelation Software is, certainly, much more than source code. It carries culture; it is Manevich’s metamedium. It tacitly and sometimes explicitly governs us; it is Lessig’s law. It is science and art and politics on scales grand and humble. Further, these myriad meanings of software cannot be read off the source code: they depend irreducibly on infrastructures of data, communication, politics, and affect. Just as a work of literature or a musical composition can be understood only at the most shallow level when read merely as a sequence of tokens, source code is only the source of meanings which emerge and erupt when the code entangles machines and minds. Yet the processes of creating these token streams—whether literary, musical, or executable—both anticipate their eventual meanings and are of interest for their own sakes. The politics and pragmatics of creation— the embodied aesthetic experience of production; the shifting roles of creator, collaborator, and audience; the material conditions embedding the work—these have everything to do with the meanings which inhere in and accrete to the created work, as well as with the ontology and ontogeny of genre. Sedgwick poses her questions in the course of interrogating the paranoia she finds embedded in contemporary critical practice. Her opening exemplum is a conversation about whether the AIDS virus is the product of a government/military conspiracy: whether this devastating immunological hack is an intentional genetic hack perpetrated against already-oppressed communities. What would certain knowledge about this do for us? she asks. “[I]t is possible that the very productive critical habits embodied in what Paul Ricoeur memorably called the ‘hermeneutics of suspicion’ . . . may have made it less rather than more possible to unpack the local, contingent relations between any given piece of knowledge and its narrative/epistemological entailments for the seeker, knower, or teller” (124). This hermeneutics demonstrates a strong affinity for guile, concealment, mystification, for code: “the fundamental category of consciousness is the relation hidden-shown . . . the distinguishing characteristic . . . is the general hypothesis concerning both the process of false consciousness and the method of deciphering” (Ricoeur 34–5, qtd. in Sedgwick 125). This project takes as axiomatic the value of this unpacking when applied to the knowledge represented through source code and those who

seek, know, or tell it. In My Mother was a Computer, Hayles observes, “[R]evealing code when it is appropriate or desired also bestows significant advantage. The ‘reveal code’ command in HTML documents . . . may illuminate the construction and intent of the work under study” (54). Of course, this is not a command that resides in HTML documents themselves but is a functionality that is traditionally offered by web browsers. Nor is it identified as “reveal code”—rather, that is a functionality famously offered by WordPerfect, whose absence in other word processing applications is an occasional cause of lamentation—but generally as “view source” or “page source.” Suspicion appears to be a very comfortable position indeed from which to undertake a study of code! Hayles goes on to suggest that widespread acceptance of the “worldview of code” may further naturalize the “concealing/revealing dynamic” even down to the level at which “the universe generates reality” (55). And here lie foundational questions for this project: If code threatens to buttress paranoia, to what extent is this paranoia originary in the poetics of code and to what extent are these poetics reproducing prior habits of thought? Can we find a critical posture toward code that is “reparative” in Sedgwick’s sense of the term?

2. The Embodied Programmer “Among the five assembler programmers of the project team there was one who one night sat down at the terminal, got glassy eyes, and slipped into a mental state in which he could not be talked to any more. . . . Among his colleagues the man was called the ‘trance programmer.’ He once commented . . . ‘You could fire a cannon next to me and it would not bother me’” (Molzberger 247). While code is a necessary component of the infrastructure of “cyberspace,” of the “virtual sphere,” of that presumably disembodied plane which we access through the grace of software, software developers do not always understand their work with code as taking place within this sphere. Reports, such as those above, of programmers reaching a state in which they realize the unity (or nullity) of body and mind are not uncommon. And many scholars of code find some utility in thinking about code as something existing primarily in some immaterial mathematical/Platonic realm, along with the golden ratio, Euclid’s technique for finding the greatest common divisor of two non-zero integers, and perhaps even Adelson-Velskii and Landis’s suite of techniques for organizing information. But code is, obviously, produced by humans and human-made tools, ever subject to inescapable physical constraints: space, distance, time, heat. Less tangible constraints of “correctness” serve to illuminate the role of human limitation in the production of code, though even this intangibility is a recent development: The term “bug” as a catch-all for software problems of various sorts is borrowed from a much older tradition in engineering of resolving “bugs” in physical realizations of designs, and even the mythology of the software bug is grounded in the story of the body of a moth interfering with the mechanism of an early computer (“Software Bug”). Code diverges from the ideal precisely because of these constraints of materiality and embodiment, and it is through these constraints, this distance, that code offers up its meanings. Software engineer Richard Gabriel observes that many bugs arise not because humans are fallible but because we are not omniscient: “Many a bug is the result of not anticipating a particular event or use and is not the result of a mistake—bugs are not always errors. Bugs tell us that we are not capable of producing a master plan” (13, his emphasis). Gabriel, following the work of architect Christopher Alexander, proposes a deeply embodied metaphor for working with code: habitability. “Habitability makes a place livable, like home. And this is what we want in software—that developers feel at home,

can place their hands on any item without having to think deeply about where it is. . . . Programs live and grow, and their inhabitants—the programmers—need to work with that program the way [a] farmer works with the homestead” (12). Indeed, writing code has always relied heavily on a material substrate: coding sheets, punchcards, teletype interfaces, increasingly sophisticated visual representations of code-in-progress. How does the embodied experience of programmers as author/inhabitants define, constrain, and thereby produce meaning in code?

3. Code and Performance Writing code has, as well, relied on literary traditions of authorship and analysis—as one example, the tradition of commentary and annotation, which code adapted as it arrived to a quasi-textual form, which Knuth revisited through the notion of “literate programming,” which reached an apotheosis of sorts with the publicly performed commentary on discussion drafts of version 3 of the GNU General Public License. How do the authorial/creative practices employed in the development of code engage the pre-history of code, and how do they in turn inform “digital poetics” more broadly construed? As Florian Cramer points out, “computer control language is language that executes. As with magical and speculative concepts of language, the word automatically performs the operation. Yet this is not to be mixed up with what linguistics calls a 'performative' or 'perlocutionary' speech act,” because the operations of the machine have no a priori social meaning. Software engineer Ellen Ullman concurs: “[A] computer program has only one meaning: what it does. It isn’t a text for an academic to read. Its entire meaning is its function” (qtd. in Hayles 48). But these notions of (non)performativity engage code as a finished product, if not a raw material. Yet code—source code—certainly has audiences for which it performs. The “recursive public” (Kelty) of free software is the most obvious contemporary example, though broad, trans-institutional collaboration has been a significant mode of software development since at least 1955 (Akera). Proprietary code, by definition potentially visible to fewer people than free software, nonetheless relies heavily on its audience. One of the many concerns of software engineering as an area of study and of practice is how to structure the developers on a project so that code is exposed to a critical audience as effectively yet efficiently as possible. One extreme example is the practice of ‘pair programming,’ in which one developer writes code while the other looks on and strives to provide constructive critical feedback. Even the most private solo programming efforts have an audience: anyone who has written code for themselves knows that the closest reader, the harshest critic, is yourself, six months from now. This concept of an audience which is invited, if not in fact expected, to modify the work being performed is integral to a broad swath of digital art; Kristie Fleckenstein takes this up under the rubric of “digital poetics.” She focuses particularly on the interactivity afforded by web-based publication of poems, especially forms of interaction which allow the “audience” to modify the work. “The phenomenon of deliberate interactivity raises intriguing questions concerning identity—ethos—and ethics: who is writing and who is taking responsibility for the writing?” While not all source code is available to view by anyone interested (unlike the work of these digital poets), in general, anyone who is permitted to read source code, anyone in “the audience,” is potentially involved in modifying the work, perhaps as a co-developer, or as a code reviewer, or as a bug reporter. Thus, code has a much longer history of this kind of interactive digital poetics, although the author position in this domain may not have been problematized as rigorously. This gives rise to another complement of questions for this project: while the web, and perhaps free software in particular, have provided and inspired new modes

of interactive and collaborative reading and writing, what else can we learn about these modes by reading the history of software “authorship” through their lens? And, dually, what can we learn about the living history of software development by translating techniques and insights from literary analysis, such as Fleckenstein’s application of classical rhetoric, into the domain of source code? Fleckenstein’s analysis returns us to the connection between the activities of author and audience “in cyberspace” and material conditions and action “in the real world:” “Aristotelian ethos belies the specious separation between virtual and material. One listens and sees as a rhetor because one speaks and displays as a citizen. Applied to digital poetics, this perspective induces a netizenship where one's actions in the virtual sphere cannot be separated either from the configuration of that virtual sphere or from the configuration of the real world.”

4. Conclusion: Code as Body Mark Johnson, echoing Drew Leder’s work in The Absent Body, suggests that our survival depends on the experiential invisibility of our bodies: “Our intentionality seems to be directed ‘out there’ into the world. The mechanisms of our vision are not, and cannot be, the focus of our awareness and attention. . . . The bodily processes hide, in order to make possible our fluid, automatic experiencing of the world” (5). Johnson’s project, the demonstration of the bodily foundation of meaning, is an attempt to repair a fault in our understanding of embodiment, to show that what appears to be hidden in fact manifests more subtly and powerfully than we guess. Code, too, appears to hide, perhaps in order to make possible a more fluid and automatic extension of our creative and cognitive capacities. What meanings will emerge when we direct our awareness and attention to the body of code? Works Cited Adelson-Velskii, G. and E. M. Landis. "An algorithm for the organization of information." Proceedings of the USSR Academy of Sciences 146: 263–6. Trans. J. Ricci in Soviet Math. Doklady, 3:1259– 63, 1962. Print. Akera, Atsushi. “Voluntarism and the Fruits of Collaboration: The IBM User Group, Share.” Technology and Culture 42.4 (2001): 710–36. Print. Cramer, Florian. “Language.” In Software Studies: A Lexicon. Ed. M. Fuller. pp. 183–74. Cambridge, MA: MIT Press, 2008. Print. Fleckenstein, Kristie. “Who's Writing? Aristotelian Ethos and the Author Position in Digital Poetics” Kairos: Rhetoric, Technology, Pedagogy 11.3 (2007): n. pag. Web. 11 Nov. 2009. Gabriel, Richard P. Patterns of Software: Tales from the Software Community. Oxford: Oxford U.P., 1996. Print. “GNU General Public License: Discussion Draft 1 of version 3.” Free Software Foundation. 16 Jan. 2006. Web. 10 Feb 2010. . Hayles, N. Katherine. My Mother was A Computer: Digital Subjects and Literary Texts. Chicago: U. of Chicago P., 2005. Print. Hixon, James. “Bodies Into Bits: A Reparative Approach to Informationalizing the Body.” UC Los Angeles: UCLA Center for the Study of Women, 2009. Web. 4 Jan. 2010.

Johnson, Mark. The Meaning of the Body: Aesthetics of Human Understanding. Chicago: U. of Chicago P.: 2007. Print. Kelty, Christopher M. Two Bits: The Cultural Significance of Free Software. Durham: Duke U. P., 2008. Print. Knuth, Donald E. Literate Programming. CSLI Lecture Notes, no. 27. Stanford, CA: Center for the Study of Language and Information, 1992. Print. Leder, Drew. The Absent Body. Chicago: U. of Chicago P., 1990. Print. Lessig, Lawrence. Code and Other Laws of Cyberspace. New York: Basic Books, 1999. Print. Manevich, Lev. Software Takes Command. Web. 4 Jan. 2010. Molzberger, Peter. “Aesthetics and programming.” In Proceedings of the SIGCHI conference on Human Factors in Computing Systems (1983): 247–50. Boston, MA. Print. Ricouer, Paul. Freud and Philosophy: An Essay on Interpretation. Trans. Denis Savage. New Haven: Yale U. P., 1970. Sedgwick, Eve. Touching Feeling: Affect, Pedagogy, Performativity. Durham: Duke U. P., 2003. Print. "Software Bug." Wikipedia: The Free Encyclopedia. Wikimedia Foundation, Inc. 9 Feb. 2010. Web. 12 Feb. 2010.