The Digital Humanities often borrows methodologies, tools, and techniques from other fields—perhaps most notably from the social sciences. But speaking from a very practical, design-oriented perspective, I would propose another field that DH can learn from: independent video game development.
About halfway through my 8-month long Student Assistantship (the resulting project is a virtual exhibit that you can find here), I stumbled across a YouTube series, made by the people at Extra Credits, called "Making Your First Video Game." The series provides advice for aspiring game developers meant to minimize frustration and maximize learning opportunities. As a series, the videos are well done and worth watching—they provide solid tips for organization and planning that only seem like common sense once you already know about it.
You can watch the one I found most personally useful here or on the sidebar to the left (the series has 3 episodes total). The rest of this blog post discusses how I applied and/or extended three of the most useful takeaways.
What Do Video Games Have to Do With It?
There were quite a few similarities between my project and how the video describes a "first game":
1. Both are small-scale. Given that most DH projects are large-scale and collaborative, many of the tips or articles that I could find on DH project management were made with that in mind. There were differences in the scope and labour involved that few, if any, of the resources addressed. And, without a whole lot of experience, I couldn't always anticipate how the differences would affect me.
2. There are many "moving parts." For a video game, this might be the many different elements (writing, art, music/soundtrack, animation, etc.) that go into it. For my Assistantship, I had to juggle a lot of different kinds of tasks (writing and research, web design, archiving) and communicate with different people about each.
3. I worked alone with limited support and limited skill/experience. I had supervisors who were as supportive as they could be, but I was sometimes working with tools they didn't have experience with (Photoshop, WordPress, HTML, etc.) and some of which I myself had little-to-no experience with. I often had to solve technical problems on my own.
4. Both emphasize the importance of learning. This calls for somewhat of an inversion from the way we usually think about learning technical or hard skills: rather than feel like I needed to learn the skill in order to do the project, I sometimes thought of the project as a way to learn (or practice) the skill. Even though I still needed to deliver a final product, thinking in terms of "solving a problem" instead of necessarily getting something done made the whole experience less stressful.
Milestones and Granular Task Lists
Extra Credits recommends splitting projects into "milestones" (generally doable in a week) and then further breaking down those milestones into even smaller tasks (doable in about an hour or two). Having a granular task list helps you keep track of your progress, which prevents you from falling too far behind without realizing it. A task list also prevents you from feeling too overwhelmed or intimidated by constantly thinking in "big picture" terms.
On the technical side, many of my "tasks" involved finding and experimenting with different WordPress plugins or solutions on Stack Overflow so that I could figure out which would/wouldn't work and which I could customize. On the writing and research side, each annotation was a milestone that I split into smaller tasks (reading/researching secondary sources, drafting, revising/editing).
Scheduling and Producer Emails
The video recommends sending yourself "producer emails": a record of what you did last week and what you plan to do for the coming week. It also recommends comparing these emails from week to week to ensure that you're organized and on task. The emails are also good moments to take a step back and consider whether your tasks and milestones may be too big.
For my own project, I found it more useful to keep week-by-week Word documents instead of emails. Emails are indeed "quick and dirty", as the video says, and I found that I just wanted something more granular (being mindful of "procrasti-planning", of course). You can find a template through Dropbox here.
Since I was juggling different kinds of tasks simultaneously (for convenience, they were "Archival", "Writing and Conferences", "Technical") and communicating with different people for each, I gave each category its own row. For each row, I had columns labelled "Tasks", "Communication" (who I was talking to about what topic), and "Notes" (a general catch-all for recording any problems, observations, questions I needed answered). As a Google Doc, this could have the added benefit of being shared with supervisors and/or collaborators.
The "One Hour" Rule
This is perhaps the most interesting and unexpectedly helpful tip: "Don't spend more than an hour trying to do anything yourself" before looking or asking for help. The idea is that you will learn a lot by taking a stab at the problem but—beyond one hour—the problem becomes too frustrating, demotivating, and generally not worth the time spent on it. Stack Overflow was an incredibly useful resource in this regard, but there could be other places to look as well.
For my own project, this became especially important the more that limited time and limited support became an issue. Because of unexpected delays (there will always be something, no matter the project) and just plain busy-ness, my supporters couldn't always get back to me as quickly as I'd have liked given the looming deadline. Thus, the earlier I asked a question, the better. Having the "one hour" rule made sure I left myself that buffer instead of asking out of last-minute desperation. While waiting for an answer, I could switch tasks (from writing to coding and vice versa), which also helped curb any frustration. Sometimes, I would even think of a solution later after giving my brain a much-needed break instead of stubbornly trying to think my way out of it.
This blog post is not an exhaustive or comprehensive list of the tips in the "Making Your First Game Series"—it might even be an interesting exercise to go through them and see what else might be useful or somewhat analogous. For all the good that collaborative, large-scale projects do, many have rightly pointed out that our current funding models and rhetoric leave gaps. We should ask what the role of personal, small-scale DH projects might be and can be for students, for marginalized groups, and others—and seek out and share the tools and knowledge to match.