Dan Cohen’s newly relaunched Digital Humanities Now is a great place to get the pulse of the DH community. One of the pieces I found there was Natalia Cecire’s When DH Was in Vogue; or, THATCamp Theory. Cecire, who is a managing editor of the Stanford-hosted digital salon Arcade, touches on an issue that has concerned me for some time: the way wholesale importation of digital tools, techniques and objects into humanities scholarship tends to foster a situation where rich, sophisticated problems are contracted to fit conveniently into software. She says it better, of course:
And so I think it’s time we insisted a little more strongly on theorizing all that hacking. There are some theoretical keywords for DH that get used in woefully unrigorous ways—keywords like “archive”; “labor”; “biopower”; “embodiment”; “disability” and “access”; “map”; “narrative”; “identity”; “author.” You show up at a THATCamp and suddenly folks are talking about separating content and form as if that were, like, a real thing you could do. It makes the head spin.
At the final talk organized by the crew that put together Tooling Up for the Digital Humanities, a Stanford grad student rather poignantly noted that oftentimes collaboration with computer scientists felt more like colonization by computer scientists, a statement that even if not true is far too sharp to ignore. Frankly, I think is true. I just attended a THATCamp, where I spent my time teaching folks how to use Gephi, and I tried to spend some time telling them that the network they create is the result of an interpretive activity*. I don’t think they cared, I think they just wanted to know how to make node sizes change dynamically in tandem with partition filters.
I love Gephi, that’s obvious, but it isn’t built for humanists because nothing is truly built for humanists, the closest we can get is something built by humanists. If you don’t know what a tool is doing and that your work is being extruded through it, then you’re in real trouble. I’m a bit concerned at how humanities scholars show a willingness to defer to tools, but I’m more concerned about how they can positively surrender to tool builders. When I got to Stanford, I felt superior to long-tenured faculty members because I knew how to code and they didn’t, and it was reinforced by the fact that they had to ask me whether something was possible. That’s a horrible burden to put on a young scholar or alt-ac type like me. It’s quite the temptation to answer questions like those as if I really knew all the possibilities of digital representation of humanistic inquiry. Because, really, the answer I’d give is what I thought was possible based on my limited coding skills and my own, even-more-limited understanding of the domain of the scholar I’m supporting.
After all, that sense of power and authority is a useful tonic for the lack of official respect accorded to alt-ac staffmembers that work with faculty in Research 1 universities. I’ve tried, hopefully with some success, to actively combat it by engaging the faculty members that I collaborate with in the nitty-gritty details of the logical systems that are being put in place to translate their work into the digital realm, all the while foregrounding the fact that, like any act of translation, it is interpretive and limited. I feel like it’s working, and one sign that supports it is that now, two years into being the Digital Humanities Specialist at Stanford, I feel far more aware of the years of work that scholars have put into truly understanding their fields. However, this isn’t meant to be some kind of self-abasing paean to the great and glorious tenured humanities faculty–if they want to do sophisticated digital humanities work they’ll need to reciprocate by learning how code works, if not actively becoming a coder.
As it stands, it is all too common that a respected scholar with years of experience in their subject matter is constrained by a masters student in computer science who, in the best of cases, is a charitable ally with little knowledge of the domain and its many, thorny issues. This situation is much like that found in the classic film, Mad Max: Beyond Thunderdome. For those not familiar with this particular artistic work, its title comes from an arena where “two men enter, one man leaves”. I think we’re replaying that moment over and over again in the digital humanities, with pragmatic, clean, idealized, “best practices” on one side and the queer, messy, uncertain and post-modern on the other. It’s not nearly as good an analogy as Cecire’s Harlem Renaissance, I know, but it has the benefit of being available via BitTorrent and YouTube.
* If there was ever a Lorax that spoke for the interpretive nature of data creation, it would be Glen Worthey, our Digital Humanities Librarian. The fact that we have a Lorax of Data, a Lit Lab, Arcade, Mapping the Republic of Letters and Franco Moretti is why Stanford stands the best chance of winning this particular bloodsport.
Thank you for this. I couldn’t agree more. I would even go a bit further and argue that the power suddenly attributed to those with technical knowledge has led to a bit of fetishization of “coding” as this magical activity. A little Ruby or PHP here and there does not a great computer scientist make (heck, check out Donald Knuth’s website at Stanford :-), nor does it enable us to tackle all the complexities of DH research (emphasis on H rather than D). It is not impossible to make oneself a reasonably proficient programmer in a semester or two, but it is also important to learn about what lies behind the loops and arrays in the form of algorithms and stats. That is what will help us produce really nuanced research once everyone is “hacking” Rails.
I wondered if you could unpack ‘nothing is truly built for humanists’ a bit. Are you including bespoke software or do you mean generic tools?
Most of my experience is in museums, archaeology and the commercial sector, but there’s usually a layer or two or business analysts, requirements engineers and user experience designers working with tool builders to ensure that what’s built is tailored to the needs of the users (be they curators, archaeologists, historians or whatever).
So, I suppose another way of saying this is that at the very core level, the systems, protocols and logical framework that are our digital world are created by and for that pragmatic, idealized, “best practices” group that I refer to above while our higher-level languages, standards and applications are a result of collaboration in varying parts between that group and the professional world. Add to this the fact that there is little in the way of domain specialization among software engineers for the field of humanities scholarship and you end up with a situation I once described as trying to use a satellite built to map elevation to instead map culture.
Archaeology is traditionally pretty pragmatic in its use of technology, and museums and business are oriented toward a different audience than humanities scholarship at a Research 1 university. We don’t, as yet, have a corresponding set of domain specialists in computer science to help fashion UI/UX, data modeling and requirements for proper digital humanities scholarship and I really don’t think we ever will–there simply isn’t the market for it, the work is too sophisticated, specialized and absurd. The best we can do, if we go the traditional route, is to latch on to best practices from journalism, public humanities like museums and library science. All of these, I think, carry with them the problems that Cecire originally noticed.
The other option is to not touch the filthy digital, which would keep humanists clean but make them fundamentally divorced with the modern world. The third path is for humanities scholars themselves to pick up coding, write weird and not-at-all pragmatic software and, perhaps, create standards through practice or, more likely, just create lots and lots and lots of weird code that better describes queer black artists in the twenties or the republic of letters or Walt Whitman or James Joyce or Søren Kierkegaarde.