Codework

“Writing software is like any other kind of writing,” says Robert Martin in Clean Code: A Handbook of Agile Software Craftsmanship. “When you write a paper or an article, you get your thoughts down first, then you massage it until it reads well. The first draft might be clumsy and disorganized, so you wordsmith it and restructure it and refine it until it reads the way you want it to read.”1 I think he is right. After years in digital humanities (DH) classrooms teaching Perl, PHP, Python, JavaScript, R, and SQL to apprehensive new students, I have taken to structuring my DH programming courses around the notions of literacy and fluency, around expression and eloquence, around style and beauty. The more I emphasize language and writing over math and logic, the more success I have found. But the very premise of “coding as language” strikes new students as more than just odd—it is somehow, well, wrong. Isn’t programming really about math? Or tool building? Or entrepreneurship? Well, they reason, coding is just a skill anyway—like double-ledger bookkeeping or driving a manual-transmission car.

No. Coding is poetry. It is wordsmithing.

Others have made this argument before, of course, and remembering these forgotten connections has positive effects on our pedagogy. Humanities students can be inspired by the creative, artistic, aesthetic, Dionysian side of programming that has always, from the very start, coexisted with its more well-known, popular, starched, buttoned-down, serious, mathematical doppelgänger. A long, protracted struggle eventually declared one side the winner. At stake in that struggle was the creation of a professional discipline having all the familiar cultural accoutrements: jobs, privilege, titles, ranks, legitimacy. Erased in that history, however, have been gender politics, language, experiment, expression, argument, creativity—all the things we humanists like. This dualistic synergy between the scientific and the artistic was once neologized by Alan Sondheim as “codework.” According to Sondheim, codework is “the computer stirring into the text, and the text stirring the computer.”2

It is time that DH remembered those long-lost artistic roots of programming. Let’s bring creativity back into the classroom.

Your first assignment in this class is to collaborate with one other person to design and program an interactive story. A user should be able to launch your Python story, read along, and then make decisions about what happens in the plot. Depending on the user’s input, your story should follow different avenues of development and may even end quite differently. You can ask for lots of different kinds of information to customize the story in various ways.

The Python structures you’ll need for this assignment are variables and some logical control structures: if/else conditional blocks, of course, but maybe also loops like while or even for.

Begin this project by sketching out the general plot outline of your story, including the different branches that the plot can possibly take. Next, you’ll need to create and build the logical Python structures that implement the story.

If we accept that writing code is like writing a story or a poem, then it makes sense to teach its nuts and bolts as a series of lessons in lexicon, syntax, and grammar, and to consider its algorithms as a series of plot devices. If software really is the expression of an idea, then students will need to learn how to express themselves using the mechanics of this new medium. At their most basic, our common scripting languages really have only four expressive structures: data containers (variables), conditionals (if/else, also case or switch), loops (usually some combination of while, for, foreach, and the rarer do/while), and blocks of named code called functions (signaled by a keyword like def or sub or function).

In the classroom, the choice of apt metaphors helps to reduce the programming language learning curve. First, since there can be no free-floating data in a computer program, we need containers, or “data structures,” of various kinds: for singular data elements, we can use metaphorical buckets (called scalar variables in many languages); for sequences of things, we can use metaphorical filing cabinets (called arrays or lists or dictionaries or hashes). Second, programs need to make decisions with conditionals (if/else) so that stories or simulations or games or algorithms can take different courses of action depending on current circumstances. Third, programs will inevitably need to repeat certain processes with loops whenever we want to duplicate the same activity repeatedly—say, to perform some action on each of William Shakespeare’s plays or on every one of a million tweets. And, last, as programs grow, we will need to manage their complexity by modularizing them into smaller pieces, into discrete chunks of code called functions or procedures or subroutines. A program without functions is like an essay without paragraphs or a sentence without punctuation. Structure is important for both the writer and the reader. Code asks questions. Code expresses arguments. Code presents evidence.

