Code and codework share many properties with text and writing, and code can be seen as an argument, corresponding to Galey and Ruecker’s (2010) understanding of the epistemological status of graphical user interfaces as argument. From an epistemic point of view, the practice of a programmer is no different from the practice of a scholar when it comes to writing (Van Zundert, 2016). Both are creating theories about existing epistemic objects (e.g. text and material artifacts, or data) by developing new epistemic objects (e.g. journal articles and critical editions, or code) to formulate and support these theories. However, as expressions of a technē whose inner workings are opaque to most humanities scholars, code and codework are all too often treated as an invisible hand, influencing humanities research in ways that are not transparent. The software used in research is treated as a black box in the sense of information science—expected to produce a certain output given a certain input—but at the same time often mistrusted precisely for this lack of transparency.

The digital humanities (DH) does not generally engage with the code and coding parts of programming in an explicit and critical manner, which is necessary for opening up black boxes of code. The invisibility and un-critiqued use of code means that the scholarly quality and contribution of codework goes both uncredited and unaccounted for. Black-boxing the code results in neglect of its epistemological contributions and imperils one of the key components of knowledge production in the DH. Much more insight into code and codework in the humanities is needed, including how coders approach their tasks, what decisions go into its production, and how code interacts with its environment.

The purpose of this paper is to provide some of those insights in the form of an ethnography of codework, wherein we observe the decisions that programmers make and how they understand their own activities. Our study follows in the footsteps of ethnographies of technoscientific practice (see: Forsythe, 2001; Coleman, 2013), Critical Code Studies (see: Marino, 2014), and reflections on coding and tool development in the DH (see: Schreibman and Hanlon, 2010; Ramsey and Rockwell, 2012). The study does not aspire to be representative of the DH coding practice, but to initiate a debate about some still overlooked elements of that practice.

This exploration applies Latour’s (1998) first rule of method to the context of narrative creation through codework, looking at the practices, dilemmas, and decisions of programmers. To do that, we use analytical autoethnography (cf. Anderson, 2006), combined with collaborative ethnography (cf. Lassiter, 2005). In our methodological design, the team ethnographer first formulated a set of ten questions aimed at generating reflexive accounts and examples of DH coding in the making. Each of the team DH programmers then individually answered the questions in a written form, providing elaborate, semi-formal accounts of his or her DH programming practice. Thus generated written accounts became the basis for a series of team discussion, both written and oral, which eventually formed the results of this contribution. This methodological design enabled us to return from the final outputs of DH coding to scholarly uncertainties and resolutions that preceded them. Through such reconstruction, we were able to document some of the key phases in epistemological construction of coding artifacts, and to identify methodologically significant moments in stabilization of those artifacts. In other words, we relied on the experiences of scholars proficient in both humanities research and coding seeking to make explicit what DH coders themselves know, maybe tacitly, about why and how they code.

We have grouped our observations into the categories known as the five canons of rhetoric, proposed in Cicero’s
De Inventione. Although originally developed for public speaking, these canons have proven to be equally potent heuristic in analyzing written and, more recently, digital discourse (Gurak and Antonijevic, 2009). Our contribution sought to extend this heuristic to the analysis of coding as argumentation, not in an attempt to fit codework and its elements into a pre-defined ontology, nor to suggest that it fully conforms or matches classical rhetoric. Rather, it was a way of presenting our experiences and claims in a form that we expected to facilitate interpretation by scholars well versed in text production but likely less so in codework.

Our study showed that codework reflects humanistic discovery (
inventio) in that humanities- specific research questions drive coding, and tasks specific to the humanities research motivate software development. Similarly, crafting and organizing code resonates with development and arrangement of a scholarly argument (
dispositio)—a programmer writes lines of code and makes many decisions on how to arrange these pieces into larger, meaningful constructs that influence the epistemological and methodological structure of research. Our study also illustrated that, like any humanities scholar, an author of software has her own style (
elocutio) in the aesthetics of code and in her way of working to create code, and this style develops through both individual and norms of coding communities. We also showed that, parallel to books or libraries, code and codework serve as memory systems (
memoria) that embed theoretical concepts in order to augment research methodology and create new theory, where code can be regarded as a performative application or explanation of theory. Finally, our ethnography illustrated how codework
actio compares to the publication and reception of the software, where DH programming is still not recognized as a locus of humanities expertise, and it is hard for humanities programmers to have their code academically evaluated as digital output.

The insights of our study demonstrate that both code as an epistemic object and coding as an epistemic practice increasingly shape research in the humanities and must be given a proper theoretical and methodological recognition in the DH, with both the consequences and the rewards that such a recognition bears. Therefore, a strategy for making code and codework visible, understandable, trustworthy and reputable within humanities scholarship is needed. Such a strategy should be comprehensive, both in the sense of accounting for the source code and the executed result of software. While we agree with Ramsay and Rockwell (2012) that providing source code is not sufficient for understanding the underlying theoretical assumptions, we disagree in viewing the “dependence on discourse” as a feature that relativises epistemic and communicative capacities of code and codework. We argue in contrast that interdependence of code and text should be embraced as a means of acknowledging their distinctive yet corresponding methods of knowledge production and communication. Just as code enhances text making it amenable to methodological and epistemological approaches of DH, text enhances code making it more visible and intelligible for the humanities community. Evaluating code and DH programming in a disengaged way would thus be similar to the literary criticism enacted on a novel without reading it. Yet currently it is practice to “criticize” software and code based only on a journal article that derived from it. As much as possible, coders should support the involved evaluation of code as opposed to its disengaged criticism. We believe that theoretical discussions of codework should become an established trajectory in the humanities, along with the development of methods for documenting, analyzing, and evaluating code and codework.

One important element of that strategy is understanding codework as necessarily shaped by its social context, which influences the attitude and perception that both coders and other scholars hold towards their work. Too often, DH programmers are treated as service instead of research focused scholars, which results in a number of negative consequences. A necessary step in the direction of a real change in how codework is received into the humanities is recognition and reward for peer-reviewed digital outputs, including code, as research outputs (cf. Nowviskie, 2011; Presner, 2012; American Historical Association, 2015). A precondition for this is to start grassroots procedures for peer review of code (Fitzpatrick, 2011), and to regard the code as alternative expressions of research or epistemologies with equal research value and validity instead of subordinating code and codework to ‘humanities proper’ (cf. Burgess and Hamming, 2011 and Ramsay and Rockwell, 2012). There is a need for peer review and critical examination of actual code, which is hardly even present in DH (Zundert and Haentjens Dekker, 2017). Also, open publishing of code in verifiable ways can be easily facilitated through existing public code repositories or institutionally-run versions of the same repositories, but it is not common practice throughout the humanities to publish code. Finally, reflexive accounts on (digital) humanities codework and ethnographic studies of actual work can help us understand how code and codework are changing the humanities (Borgman, 2009). We believe that an important step in illuminating the process and results of DH programmers’ codework is to develop and explicate reflexive insights into its key epistemological, methodological, and technical aspects. Explaining, for instance, what kind of research questions give impetus to one’s codework and how new research insights co-evolve during code development can help both DH programmers and their traditionally trained colleagues recognize the important epistemological connections between humanistic theory and scholarly programming.