On Digital Solitude

This post is a revised version of a paper presented at the 2017 AHA meeting in Denver. The panel was titled “Making Digital History Work,” and focused on doing digital history in places without significant institutional support. I must thank my co-presenters Konstantin Dierks and Nicole Phelps, as well as our commenter Seth Denbo for a most provocative set of talks and discussion. For a very nice roundup of digital history sessions at the conferece, see this AHA Today post by Evan Faulkenbury.

The rise of digital humanities has often been framed as conservative, static, analog methods and products against their innovative, dynamic, digital counterparts. I must admit that I’ve done this (repeatedly), and I’ve really enjoyed it.

However, not only is that dichotomy frequently overblown, it’s not the whole story. I’ve come to think that uncertainty and questions about how to “do” digital history or “make digital history work” are an unfortunate but very real byproduct of the growth of digital history itself. Just yesterday morning there was a fantastic panel (110) on the necessity of collaboration in digital history. We got to hear several inspiring examples of what collaboration can achieve, and which simply could not be achieved without it. If you’ve read any digital humanities grant application guidelines recently, the requisite emphasis on collaboration will sound most familiar.

It’s fair to say, I think, that digital humanities advocates, practitioners, and funders have recently oriented, if not effectively defined, DH in terms of collaboration—quite often with a focus on multi-disciplinary and multi-institutional projects. Collaboration has become a defining feature that separates conservative individual analog history and promising team-oriented digital history.

Now, of course, it’s not that most people (although some do) argue explicitly that collaboration is essential to digital history. Even the chair of yesterday’s panel, Stephen Robertson, cautioned that we shouldn’t take the panel to mean collaboration is necessary. But there is a very real sentiment, perpetuated by the panel itself, that if you’re not collaborating, you’re not fulfilling your DH potential. The great upside of collaboration notwithstanding, the implicit message seems obvious enough: The way you should start to “do” digital history is to write a grant to do a big thing with lots of people who work in other fields. Let’s be honest: you’re never going to be able to learn everything, anyway, so find some collaborators.

Yet if you’re an individual without access to significant funding, or you’re in circumstances that make collaboration difficult if not impossible, or you just don’t want to, it’s easy to feel marginalized by the emphasis on collaboration. In reflecting on my own efforts and motivations for promoting collaboration in these exact ways, I think it’s become over time a systemic problem. So I want to outline two ways of dealing with it, or at least reframing it, that I’ve found useful in my experience working with and teaching digital methods. Essentially, I’m making arguments about why we should be more at ease with individual digital history.

Importance of Failure

At least within Digital Humanities circles, the importance of failure has been typically discussed in terms of credit. The usual line of argument is that digital historians who are forging new methodological trails should get credit (jobs, promotions, tenure, gold stars, etc.) for doing that, even when not producing conventional research results like new historical interpretations in journal articles. This is a very good thing in my opinion.

However, we have to recognize that are several kinds of failure, a distinction that has not been treated carefully enough. I want to highlight two kinds of failure here.

Productive Failure

On one hand, there is what I call productive failure—the kind that most people mean when they lobby for getting credit for it: exploring and explaining a technique or tool used very carefully and critically and robustly, but tells you nothing. Explaining how much work you did to fix sloppy OCR that didn’t actually matter in the end. Or showing how your brilliant database schema became problematic while developing and reformulating research questions. Sharing this kind of failure is how practitioners teach each other new methods. Very important.

Also Productive Failure

On the other hand, there’s another kind of failure: a nagging, frustrating, stress-inducing, soul-eating kind of failure. It’s almost never publishable. You can’t publish a paper extolling the importance of spacing in a python script. (For those of you who don’t know, spaces are SUPER important.) And they are SPACES, so you can spend an awful lot of time troubleshooting something you can’t see all that well. Similarly, you can spend a lot of time tracking down a typo in a large data files that’s not loading into a tool properly. I won’t mention the myriad problems that arise when installing software and dependencies. And I definitely won’t mention character encoding. For those of you who have dealt these sorts of things, you know what I mean. These things are listed in the definition of time-sink.

So it’s easy to think—and I think most people think this—that as one inches up the learning curve, this kind of failure is not significant. Not productive. However, I want to argue that this kind of failure is important and productive in two crucial but totally under-appreciated ways.

Honesty

The first is that how you respond to this particular kind of failure is an important indicator of what you’re really interested in doing, and what kind of digital history you might most profitably and amicably engage in.

If you’d like to analyze many thousands of newspapers as part of some project—that is, work at a larger scale than most historians—you’re going to need to learn different skills than most historians simply to do the most basic tasks the craft requires: discover sources, organize them, explore them, to synthesize and interpret them. There are tools that you can play around with to help you decide if a large-scale approach is worthwhile, but they can only take you so far in terms of analysis. If you’re serious, you’ll need to learn about how to organize plain text files; you’ll need to learn about different kinds of text mining tools and algorithms (though not the math itself), visualization techniques, limits of OCR, maybe extracting text from PDFs, how to fix sloppy OCR files, and so on.

My point is that these skills should not be seen as someone else’s domain, even though people obviously specialize in these sorts of things; it’s squarely within the purview of the digital historian. What is more, to outsource them is highly problematic from a methodological standpoint. Would you take seriously a historical study in which the historian worked only from translations? Or let someone else determine the source base?

