A few weeks ago, at DHSI, I was giving a demo of a prototype I had built and talking to a class on versioning about TEI, standoff markup and the place of building in scholarship. Someone in the audience said I seemed to exhibit a kind of hacker ethos and asked what I thought about that idea. My on-the-spot answer dealt with standards and the solidity of TEI, but I thought I might use this space to take another approach to that question.
The “more hack less yack” line that runs through digital humanities discussions seems to often stand in for the perceived division between practice and theory, with those scholars who would have more of the latter arguing that DH doesn’t do cultural (among other forms of) criticism. That’s certainly a worthwhile discussion, but what of the division, among those who are making, between those who hack and those who do something else?
I take hacker to connote a kind of flexibility, especially in regards to tools and methods, coupled with a self-reliance that rejects larger, and potentially more stable, organizations. Zines. The command line. Looking over someone’s shoulder to steal a PIN. Knowing a hundred little tricks that can be put together in different ways. There’s also this little graphic that’s been going around recently (and a version that’s a bit more fun) that puts hacking skills in the context of subject expertise and stats knowledge. Here, what’s largely being talked about is the ability to munge some data together into the proper format or to maybe run a few lines of Python.
This kind of making might be contrasted with engineering—Claude Lévi-Strauss has already drawn the distinction between the bricoleur and the engineer, and I think it might roughly hold for the hacker as well. In short, the bricoleur works with what she has at hand, puts materials (and methods?) together in new ways. The engineer sees all (or more) possibilities and can work toward a more optimal solution.
Both the bricoleur and the engineer are present in digital humanities work. The pedagogical benefits of having to work with imperfect materials are cited, and many projects do tend to have the improvised quality of the bricoleur—or the hacker described above. But many other projects optimize. Standards like the TEI, I would argue, survey what is possible and then attempt to create an optimal solution. Similarly, applications and systems, once they reach a certain size, drive developers to ask not what do I know that might solve this problem but what exists that I could learn in order to best solve this problem.
My point here has little to do with either of these modes of building. It’s just that the term “hack” seems to get simplified sometimes in a way that might hide useful distinctions. Digital humanists do a lot of different things when they build, and the rhetorical pressure on building to this point seems to have perhaps shifted attention away from those differences. For scholars interested in the epistemological and pedagogical aspects of practice, I think these differences might be productive sites for future work.