Attending the Scholars' Lab/NEH Speaking in Code symposium emphasized for me how much of a research developer's work involves tacit knowledge, and this opacity extends to scholars in general when it comes to how stuff—books, articles, projects—get made. You get semi-polished glimpses of a work becoming itself, from its beginnings (grant applications, abstracts) to the draft stage (actual drafts, as well as blog posts and conference talks feeling out the research) to the end point (white papers, finished products, and sometimes honest discussions of a project's struggles). But what does doing this work look like on a daily basis? What tools do you use, and where, and when? Matthew Kirschenbaum writes:
Nobody teaches you how to write a book. Yes, in graduate school, you may get “feedback” on your dissertation to a greater or lesser extent from mentors and peers. But that typically has very little do with the process of executing on a marketable book project. (Kirschenbaum, blog post)
Kirschenbaum's post attempts to improve on this lack of example for how scholarly work gets done, discussing practical details of his book-writing process such as citation management. I've tried to emulate this example-sharing by blogging about my dissertational process, from the technical choices I've made to the theoretical questions I'm considering. In this post, I've asked myself what I'd like most like to learn about others' DH work set-up, and decided that the physical and screenspace environments, most-used software and websites, and work habits were the aspects I would most benefit from seeing other examples of. I'll describe the workplace set-up, schedule, and software that help me make progress on my digital dissertation project and its Infinite Ulysses, with the hope of hearing more from others about the day-to-day environment and behavior that produces their digital humanities work.
MITH. I'm in residence at MITH as the Winnemore Digital Dissertation Fellow this academic year, and the plan is to do most of my remaining dissertation work at the office. MITH is generally either quiet or has a pleasant hum, but sometimes I'll block out sounds while I'm blogging or on a particularly frustrating problem. I saved up for some noise-canceling headphones, which are pretty magical at producing quiet even when I've been trying to work in an airport. In the past, I've used cheaper but still useful alternatives such as earplugs or normal headphones playing free white noise. Coffitivity is great when you want want something a little more realistic in the background.
I use an external monitor, keyboard, and mouse, both for the extra screen space and to position everything at the optimum height for my wrists and neck.
Home. I worked entirely at home over the summer, but my set-up there is pretty similar (external monitor, desk/chair/externals adjusted to promote good posture/happy muscles).
In terms of screen space usage, I'll have one Chrome browser window open with a number of tabs up (or two separate windows if I want to separate research/question-solving from website work), as well as a minimized Firefox window (for checking site design and script using the plugin Firebug). I'll also have a text editor open with several different code files I'm working on or consulting, and the GitHub for Mac application open for committing (saving/uploading) new code to my private dissertation code repository (to be made public soon).
Time. I have the most energy in the morning; I was the kind of person who preferred taking classes in the 8am slot during college. Being up early lets my day start at a slow pace, and I have a bit of time by myself to get into a good working frame of mind and plan what I want to accomplish that day.
I get to MITH a little before 8 A.M. and stay until I hit a good stopping point for the day, either mid- or late afternoon. I do this for four consecutive days a week, with some extra email/organization/reading work on those evenings after I go home and try to jog. On the remaining three days, I try to do nothing related to the dissertation, focusing instead on fun projects (creating a new theme for this blog, learning to bake really good bread, trying to increase my running distance, learning Go). So far, this is a great schedule: I get way more done than if I try to say "I should be working on my dissertation 40+ hours a week and on every single day!", and I'm always refreshed and excited to get back to my research after a few days resting my brain with other things. I think I'd allow myself to work on one of these days off if I was really excited, but I never want to feel like I need to; getting my project done a bit sooner isn't worth burning out or not being able to think about anything but my project.
Scheduling tasks. I previously used TaskPaper, a task list app from the makers of the distraction-free writing app WriteRoom (which really helped with writing my candidacy exam presentation!), to keep track of what I needed to do on my dissertation. That got a bit unwieldy. I've recently switched to keeping a TaskPaper list for things I want to do on non-dissertating days (so I can write them down and not have them distracting me), and using Basecamp to manage teaching and research tasks. Trello is a good, free alternative, but I ended up finding the set-up for Basecamp matched the structure of my task list a bit better (I'm also more used to Basecamp from using it for MITH projects).
On Basecamp, I've attempted to break down everything I need to do in the remaining year (knock on wood) of my dissertation into small tasks, then added a date to the tasks I want to complete in the next month, so I can filter to a view of just what I need to accomplish today or this week in order to stay on track. Checking off tasks is pretty gratifying, and having a clear overview of what needs to be done by what point (after first, of course, creating a project timeline that I could reasonably follow, with a lot of empty buffer time at the end for all the things I can't plan for) keeps me from getting stressed about what I haven't done yet—if I complete the tasks I need to do this week this week, I know I'm on schedule.
Within a given week, I try to vary between coding-focused days and other activities such as organization of tasks and URL bookmarks, blogging, and reading/research. I generally start the week with coding so that if a problem proves frustrating, I can switch to a non-code day to clear my mind before trying to figure out the issue again.
Citations. I've managed citations in the past with the free and awesome Zotero (e.g. for my master's thesis), and I expect to do so again once I start creating my final article about my project. If you do a lot of your research on the Web, Zotero is fantastic—you can use it to pull citation info from a page you're reading, as well as take a snapshot of the page in case it disappears later.
Research for me right now means a mixture of theoretical articles (e.g. papers about the social reception of Ulysses, or studies on meaningful crowdsourcing for the humanities, or blog posts), example digital editions and other digital textual work (e.g. Alan Galey's Visualizing Variation), and support for my research coding/design (e.g. code snippets, the Drupal StackExchange, tutorials, and documentation). I initially saved these bookmarks into various folders, but the folder names at the start of my project proved to be way too vague and all-encompassing two years down the road ("Scholarly Sources to Read", anyone?). I recently re-organized these so it's easier to find what I need, with more specific folder titles.
I wanted to keep the folders in a certain order, but kept losing that when I'd sort their contents by title—thus the numbering per folder. In my research resources folder, you can see some more specific sub-folders, such as one where I'm keeping track of the various digital edition and textual annotation tools I considered and tested before ending up working with Annotator.js.
Coding. I read, edit, and write code in bbEdit (the pro version of the free TextWrangler), which has far more fancy features than I can regularly use. Features I've found useful include scripts that convert minified CSS and JS into readable, well-structured code; folding (collapsing) sections of a code file I'm not working on and don't need to see; and searching across multiple folders.
Track changes. Keeping track of changes in my code is important for several reasons: I want to document effort for my dissertation committee (especially as my dissertation looks different than those they're used to), give proper credit and correct licensing for any pieces of open-source code I build on, and be able to roll back my code to an earlier state if I need to. I use git to do this, mostly through the website GitHub and a GUI app (GitHub for Mac) that is quicker for me than using git on the command line.
I've started creating Drupal installation profiles after I make major changes to my work, so I can easily re-create my site without needing to reset all the options and reinstall various modules; eventually, I'll package all my work as a Drupal distribution, so that anyone can spin up a participatory digital edition website like mine with no more trouble than setting up a vanilla Drupal website (and if setting up a vanilla Drupal website is difficult or unknown to you, I'll provide user-friendly instructions on that as well—or you can check out Quinn Dombrowski's awesome Drupal for Humanists).
Command line and local work. I don't use the command line as much when I'm just working locally (i.e. on a version of the website that lives on my computer and isn't accessible on the Web), and I've been mostly working locally lately. When I need it, I use Mac's Terminal app to manage things that are easier to do from the command line than via the GUI, such as Drush (a set of commands that makes doing sysadminy and developer things with a Drupal site quick), or to move files around. When I'm working on a site on the Web, I use the command line to install things, edit files, and more. When I want to work locally on my Drupal site, I use MAMP Pro (the paid version of the free MAMP), which imitates the things I'd be using on a web server to make a Drupal site work (e.g. MySQL).
Technical support. An important piece of tacit understanding we discussed at Speaking in Code was the ability to successfully search for answers to technical problems; surprisingly, knowing how to Google well as a coder—especially when technical words have alternative popular meanings—is a difficult skill to impart. Since someone has probably encountered the same or a similar problem to yours before and written about it, and coding today is all about not re-inventing the wheel but building off of existing open-source code, knowing how to search for what you need is a vital technical skill.
Blogging. I've covered how I figured out what I needed to blog about in this post on affinity mapping.