Digital humanities is a field that makes us self-conscious about our jobs. In my contribution to Matthew Gold’s “Debates in the Digital Humanities” I spent several thousand words anatomizing the different roles I’ve played and their different institutional frames, modes of work, funding structures, and systems of credit. In this I was participating in a long tradition of introspection that began with discussions about whether humanities computing was a discipline and whether it should find its most characteristic and beneficial home in humanities departments, libraries, IT departments, or some other academic or para-academic space altogether.
By the time I was in a position to write with any experience on the subject, the answer was clearly in some sense “Yes!” and “all of the above”: for instance, the Women Writers Project has been located in all four types of space and there are vibrant examples of digital humanities centers, digital scholarship centers, digital archives, digital initiatives, digital collaboratories, and many other units located in all different kinds of institutional spaces. It’s also clear that the identity crisis the field experienced so early on (I’m not a faculty member! My job is in an IT unit! but I have a PhD in classics! Is what I’m doing research?) has matured not through a clean resolution but through a proliferation of professionally viable options and job types: the digital humanities librarian; the instructional technologist; the digital humanities project manager; the professor of XYZ and digital humanities; the director and associate and assistant director of DH centers; the DH developer, and so forth.
Asking the question “What is DH?” (and either evading or reframing or attempting to answer it) is a popular pastime, could almost be a drinking game in some contexts. But looking at this landscape, we might be more inclined to ask “Who is DH?” or ‘How is DH?” All of these roles have proven themselves necessary or at least possible: in various configurations they form more or less stable local ecologies in which roles and skills are allocated based on conditions of institutional possibility (who has the funding, who has the will, who has the imagination, who has the open staff lines, who has the office space, who has the research project). But this observation is equivalent to saying “stuff happens where it happens”: it doesn’t help us understand how to design such configurations, or how to adjust them when they turn out to be unstable or toxic, or how to form ourselves professionally to occupy a particular niche.
Looking at this landscape with an eye to understanding how these ecologies work, what we see first is jobs. But jobs (though fascinating in their own right) are not the most useful unit of meaning here: for one thing, as we all know, specific jobs come into being in particular shapes and sizes for reasons that have more to do with occasion and accident than with ontology. Jobs are actually aggregations of roles—specific vectors of participation in the ecology—and of skills—the competencies needed to perform the role effectively.
This line of discussion has you all worried that I am actually from an HR department. But in fact I’d like to suggest that if we’re interested in understanding how digital humanities works as a field, these roles and skills (properly unpacked) hold the key to that understanding. Consider the following questions:
- At what point in a digital project work flow should texts be proofread, and by whom? In what form should the data be exposed for this work to proceed effectively?
- Is text encoding integral to digital scholarly editing, or an implementation of it?
- To what extent do scholarly users of a digital resource need to understand its use of metadata standards?
- How can the underlying information architecture of a digital edition effectively represent its editorial principles?
- When a work of digital scholarship is complete and its original researchers have retired, who takes responsibility for it and where in the institution does that responsibility lie? How substantively can we expect those with long-term responsibility to maintain and extend the resource?
- Do we need to understand the complete inner workings of our digital tools in order to use them responsibly and critically?
- With whom does final intellectual responsibility for a digital humanities project lie? In what specific components of the project does that intellectual responsibility make itself felt?
Given time, we could design an interesting small-group workshop exercise to diagram those questions out as implied relationships between different institutional roles and skills, and in doing so I think we would find that the roles we identify (for instance, the potential librarian presence in items 3 and 5, or the potential programmer role in items 1, 4, and 6) aren’t represented by the same skills across the board. Similarly, the same skill (e.g. knowledge of scholarly editorial principles) doesn’t necessarily map to the same role in every case. So understanding roles and skills and their configurations can help us think more precisely about terms like “collaboration” which I think gets used far too often in far too facile and imprecise a manner.
But there another term lurking in this list which I think is also significant, namely “tools.” Digital humanities has a keen awareness of tools as a marker of difference from the “traditional humanities” and a deep self-consciousness about tools as a marker of expertise, without really being certain what that expertise says about us. I’ve listened with fascination when speakers at conferences preface a comment by a phrase like “I’m not an engineer, but…” What this phrase means is “I don’t have technical expertise but in fact this makes me a more credible commentator on the non-technical aspects of the issue here…”
So in what follows I’m going to use jobs, roles, skills, and tools as a way of teasing apart this complex ecology and helping us understand it better.
From Jobs to Roles
Is humanities computing merely a hobby for tenured faculty? I am beginning to think so. I have just finished looking through the October MLA job list along with the computer science equivalent. As in past years, I see no jobs relating to humanities computing. At best, there are 1 or 2 positions where experience in computer aided instruction might be helpful. … I started out as a German professor here at Yale and then was, in effect, booted out when I consorted with the CS people. Now I am a full-time lecturer in computer science, teaching a curriculum of humanities computing along with regular CS courses… But I am also painfully aware of the fact that I have this job because I MADE this job, and it took 5 years of continuous drudge-work and diplomacy to get to this point. …I can tell you this: if humanities computing is to be more than a gentleman’s sport, somebody has got to start creating jobs for this field. How many more Goethe specialists do we need? Give it a rest. Hire someone who will rock the status quo. …20 years from now there will be departments of humanities computing. No doubt someone will write a doctoral thesis on the history of the field and my name will appear in a footnote: “wrote some interesting early works, ‘German Tutor’, ‘MacConcordance’, ‘Etaoin Shrdlu’, and then disappeared from the field”. I don’t want to be a footnote. I want to be the head of the department. Make a job in humanities computing this year.”
—Stephen Clausing, Humanist Vol. 6 Num. 357, 15 Nov 1992 (emphasis mine)
Jobs are a good starting point here because they are easy to detect (especially when they are missing). This quotation is curiously telling: even while calling for “a department of humanities computing” (i.e. more faculty jobs, but representing a hybridization of humanities and CS expertise), it subtly registers the fact that the very “gentlemanliness” of the faculty jobs (and the way they would tend to position the more practical aspects of building, teaching, and using technological systems) might not in fact serve humanities computing very well in the long run. With hindsight, we can also note that in fact the jobs that first proliferated were not in fact faculty positions; there were plenty of faculty in humanities computing early on but they all had quite standard jobs and their “computing” dimension was acknowledged as odd. The distinctively “humanities computing” (or, later “digital humanities”) jobs were in other institutional spaces:
- library positions, particularly around library-led digitization efforts like UVA’s EText Center but also in some cases as an outgrowth of library support for digital publications and projects (for instance, IATH, MITH)
- information technologists: arising in groups dedicated to supporting faculty research (e.g. STG, OUCS, Centre for Computing in the Humanities @ KCL
- instructional technology groups, for instance at Northwestern University, University of Virginia, and NYU
- research groups, either free-floating or located in departments: e.g. ARTFL, the WWP, Perseus
And these categories of jobs have now solidified around a set of parameters that match the institutional spaces where these jobs are located. It’s also worth noting that the jobs we think of as “alt-ac” (jobs that humanities PhDs might consider as alternatives to tenure-track faculty positions) had in fact been around for quite a while before that label was invented, and there was nothing particularly “alt” about them: they are in an important sense the infrastructure of the academy. Their “altification” is in the eyes of those now seeking those jobs: people with humanities PhDs who see them as an alternative to faculty jobs.
If we map these out organizationally what we start to see is that certain kinds of positions are replicated in multiple organizations: notably developers, analysts, and support staff, and that in fact “research centers” can be located pretty much anywhere (and bring their characteristic staff with them).
So to get at the real categories that are emerging here, we need to remap these by job type rather than by organizational unit (I’m giving broad characterizations here)
- information management jobs: emphasis on maintaining healthy information ecologies for the institution
- faculty/academic jobs: emphasis on research and teaching
- analyst jobs: these are the jobs with responsibility for translating between competencies and thinking about systems
- technical or “developer” jobs: these are the “building” jobs that typically involve deeper programming expertise
- managerial jobs: oversight over working groups and work systems
- administrative jobs: oversight over resources, fiscal and legal arrangements
- data creation jobs: those involving digitization, encoding, metadata creation, georeferencing of maps, etc.
These characterizations help us see the functions these jobs play in the larger ecology (and we can start to imagine some of the working relationships they entail with one another). They help us see what people “do”—their organizational role— regardless of their institutional location. Bear in mind that an individual “job” might entail more than one “role” as I am describing them here.
We can probe even further into these roles by asking what kinds of skills and expertise distinctively belong to each one. However, skills and expertise here are not simply “the things people know how to do.” I know how to write a TEI customization, and my colleague Syd Bauman knows how to write a TEI customization, but that skill operates very differently for the two of us because of the different kinds of metaknowledge we each have. By “metaknowledge” I mean domains in which we possess a comparative perspective, an understanding of why things are the way they are. In his case, metaknowledge about the design of schema languages and the systems that process them, and in my case, metaknowledge about discipline-specific approaches to textual analysis. So it may also be useful to consider the distinctive skills and metaknowledge each of these roles characteristically possesses; this slide is an oversimplification but I hope it illustrates what I’m getting at here:
- analyst: knowledge of design, standards, and systems; translation between discourses; has meta-knowledge with respect to discipline and method
- scholar: content expertise, research methods, reading and interpretation; has meta-knowledge with respect to theory (what does this mean?)
- developer: significant technical and architectural knowledge at the system level (i.e. not just the ability to use specific tools and languages but ability to learn and assess them, use them strategically); has meta-knowledge with respect to code, processing systems, system architecture
- manager: understand and manage resources, creating effective conditions for individuals and groups to function; has meta-knowledge with respect to organizational systems
- administrator: knowledge of fiscal structures, legal and policy requirements, university ecology (including both fiscal and diplomatic realities and strategic planning); has meta-knowledge with respect to resources
- data creator/coder: (coder/data preparation): data modeling, quality assurance practices, specific technical systems, consistent application of standard procedures and good decision-making in exceptional cases; has meta-knowledge with respect to content
- information manager: understanding and managing information systems, designing systems in which information can be translated efficiently into usable and sustainable forms; has metaknowledge with respect to data management and data representation systems (such as information standards, repository systems, data curation best practices)
“Personally, I think Digital Humanities is about building things. [. . .] If you are not making anything, you are not…a digital humanist.” (Stephen Ramsay, “Who’s In and Who’s Out”, http://stephenramsay.us/text/2011/01/08/whos-in-and-whos-out/)
What’s a tool? We use the term as if we know them when we see them: things we use to do tasks. In digital humanities, terms like “build” and “tool” are necessarily a bit metaphorical: you can’t break your toe by dropping these things on your foot.
In early discussions on the Humanist discussion list (e.g. in the late 1980s and early 1990s), the term “tool” often carried a pejorative tone, with the implication of considering something as “merely a tool.” More precisely, through discussions of how and whether a tool determines our relations with the world (the “if all you have is a hammer everything looks like a nail” analogy), we can see concerns about the effect that the use of computational tools would have on humanistic research: a loss of nuance in our methods, a tendency to reduce complexity in the interests of computational tractability, and conversely, expectations about the usefulness of the computer as a “fast and accurate tool”, an “analytical tool.” Tools also figure prominently in definitional discussions of DH as a domain and as a profession: for instance, the ACLS Cyberinfrastructure Report lists 5 things “digital scholarship has meant”, of which 4 mention tools (p. 7) and three of these items are “creating tools”:
“In recent practice, ‘digital scholarship’ has meant several related things:
- a) Building a digital collection of information for further study and analysis
b) Creating appropriate tools for collection-building
c) Creating appropriate tools for the analysis and study of collections
d) Using digital collections and analytical tools to generate new intellectual products
e) Creating authoring tools for these new intellectual products, either in traditional forms or in digital form”
—”Our Cultural Commonwealth: The Report of the American Council of Learned Societies Commission on Cyberinfrastructure for the Humanities and Social Sciences”, http://www.acls.org/cyberinfrastructure/OurCulturalCommonwealth.pdf
Alongside these discussions there’s another strand visible, concerning the question of whether the computer is more like a “tool” or a “method”: essentially, a set of questions about how these systems sit in relation to our own thought processes and theories. The hammer/nail metaphor imposes a strict thingness on the tool: its shape determines our use of it, and this metaphor also suggests a certain self-evidence about the tool (we all know about hammers) and a desire for transparency. The hammer works, unproblematically, as a hammer: its purpose is to drive the nail, not to open up a discussion about the process. But if something that looks like a tool could also be a method, then the concept of the tool starts to seem more plastic, more responsive to and engaged with our own thought processes. Stephen Ramsay observed at MLA in 2011 that “If you’re not making anything, you’re not a digital humanist,” but far from offering this kind of “making” or “building” as a pure, bone-headed space of theory-free praxis, he proposes making as “a new kind of hermeneutic.” As he and Geoffrey Rockwell argue in “Developing Things: Notes Towards an Epistemology of Building in the Digital Humanities”, under the right conditions tools can even be theories:
For tools to be theories in the way digital humanists want—in a way that makes them accessible to, for example, peer review—opacity becomes an almost insuperable problem. The only way to have any purchase on the theoretical assumptions that underlie a tool would be to use that tool. Yet it is the purpose of the tool (and this is particularly the case with digital tools) to abstract the user away from the mechanisms that would facilitate that process. In a sense, the tools most likely to fare well in that process are not tools, per se, but prototypes—perhaps especially those that are buggy, unstable, and make few concessions toward usability.
—Stephen Ramsay and Geoffrey Rockwell, “Developing Things: Notes Towards an Epistemology of Building in the Digital Humanities”, Debates in the Digital Humanities, ed. Matthew Gold, 2012.
In particular, tools can be theories if they operate to draw attention to themselves, above all by functioning in frictional ways.
We can start to see here that there’s a reason digital humanists are so preoccupied with tools and it’s not because tools are important in themselves: it’s because they are an irritant. They catalyze something complex and difficult concerning professional identity, scholarly methods and practices, and specific types of expertise. The questions of “who is digital humanities?” and “how is digital humanities?” can evidently be reframed as questions like “what are the design goals of our tools?” “when should a tool ‘just work’?” and “are we tool users, tool builders, or tool theorists?”
So we can now come back to think about how each of these digital humanities roles understands the category of the “tool”. (Remember that I’m talking here about “roles” rather than “people”: a given person might occupy more than one role and hence have a more complex positioning.)
The scholar has a tendency to regard tools from a distance, as a category rather than as a set of specificities (“we need a tool…”). In my experience when people are speaking from the “scholar” role, they don’t tend to differentiate between tools on the basis of complexity or design, but rather on the basis of function. So a car and a tricyle would appear more similar (as tools for carrying humans over the ground) than a tricyle and a wheelbarrow (simple non-motorized wheeled devices). The “scholar” role also tends to use more complex tools only to the point of getting the general idea, delegates their use in cases where in-depth expertise or systematic production-grade use is required (delegates e.g. to the coder) although the scholar may often try out the tool in a spirit of solidarity. “Tool” for the scholar role is often a metaphor for the thing someone will build and I will use (or someone will use on my behalf). Tools are the mark of the domain of implementation.
Scholars tend to use the metaphor of “get our hands dirty” when talking about using tools. Tools are the implements through which practice (praxis) is enacted. Tools do things. Tools are the subject of workshops. Typical examples of this kind of tool include visualization tools, data manipulation tools, publication tools. search tools, analysis tools. The scholar is also very interested in theorizing the tool, and likely to be very sensitive to potential theoretical implications of its use, although not necessarily in a position to engage with its underlying design or implementation.
Developers are less likely than scholars to be interested in a frictional relationship with tools, although they are likely to have a much greater awareness (metaknowledge) of the kinds of design and implementation issues that could inform an understanding of their theoretical implications. It’s easy to understand why: these jobs are typically the ones that involve building things that “actually work”, and their colleagues anywhere in the institution (IT, library systems) are operating under an extremely practical set of metrics for success: Did my beeper go off at midnight? Is the server down? Did I have to fix bad code someone else wrote five years ago who apparently didn’t know what they were doing? People in these jobs have a word for tools that are “buggy, unstable, and make few concessions towards usability” and it’s not a polite one.
The analyst chooses tools, specifies tools, documents tools, and thus has a kind of inexpert but meta-awareness of the tools that the developer uses directly. The analyst can participate in decision-making that concerns these genres of tools, but doesn’t participate directly in or have responsibility for their creation or management. It’s worth noting that analysts probably have the strongest interest of all these roles in theorizing tools; they understand them well enough to do so and their interest is not purely practical; they’re aware (like the developer) of how much of a difference the choice of tools makes, but by nature of their job they can be less pragmatic about it. In the analyst we see an almost anthropological interest/perspective.
The analyst also has tools native to his/her position. These include design and prototyping tools (wire framing, diagramming/charts), documentation tools (wikis, content management systems, literate programming, code commenting), standards and reference systems, ontologies and authority systems. It is worth noting that the “tool” aspect of these systems with respect to the analyst’s role really lies in the expertise with which the analyst uses the capabilities of these systems to ensure that the information they contain can be used effectively within the project context. In other words, these systems become tools through the work of information design/organization, ergonomic optimization within a specific work flow, ease of use (training, reference), and effectiveness in preserving records of decisions and actions.
The administrator stands aside from the specifically digital humanities “tool” ecology, but of course this role has its own tools: e.g. payroll systems, grant management systems, budgeting tools, record-keeping tools. These tools are assumed to be theoretically neutral with respect to the research enterprise, but it’s interesting to contemplate the effect they have on the ecology, for instance by defining professional roles, differentiating spheres of expertise and authority, and limiting access to information.
The manager benchmarks and assesses tools and their impact.
The data creator uses tools, often with somewhat more critical perspective than the scholar (i.e. as an expert user rather than an onlooker or visitor-user). Tools natural to this role include:
- authoring tools (XML editors like Oxygen, content management systems like Omeka and WordPress)
- simple data conversion tools (Google refine, OxGarage)
- digitization tools: scanning, OCR, other kinds of image capture/manipulation
Expert data creators who have used multiple different tools for the same kind of task develop a kind of parallax or meta-knowledge about these tools. Inexpert data creators—understandably—fetishize and personify the tool as a kind of totalizing context for their work (“Oxygen didn’t like my code”) and may also not fully understand the data apart from the tool through which they encounter it. For instance, it’s common to find that someone who has deep familiarity with XML data as an encoder may nonetheless not know that the same XML file can be opened and viewed in a web browser.
The information manager is very similar to the analyst in choosing, specifying, and documenting tools, but these tools tend to be infrastructural (or portals to infrastructure) rather than user-oriented. The characteristic tools of the information manager include:
- data management tools (repository systems, tools for integrity checking, data migration, data conversion)
- data dissemination and discovery tools (online library catalogues, APIs and tools for exposing metadata for discovery such as OAI servers)
We can see latent in these roles some strong potential complementarities and also some strong potential friction points. For example, a developer who is also an analyst (combining deep expertise in systems with disciplinary metaknowledge) is a powerful ally of the scholar, since together they can develop tools and projects that are both functional and theorized. Finding those three roles combined in a single person is difficult but if you do, you should hire them! However, when developers who are not also analysts work directly with scholars, there can sometimes be a kind of disjuncture: the developer’s detailed awareness of the differences not just between tricyles and cars, but also between different kinds of transmissions and how they affect the behavior of your four-wheel drive, makes it likely that there will be conversations where the scholar thinks he or she is requesting a way to get from point A to point B on wheels and ends up in a conversation about the merits of different kinds of synchromesh. As another example: people often start their careers in the data creator/coder role (e.g. working as a graduate assistant on a digital project, which gives one an initial exposure to tools for content creation and management), and then develop additional roles over time. But a project that includes only scholars and coders (a common combination) will have a peculiar relationship with tools: a kind of distance (on the scholar’s part) and on the other hand an intensive proximity (on the coder’s part) that may not yet have critical distance or meta-knowledge: the awareness needed to use the tools in a fully knowing way.
So what does a healthy ecology for Digital Humanities look like, taking all of this into account? How can we build organizations in which digital scholarship in the humanities can thrive and where practitioners in a variety of roles can work effectively together? A few thoughts and concluding suggestions:
- The “analyst” role is clearly an important one, and also one that interestingly seems to inhabit a number of different possible institutional locations and job identities: the library, IT, research centers; post-doctoral fellows, data curation and DH librarians, instructional technologists, research support specialists, programmer/analysts. Furthermore, because the analyst is so often an infrastructural position rather than a project-specific one, that role brings with it an inherent attention to longevity and sustainability. The analyst is likely to know about things like data standards, institutional repositories, data curation and reuse. The analyst’s skill profile also includes knowing how to identify and assess relevant work by peer institutions, to avoid reinventing the wheel (or worse, repeating common mistakes)
- It’s important not to overload junior jobs like assistant faculty, post-doc, grad student, entry-level developer, with roles that are outside the scope of their capacity: or at least to do so knowingly. I spent the first ten years of my professional life operating outside the scope of my capacity, which was great for me in the long term but arguably less than ideal for the project and not great for my personal life either. If you’re going to overload a junior role, make sure you have strong mentoring and training in place, and make sure you have infrastructural roles somewhere else in the system (analysts, developers) who can provide transitional support when needed. Which leads me to:
- It’s important not to use short-term jobs as a way of filling long-term roles. In situations of scarcity and constraint, it’s tempting to make technically gifted graduate students or post-docs serve as solo developers or managers, but this is a risky approach: not because they aren’t capable of doing this work, but rather because those roles need greater continuity. Turnover in those positions results in loss of organizational memory, poor or incomplete implementation of systems, lack of documentation, and long-term difficulties for both the project and for those who stay behind (scholars, analyst roles in the library or IT organization who will have to pick up the pieces, administrators who have to make sense of financial and HR situations).
- Finally, be aware of the different professional trajectories and accompanying reward systems that are in play for these different roles, again bearing in mind that the same person may occupy different roles (and may have multiple professional trajectories in play). This is an area where a lot of discussion has taken place in recent years, particularly in venues like the University of Maryland’s Off the Tracks workshop and of course in the discussions of “#alt-ac”, citation practices, and related issues. It’s important to think about the forms of professional development each role needs: additional degrees, opportunities to attend conferences, opportunities for practical training or internships. It’s also important to think about the forms of professional visibility each role needs, such as opportunities to publish, opportunities to participate in open-source software development and standards bodies, opportunities to mentor others and participate in professional associations. And it’s very important to think about the next job each role is likely to be seeking—whether that is a tenure-track faculty position, a more senior analyst or developer position, a post-doc, a position in an MA or PhD program—and to think about whether that role will be in your organization (and if not, why not?).
The strongest digital humanities centers I know of are the ones that have succeeded in creating generational systems: viable succession plans in which students trained as data creators grow into developer, analyst, or manager roles while also maturing as scholars. But they also have invested in creating permanent jobs for the infrastructural roles (developers, analysts, administrators, managers) that give the ecology its stability and continuity.
I’m grateful to those who have heard versions of this talk for their feedback and insight.