Some humanists might claim this to be a bit of poetic license. After all, the notion that computation lives on the wrong side of the disciplinary tracks is ubiquitous. The nadir might well have been Stanley Fish’s relatively recent rant in the Chronicle Review that DH “is an anti-humanistic project, for the hope of the project is that a machine, unaided by anything but its immense computational powers, can decode texts produced by human beings.”3 Hardly. Or, comparably, those of us of a certain generation might even recall the once-popular Neil Postman noodle-braining that “there are . . . no ‘great computerers,’ as there are great writers, painters, or musicians.”4

The historical record speaks otherwise, of course. The alternate story’s origins have been eloquently detailed by scholars like Sadie Plant in her Zeros and Ones: Digital Women + the New Technoculture and James Essinger in Jacquard’s Web, both of which discuss poet Lord Byron’s daughter, Lady Augusta Ada, often touted as the first computer programmer, and her working relationship with inventor Charles Babbage. Closer to our own time, great computerers include Navy Rear Admiral Grace Murray Hopper, inventor of the English-like COBOL programming language, who famously introduced the term bug into our lexicon, and NASA programmer Margaret Hamilton, author of the software that launched Apollo 11 to the moon and coiner of the term software engineering.5 Both were awarded the Presidential Medal of Freedom, one of the two highest civilian honors the United States gives. They are, by any measure, great computerers.

That fuller historical record—read with more acumen, more perception—can help to inform our DH pedagogy today. We would not really be wrong to say, for example, that a recognizable form of modern programming started in World War II with the Bletchley Park circle, with the solving of the Enigma cipher, and with rooms full of computers—that is to say, women—using slide rules, building data tables, calculating Bayesian probabilities, and estimating missile trajectory charts. But the parallel history, that equally noteworthy intellectual tradition, the one going back at least to Lady Ada and the punched cards of Joseph-Marie Jacquard’s loom; back to the textile factories of the English midlands; back to the rise of Romantic, humanistic philosophy; back to the Luddite resistance to the Industrial Revolution, still shapes us. Much work has been done to recuperate these stories. A particular style of programming was born in those textile factories, encoded into those fabrics, woven by the laboring classes into the warp and woof of the intellectual DNA that we have inherited. Computing and humanism, born at the same time, in the same place, have always been twins. Courses in Romantic literature, far from the hurly-burly of Python, are terrific places to trace this history.

But by the postwar 1950s, the relationship had taken a turn that would ultimately affect our DH classrooms. Programmers were striving to masculinize this work, to mathematize it, to professionalize it, to install a sterner, stricter, more managerial ethos into membership associations and university curricula and granting agencies. Divided as it was between those who favored the theory of “hard” math and those who favored the praxis of “soft” software, postwar computing needed to tame one of its unruly siblings. At that time, as has been detailed neatly in Matti Tedre’s aptly titled book The Science of Computing: Taming a Discipline, “programming was—justifiably indeed—largely seen as a craft; as a domain of artistic talent.”6 Similarly, computer scientist John Backus has reminisced that “programming in the early 1950s . . . was a black art, a private arcane matter.” It had then, he has said, “a vital frontier enthusiasm virtually untainted by either the scholarship or the stuffiness of academia.”7

While Backus and his team were busy inventing the FORTRAN programming language, corporate management was already hard at work, tempering the chaos, hardening the subject. That they eventually won the day is readily apparent. Today, ranging everywhere from academic journals to popular culture, the inevitable result is obvious: the demise of coding’s mysterious arts and the ascendance of the mathematical. It has been an ideological shift in the broadest of terms, one that has successfully convinced—I would say, overconvinced—many humanists that programming is math, that the Midas touch of computation renders everything scientific and mathematical. And in the Hollywood version of this tale, the Oscar for Best Performance in a Supporting Role goes to the Fordist management regimes that have denatured programming into little more than an instrumental skill.

