Blog Post

My Mellon Fellowship Year: Hindsight Advice

I spent my year as an A. W. Mellon Fellow in digital humanities becoming literate in the state of the field, finding new resources, meeting new collaborators, and becoming semi-proficient with a pile of skills, few of which I anticipated needing or wanting beforehand.

My project proposal, Buying into Science, was to assemble a database of producers and consumers of scientific print, from 1660-1800, which would support network graphs and statistical analyses of structural change in the scientific print trade, as well as changes in the consumption patterns of its audience over time. Like those of many novices I’ve met since, who were themselves transitioning from concept to construction, my expectations of impending graph glory took a swift kick in the pants. I’m a better scholar for it.

It’s been nearly two years since I began my project, and I’ve only just recently developed a working “toy,” or an abbreviated iteration of my data, that has produced meaningful (conference-able) results. In the interim from then to now (and more than ten years since my last math class), I’ve developed functional literacies in graph theory, applied statistics, societal computing, information architecture, database design/construction/management, scripting languages (PostgreSQL, R, Javascript, CSS), and programming languages (Python and PHP).

Am I an expert in any of these areas? Decidedly not. As I type this, I’m actually finding myself hesitant to name them for fear I’ll drub the lingo and call forth the ghost of Dennis Ritchie to haunt my Christmas pasts. But parts of each of them have been crucial to gathering, structuring, rendering, and analyzing my data. I have a webpage where you can read about my project at length. What I want to emphasize here, however, are the ways that the Mellon fellowship, I think, made me a more productive, more critical, and more concrete (digital) humanist than I might have made myself otherwise. It’s awfully easy for a field littered with technical and unfamiliar jargon—and plenty of people with far more expertise—to make you forget you already know how to be a humanist really well, that you are not looking to become a software developer but, rather, to enhance your critical lens and find new pathways into the texts, ideas, and objects we study.

I’m going to conclude this letter with a list of pro tips I wish I’d received when I started, but this seems a fine moment to peremptorily nod at the first: you do not need to learn Python to be good and smart and cool vis-a-vis digital humanities. No, you don’t.

Of my semi-proficiencies, what I mean to say is that I’ve spent a good part of my time looking at successful projects already out there, reading about how they have used scripts and metrics and methods, and considering how the research questions they’re designed to answer compare to my own. Once-weekly sessions with my cohort of fellows; once-weekly office hours with dSHARP; plenty of formal and informal sessions with developers and researchers at Carnegie Mellon; and a ton of outside networking, training, and communicating with peers on other projects at other campuses—all of these were legs up towards the competencies necessary for me to meet the demands of my project, as well as some sense of self-direction in pursuing it. None of these exercises has made me a programmer.

The most useful skills I’ve learned are how to look critically into the design of digital humanities inquiries, to form opinions about pluses and minuses of one approach versus another, and then, if I want, to reverse engineer solutions by others and tailor them to my own needs. Let those who love to code make tools for your computational research. There are degrees for that, and those people often have them. I’ve had better success learning how they do what they do, reading what they’ve done to understand why they did it, then focusing on just the pieces I need: how to call just a few functions in R, not all of them; how to tweak some CSS, not invent it. Bit by bit, the stuff piles up. Some silly and tedious thing (e.g., regular expressions), six months later, will save you hours or days fiddling with some other mindless task.

Make note of the syntax of solutions you see, learn the lingo so you can find things on Stack Overflow, and get really comfortable with treading water.

Pro Tips:

1. You (probably) do not need to be fluent in Python. At the outset of my fellowship tenure, I was, for mysterious reasons, under the impression that to do digital scholarship I would need to master all coding languages. In pursuit of this I enrolled in Fundamentals of Computer Programming (15-112) at CMU. Not only was this completely unnecessary, the four weeks I took of this course before dropping it stole nearly 40 hours per week of my life, which I mostly spent just trying to understand what the homework was asking me about. My project itself was stalled while I committed my time to algebra tutorials and evening recitation. Right around crisis point, I tried to identify specifically what it was I thought Python would allow me to do. The only answer I could formulate was, vaguely, “computers.” The point here is to identify as quickly as you can the skills you will need to succeed in your project and little else. You’ll find that simply by virtue of pursuing cursory knowledge, then some literacy, then some operability in targeted areas, you will absorb bits and pieces of parallel areas, too. You’ll also find, as I did, that coding languages have many things in common, they call functions in similar ways, or they have similar syntactical patterns or restrictions. If you can get to a point where you can use a tool, read the script, and understand how it works behind the scenes, you’ll be in prime shape to find tools that others have built and adapt them to your needs without having to become a wheel inventor yourself. Not least among the fringe benefits of all this snooping around in source code is that you’ll be aware of what the machine is actually doing to your data. Visualizations are beautiful, but it’s what’s on the inside that counts.