If you don’t enjoy these kinds of technical challenges, it may be that some kinds of digital history work isn’t for you. So the question isn’t “how do I do this?”, but “do I really want to?”. It’s important to find out. And it’s important to mention that you may find that you like certain methods or technical aspects more than you expected, and how much historical expertise is required in what seem like mundane technical tasks. Even what seems as unproductive failure may help shape the kinds of projects you undertake and can tell you about how you’d like to be engaged with digital history.

Pedagogy

The second reason to value failure, if you find that the technical work is interesting or at least tolerable, is because it’s the only way to learn requisite technical skills—precisely the kinds I’ve mentioned above that help us understand our sources. Furthermore, it’s important not only for scholars teaching themselves, but for our students as well.

As someone who has been teaching digital methods courses for about 8 years now, I’ve convinced myself that navigating trial and error (and the failures that inevitably accommpany it) is an essential part of learning digital methods. It’s great to work through tutorials—everyone needs a reasonable place to start. Googling is not always helpful, if you haven’t noticed. Fortuntaely, resources like Programming Historian are a great place. (As one of the editors, I had to work it in somewhere; and I’ve very proud of how much our contributors have done).

But your research project doesn’t come with a tutorial to follow. Even what seems to be the most straightforward digital history work creates an endless onslaught of problems. While problems may have been solved in general, they haven’t been solved for your sources. And you have to be able to see that work as essential to your field, not something that someone else should be doing. That’s a unique scholarly contribution, whether to digital methodology in general, or to your field and work with your sources. I think it’s hard to get sufficient credit for this now, but that will change as we develop better guidelines for evaluating digital scholarship.

OK: there you have two reasons failure is important: honesty and pedagogy.

Decentralized Digital History

We all know that one big reason for collaboration is that dirty five letter word: SCALE. Everyone’s heard that scale is where a lot of the potential of digital history lies, and it’s where much of the rhetoric and theory (and blog posts) have focused. I’ve really enjoyed making these arguments, by the way, so I’m totally part of the problem.

Look: if you’re going to analyze terabytes of data, you’re getting into technical and infrastructure challenges that personal failure is not going to help you solve in a reasonable time. So the general DH emphasis on collaboration and scale go hand in hand. But I want to make the case that we can collaborate and work at increasing scales without these big expensive grant funded projects. First, I want to remind us that we tend to gloss over many challenges of collaboration in our fervor for digital history teamwork:

There’s also another way we can think about scale. To me, some of the greatest potential of DH isn’t large collaborative and expensive projects, but in what I call “passive collaboration” in the sense that you remain aware of how your work can inform future work without knowing how it will happen. Despite the usual digital humanities rhetoric, we might make working at scale more of a long-term DH goal, not the most immediate, and certainly not the most important. This means all of us engaging with digital methods and tools and data and failing and being frustrated and perhaps experimenting and teaching each other ways of creating, standardizing, and sharing data.

I worry that we’ve become seduced by the sexy project website and big data at the expense of a valuing the nitty-gritty work (often with difficult sources and data) that make digital history possible and exciting. But there’s good news, even if it’s totally obvious: historians have long enjoyed—basically forever—NOT working at large scales. So please, as one digital historian to another, please, work at small scales. Together, we can accomplish over time much more than most big expensive projects. For me, the future of digital history isn’t in scale and complexity and interdisciplinarity. Again, if you want to do that, awesome! For most everyone else, it’s about doing what we like to do, largely on our own, while participating in a larger scholarly conversation.

Very quickly: one argument against individual work I want to address explicitly: the danger of mediocrity. The argument is that as a historian, you’re never going to be really good at, say, coding. You’re never going to be really good at design or typography. You’re never going to be a top-notch database architect. Therefore, we should outsource these difficult skills to professionals—people who have studied and practiced and honed these crafts over time. There’s a reason these are professions! And then we’ll all have better code, better design—better everything—when we all do our jobs for which we’ve been trained.

So there’s an interesting contradiction here. On one hand, multi-disciplinarity remains central to most DH work, and especially with collaborative projects. Yet in many respects, insistence on collaboration reinforces typically disciplinary silos. “Sure, we’ll work together, but you work in your discipline; I’ll work in mine. And we’ll make something we couldn’t have otherwise.” But the mediocrity argument applies equally to the collaboration; it produces something that has to satisfy too many disparate parties. While it does create its own value, there is equal value in one person doing a bit of everything with the intimacy of the study permeating all aspects of the project.

What’s most troubling to me about the we-should-collaborate-to-avoid-mediocrity argument, is how it encourages the corporatization of DH at the expense of individuals themselves dissolving and transcending disciplinary boundaries. Ultimately, by this rationale, historians should learn about technologies so they can communicate to experts more effectively, but not actually do anything significant with them—that “other work” is for the experts. To be frank, that’s not a future of digital history I think we should pursue.

To Conclude

I’ve tried to make a case for 1) de-emphasizing the necessity of collaboration; 2) de-stigmatizing failure; and 3) thinking about scale in a more distributed way. Again, this is NOT to say that we shouldn’t collaborate. It’s absolutely true that collaborative projects do amazing things not otherwise possible. We need these!

But I think we may have gone a bit overboard extolling the virtues of collaboration and inadvertently marginalized those who can’t or don’t want to; ditto for working at large scales. We should be more careful to treat digital history work on much smaller scales done largely individually (especially that which can be aggregated over time) on equal footing. For this to happen, we have to recognize that personal failure, while unevenly recognized in the discipline (although unfortunately not equally available to everyone), is crucial to our individual success as digital historians. And it’s when we feel welcome to pursue our own interests, that’s when we can simultaneously work together to “make digital history work.”