A few bright corners of academia took a different path. The classic success story is the 1964 invention of the BASIC programming language by professors John Kemeny and Thomas Kurtz at Dartmouth, one of the United States’ elite liberal arts schools. “Sooner or later, it was inevitable that someone would come up with a programming language aimed at beginners. But BASIC as it came to be was profoundly influenced by the fact that it was created at a liberal arts college with a forward-thinking mathematics program,” wrote Harry McCracken for Time magazine on BASIC’s fiftieth anniversary.8 The motivation was “a general belief on Kemeny’s part that liberal arts education was important,” said Dan Rockmore, then Dartmouth’s chair of mathematics.9

The simple fact that math won the day—at least in the popular consciousness of computing—makes our job harder, but not impossible. The trick is to find computational exercises that are solidly grounded in contexts and issues that are familiar to humanities students.

We’ll tackle a number of in-class coding projects this semester. I call these “code-alongs” because they’re a lot like campfire “sing-alongs” except that we’ll be writing code together as a group. No musical talent is required. Exercises are based on a short outside reading or two, so please read those before class so that you know what we’re doing. A few involve some additional outside research or a file download or the installation of a Python module. Go ahead and do those too so that you’re ready when we meet for class.

Our purpose is not just to learn more Python but also, as is common in the Digital Humanities, to use coding as a vehicle to explore ideas in more depth. We write code when we want to understand something more clearly or to model a phenomenon to see how it works. Notice that some of these exercises could expand into more formal academic essays—even, perhaps, into entire thesis or dissertation projects. I hope you can imagine ways in which these exercises could be scaled up into bigger projects.

Because it helps to watch programmers do what programmers do, we solve these code-alongs together every day in class, using them as ladders to learn more about the grammar and syntax of our chosen language. Through the activity of coding, we practice how to think about the issues at hand—how to define them, how to weigh them, how to assess them—never pretending that the code we write is merely a mathematical calculation that stands outside, or subordinate to, the questions we are asking. The short readings simply set the stage. We weigh an argument about Roger Maris’s 1961 Major League Baseball homerun record from Leonard Mlodinow’s The Drunkard’s Walk, which teaches us about variables and loops and what it means to build simulations of real-world events.10 We decrypt a secret message according to the frequency analysis techniques described in Simon Singh’s The Code Book, which introduces us to text parsing and to more complex data structures.11 We correct some badly OCRed text as outlined by Ryan Cordell’s “Q i-jtb the Raven” essay, which teaches us how to wrangle increasingly unwieldy data and how to choose algorithms that will improve both speed and accuracy.12 For many, it is the first time they have written code whose performance is so slow as to be above the threshold of human perception. Algorithmic efficiency suddenly matters because speed is something newly palpable. Given time, we also explore other topics: how to build a simple Bayesian machine learning classifier that predicts a movie’s genre given only its title, or how to program the computer to strategize against a human player’s unconscious biases in a game of rock, paper, scissors. We code by hand, from scratch, in order to better understand the concepts embedded in, and resulting consequences of, our projects. We code these exercises together, which provides plenty of opportunity to demonstrate and to discuss problem-solving strategies, coding style, variable scope, function abstraction, algorithms, command-line techniques, file paths, character sets, and a myriad of other issues that DHers face daily. A significant part of these exercises is blatant imitation. But another part is simply learning to make smart choices in our code. Every code-along fosters its own lessons.

The semester ends with a final project that invites students to explore a question or a debate or an issue—something grounded in some external research, something that explores a technique or a strategy that is useful for DH, and something that has, finally, some implications, either theoretical or practical, that are worth discussing in more detail.

The essence of digital scholarship (DS) is using computers to facilitate our own research by exploring ideas. That’s exactly what I’d like you to do for your final project. I’d like you to engage an issue or a question that interests you or, if you’re a graduate student, that perhaps forms a part of your thesis or dissertation project. Regardless, there will be some scholarly work surrounding your chosen issue and I’d like you to bring that research into your project for this class. The code you write should form a significant part of “thinking through” that issue or that question.