2. Embrace the community ethos. The Mellon fellowship offers a teaching release, which has its own appeal. But your time would be superbly spent in supplement with all the tutoring, office hours, coursework, audits, and un-conferencing you can fit into your schedule. The DH community is in many respects the obverse of the cloistered solo-show that humanities research can be. Open access, collaboration, humility, and a willingness to be wrong, or at least unsure, in public: all these are characteristic of DH scholarship. I’ve seldom worked around so many people so genuinely enthused about others’ work as I have while working in DH. Message boards, Twitter, un-conferences, and listservs are your friends. Someone out there knows how to do what you want to do, and they won’t shame you for admitting you’re lost or looking for guidance.

3. Take advantage of structured training opportunities, and go to DHSI. Number 3 is closely related to 2, but DHSI deserves its own plug. The facilitators of the fellowship can provide really specific suggestions for any technical training resources on campus you may need. For me, these included coursework in applied statistics and network analysis in CMU’s Institute for Software Research. Those folks are incredibly excited for multidimensional humanities data upon which to test the functionality and accuracy of their tools. At the Digital Humanities Summer Institute, however, you’ll be exposed to a huge group of scholars from all over the world, at all levels of expertise, with whom you might collaborate, troubleshoot, or keep in mind for inquiries down the road. Go into this program with measured expectations. You won’t master R or Ruby or digital editions in a week. But you will at least learn how to acquire a skill you want and, in most courses, make something tangible with that skill and your data.

4. Plan it and plan again before you make it. This one’s pretty straightforward. Plan out the workflow to the smallest detail you can before building anything. Try to imagine use cases for your project or analytical methods available to you, then actually go through the motions to find what the steps will entail. Things to consider include: how you will structure your data, whether there are competing methods for asking your research questions of your data, who else might want to access your data, and how you can make it so that access is smoother. I got nearly 3000 hand-entered lines into my catalog of subscribers to scientific print before Excel started lagging. I soon realized the data would become so large that storing it in a spreadsheet would prevent me from doing anything meaningful with it. It took 3 months to restructure it as a database and learn the SQL to query it. This was avoidable.

5. Read digital humanities scholarship. With all the activities going on, this one was an unexpected challenge. Reading how people are asking and answering questions in the field already, as well as exposing myself to key terms in hot debates, was something I made time for only later in the process. Doing this much sooner would have sped my approach to what was, for me, the most difficult step: formulating ways to integrate interpretations of my data into my humanities arguments.

6. Include a benchmark early in your timeline for a toy version of your project. Know if the concept works in principle before building an ineffectual mothership.

7. Keep logs of everything you do and how you did it. I’ve built and structured and tidied up a lot of things with the help of advisors only to find that, later, I could not reproduce those operations on my own. This can be debilitating. Take consistent notes of the challenging and the seemingly mundane things you learn how to do.

8. Learn to talk about your digital scholarship with some polish and ease. Of course, part of this is the lingo problem, which I think is best acquired simply by reading of and listening to a lot of people who know more about this stuff already. And the exercise we went through as a cohort to develop our elevator pitches as supremely helpful. I’ve delivered this pitch in various forms countless times at DHSI, at conferences, while interviewing for research positions, and in grant applications. But an equally important piece I wish I had considered is a more fully developed picture of how my digital scholarship enhances my more traditional work. Most of the questions I have received about my project have had to do with what computation makes possible that serial reading does not. Why are your digital methods necessary to answering your non-digital questions? Think hard about how you can sell this as more than an accessory to the work you really care about. Take advantage of this opportunity to integrate alternative paradigms into your regular capabilities and intellectual habits. In brief, be concrete about how the digital component of your work fits with the rest.


No comments