Our in-class code-alongs have provided a model of what I’d like to see in your final project. Each code-along we have done in class has been set up by, or framed by, an outside reading or two. Each project is grounded in some external research, explores a technique or strategy that’s commonplace in DS, and has, finally, some theoretical implications that are worth discussing in more detail. I’d like you to develop that kind of basic structure into an essay that frames, contextualizes, explains, and perhaps even justifies the code that you have written.

By the end of the term, the students see that the language part of programming language is not just metaphorical. The literalness of that equivalence, in fact, has informed the development of many of today’s popular programming languages and can help guide our pedagogy. For example, Yukihiro Matsumoto, known as “Matz,” inventor of the programming language Ruby, has argued for a renewed equivalence of coding and writing in “Treating Code as an Essay,” collected in the volume Beautiful Code: “Programs share some attributes with essays. For essays, the most important question readers ask is, ‘What is it about?’ For programs, the main question is, ‘What does it do?’ In fact, the purpose should be sufficiently clear that neither question ever needs to be uttered. . . . Both essays and lines of code are meant—before all else—to be read and understood by human beings.” Both forms of writing share similar qualities: clarity, brevity, elimination of redundancy, familiarity, simplicity, and flexibility. Matz’s language, Ruby, was designed specifically to personify these ideals. “Beautiful code is really meant to help the programmer be happy and productive. This is the metric I use to evaluate the beauty of a program.”13 Peter Cooper, author of Beginning Ruby, notes the uniqueness of the language: “Like the difference between spoken languages, Ruby differs from most other programming languages not only by syntax, but by culture, grammar, and customs.”14 Programming languages both shape and are shaped by their respective communities of practice—communities encompassing all levels from beginners to professionals, communities to which we can and should introduce our students.

Larry Wall’s Perl, the language I originally taught to humanists early in my career, is rooted even more deeply in natural language. A linguist by training, Wall has explained that “Perl is an ongoing experiment in how best to incorporate some of the principles of natural language into computer language.”15 Perl’s philosophy exemplifies several lessons Wall gleaned from linguistics:

• Expressiveness is more important than learnability.
• A language can be useful even before you have learned the whole language.
• There are often several good ways to say roughly the same thing.
• Languages naturally have slots for verbs, nouns, adjectives, adverbs, etc.
• The primary purpose of language is to communicate with people who are different from you.16

The list goes on and on. “Each of these principles has had profound influence on the design of Perl over the years,” Wall says. “For various historical reasons, many language designers tend to assume that computer programming is an activity more akin to an axiomatic mathematical proof than to a best-effort attempt at cross-cultural communication.”17

My students’ final projects drive home the parallel. DH codework is neither antihumanistic nor a betrayal of humanistic methods. Our pedagogy simply recaptures the artistic spirit of programming that some have been trying to drum out of the tradition for the last seventy years. We should seize every opportunity to recuperate that tradition, to weave it back into our pedagogical practices, to let codework shape insights, frame questions, and drive curiosity. Richard Hamming, the designer of more than a few eponymous algorithms, pointed out in the epigraph to his 1962 textbook, Numerical Methods for Scientists and Engineers—numerical methods, mind you—that “the purpose of computing is insight, not numbers.”18 And in the 1990s, Daniel Hillis quipped that “if we had named the two possible messages conveyed by the bit the letters X and Y, people would be saying, ‘The computer does everything with letters.’”19

The student projects are astonishing in their breadth and depth. As might be expected, text analysis is popular: ranging from tf-idf word lists in Arabic corpora, to sentiment analysis in subreddit threads and in horror film scripts, to Markov chain Twitter bots autogenerating surrealist dreamscapes. Some students track and catalog rhetorical differences between right-wing and left-wing commentators on YouTube, while others try to decipher whether the posts themselves have been made by real people or bots. Social networks are gaining popularity: whether to explore the Bechdel test in Hollywood films, to chart Game of Thrones relationships, or to trace social media influencers. One student built a prototype to explore whether blockchain might be a useful way to store library catalogs. Another used open-source computer vision libraries to improve the OCRing of political letters to the editor in Kenyan newspapers.

Once I pointed the students to the long history of humanities in computing, we were immediately overwhelmed by the historical evidence. We noticed that prominent computer scientist Donald Knuth’s algorithmic magnum opus, whose publication began in 1968 and still remains incomplete today, is titled The Art of Computer Programming. In classifying and architecting the structural analysis of algorithms, Knuth has become, in effect, the Vladimir Propp of algorithmic theory. Later, in 1984, Knuth started to advocate “literate programming,” which he suggested was best achieved by “considering programs to be works of literature,” reasoning that “the practitioner of literate programming can be regarded as an essayist, whose main concern is with exposition and excellence of style.” The literate programmer strives for comprehensibility, Knuth argued, “with thesaurus in hand.”20

We learned that Brian Kernighan and P. J. Plauger’s 1974 book, The Elements of Programming Style, patterned lessons for programmers explicitly after similar lessons found in William Strunk and E. B. White’s classic 1959 text, The Elements of Style. Kernighan and Plauger noted that they “have tried to emulate [Strunk and White’s] brevity by concentrating on the essential practical aspects of style.” “Good programming cannot be taught by preaching generalities,” they maintained. “Practice in critical reading leads to skill in rewriting, which in turn leads to better writing.” Toward that goal, their book performed close readings of published computer code in then-popular languages like FORTRAN and PL/I and discussed pithy rules of thumb like Avoid temporary variables and Don’t sacrifice clarity for “efficiency” and Don’t patch bad code—rewrite it. Some of their advice, as would be expected, still cannot make the full circle back to English from code: Use recursive procedures for recursively-defined data structures and Test programs at their boundary values. “The essence of what we are trying to convey,” they conclude, “is summed up in the elusive word ‘style.’”21

In more contemporary academic circles, Annette Vee has recently made a compelling case for computer programming as a form of literacy and as the literal encoding of a particular community’s values. In Coding Literacy: How Computer Programming Is Changing Writing, she recognizes that “programming as defined by computer science or software engineering is bound to echo the values of those contexts.” She continues, “But a concept of coding literacy suggests programming is a literacy practice with many applications beyond a profession defined by a limited set of values.” Literacies of all types have always been ideologically driven, she notes. Moreover, “literacy” remains a moving target insofar as it is always pointing toward what should be considered morally or socially or economically good. But if wider cultural literacies have often tended to marginalize vulnerable groups, then the DH classroom can do good work by altering the political stakes, especially for those struggling the hardest to gain entrance: usually those who are “disproportionately poor, women, or people of color.” Reconceptualizing coding as a transformative literacy “also offers fresh approaches to teaching programming—programming not as a problem-solving tool, but as a species of writing.” “When we consider programming a mode of written communication,” she says, “it is no longer bounded by the field of computer science. Its roots are no longer solely in math, engineering, and science; they include written communication as well.”22

A newer entry in our lexicon is computational thinking, which Peter Denning and Matti Tedre have defined as “the mental skills and practices for designing computations that get computers to do jobs for us, and explaining and interpreting the world as a complex of information processes.”23 In both these senses, DH programming already exemplifies computational thinking: the humanistic design of research questions, modes of exploration, the aggregation of evidence, all combined effectively with humanistic explanation, those familiar paths of hermeneutical interpretation and examination that culminate in essays, arguments, and points of view. Denning and Tedre’s claim is that twentieth-century computational thinking ushered into the sciences a radical new methodology: “For centuries, theory and experiment were the two modes of doing science. Supercomputers changed this, opening a new approach to doing science based on computational exploration and modeling. It was the most significant scientific paradigm shift since quantum mechanics.”24

Codework both embodies and transforms the humanities’ two dominant modes of inquiry: reading and interpretation. The digital humanities have evolved beyond just counting things. We are building models and simulations, using networks to analyze both the close reading of texts and their circulation among historical readers, visualizing arguments in charts and graphs, fostering collaborative scholarship, borrowing interdisciplinary methods, and scaling our research domains up to “big data” proportions.

Perhaps the most contentious issue in this more recent shift, however, has been the representation of our objects of study as information, the reconfiguration of the world around us as a series of what Denning and Tedre call information processes. Everything we study—literature, tweets, court transcripts, film, history, personal correspondence, music, sporting events, language, painting, politics, dance, games, and so on—must be encoded as information. These real-world phenomena become bit sequences—text files, multimedia streams, spreadsheets, networks, visualizations—all of which must run the gauntlet of a limited and small set of data structures. This symbolic representation, it seems, is the rub for many humanists. For Stanley Fish, someone for whom the computer is nothing more than a bean-counting calculator, a tidy reductio ad absurdum argument leads neatly to a conspiracy theory: “One could just count things and go directly from the result to a statement of what Paradise Lost means. That is the holy grail of the digital-humanities project.”25

And so DH finds itself these days in a perplexing landscape, one where it now experiences its share of backlash. But it also finds allies, sometimes in strange places. That Knuth, winner of the prestigious A. M. Turing Award, “the highest honor in computer science and often referred to as the field’s equivalent of the Nobel Prize,” could suggest that a literate programmer’s “main concern is with exposition and excellence of style” proves him to be a collegial friend.26 And who needs enemies when the consummate humanist, the author of Surprised by Sin and Is There a Text in This Class?, finds us to be “complicit in the killing of the humanities”?27 The more forward-thinking Jeffrey J. Williams recently described, in the Chronicle of Higher Education, “a new kind of humanities,” a “wave of hybrid fields such as the digital humanities, environmental humanities, energy humanities, global humanities, urban humanities, food humanities, medical humanities, legal humanities, and public humanities”—all of which, he says, “emphasize commerce between other disciplines, particularly STEM or professional fields, and humanistic ways of thinking.”28

Reframing the pedagogy of DH programming situates us in this broader landscape, allows us to nurture humanistic thinking by resurrecting the mysterious arts of coding, by understanding code as a mode of communication, as a style of thought, as a vehicle of expression and of exploration. My programming classes all embrace the premise that DH programming cannot be divorced from our other interpretive activities. Embedded in our familiar humanities scholarship, DH codework succeeds. It fails when we remove it from that context, when we set it to the side and treat it as secondary or merely instrumental. And when students are genuinely curious about their research topics, they discover new ways to integrate coding and data visualization and computational analysis into their work, which in turn reveals new insights for them. When coding, they are inevitably surprised by the process and discover happily that they have plenty of new things to say. To encourage that result, DH coding cannot be treated as a mere supplement to scholarship. It is the scholarship. Code embodies the interpretive strategies that the students bring to their research; it reifies and makes obvious our assumptions, agendas, biases, subjectivity. Students cease to see code as a “neutral” tool that simply brings down the big hammer of objectivity. Humanistic theory and digital praxis shape each other symbiotically and synergistically. Coding becomes a new way for them to think about the boundaries and purposes of the humanities.

At this precipitous moment, both inside and outside academia, reframing the humanities is an especially consequential action. DH programming might be too easily dismissed by some as an instrumental skill, too casually disregarded as a form of curricular micropolitics, too naïvely misrecognized as numeric. But the stakes are high, just as they were two hundred years ago when the Luddites hived off the arts and humanities as being somehow separate from, and resistant to, the technologies of the wider world. Through our digital work, we have an opportunity now to make a different choice. “Master programmers think of [software] systems as stories to be told,” said Robert Martin, “rather than programs to be written. They use . . . their chosen programming language to construct a much richer and more expressive language that can be used to tell that story.”29 It is time for the digital humanities to recode these old stories into our new pedagogies.