Today’s adventures in yak shaving: gritty realities of working with code for PhD students

(crossposted to my personal blog)

I wrote this almost a year ago — and published it — and then unpublished it, terrified that I would seem as though I was kvetching without good reason. I don’t think that’s the case anymore — and both this post, by Julie Platt, and this post, by David Golumbia have convinced me that this stuff needs to be talked about.

Plus, I’m feeling braver now than I did then — so! I’m publishing it again, both here, and at my Day of DH blog.

So: here’s my original post, originally from April 19, 2012. I’ll update with another post later tonight, discussing what I’ve learned since then.

***

Earlier this week, via Twitter, I discovered Tara L. Andrew’s post on the realities of coding and collaboration for digital humanists. It’s brilliant. You should go read it, probably before you continue reading this post.

I’m resisting the urge to pontificate, so here’s the particular yak I’m shaving this week — but you can also skip ahead to my recommendations, if you like.

It seemed like a perfect solution!

I realized on Sunday night, while I was working on a Simile Timelines page for my students (an assignment I yoinked from Brian Croxall), that if I could modify the source code for units of time, that I could make Timeline into an ideal visual interface for my own project, Visible Prices. One of the challenges of helping people read prices is that pre-1971 British currency isn’t a base 10 system — instead, you have twelve pennies in a shilling, twenty shillings in a pound, and back in the 18th century, 21 shillings to a guinea. It’s not intuitive. But if I could mod Timeline’s date units to show units of money, rather than units of time; and adjust the multiplication formulas, then people would be able to scroll up and down the various amounts — and use facets to filter to a particular set of dates, or geographical region, or a type of object. I realized, too, that this interface would be that people could see other prices that were close to the same price — not just £4, 10s., but £4, 12s., too.

It would be PERFECT, I thought, and in a visual interface that I hadn’t conceived of before. I could use Simile Timeline as a platform to create a stable prototype that would easily demonstrate proof-of-concept. And this is hugely important, because platform decisions are epic. Almost certainly, especially if you’re approaching tool/project development from the humanities side rather than the programming side, when you first come up with your Big Idea, you won’t know enough about the limitations and capabilities of particular platforms in order to make a good decision.

I’ve actually taken a class in Java, and worked my way through textbook chapters beyond the class. I’ve taught myself HTML and CSS and Javascript and even some PHP using the W3schools tutorials, textbooks, and just studying code syntax. You can figure out a lot on your own if you’re comfortable looking at code, and if you understand the basic principles of variables, parameters, calls, methods, etc. In fact, at the workshop where I started learning HTML as a college freshman, back in 1995, we were encouraged to look at source code, see what it was doing, copy and paste, and debug till things worked. In some ways, I like this method of learning better than more systematic textbook progressions from “Hello, world!” to methods, to arrays, because it prompts me to see details better. (Your mileage may vary, but for an excellent discussion of this elsewhere, see Chapter 4 of William J. Turkel and Alan MacEachern’s The Programming Historian.)

In short: I understand enough to think that altering the source code of Timeline to change the units would be well within my capabilities. And there were even two sets of instructions at the Simile wiki for customizing dates that I could follow along with. Everything sounded doable. There would be bugs, but I was confident that I could fix them.

Or maybe not…

Last night, after turning in a grant application, I decided to have a go at it. I knew I would need to host Timeline locally, per instructions like these — and they were duplicated in enough places on the web that I thought they were probably fairly stable.

What I discovered is that hosting Timeline locally is probably the most difficult part of this mod — at least, for my own skill set. I thought I could host Timeline without hosting the rest of Exhibit locally, but I’m finding it challenging to do that. And I’m making use of the Simile Widgets Google Group, where at least I’m not the only person having trouble, but of course, I’m trying to avoid asking questions that are really just signs of my own lack of experience, and that would be solved if only I had learned to code more systematically, or hired a dev to help.

Hosting Exhibit 3.0 locally will require me to install, and implicitly, learn my way around Backstage, which, as the Exhibit 3.0 documentation says, may not be the project to start the learning curve for Java development. I’d like to do it. It seems like a great thing to learn. I have no problems learning, and part of me is saying “don’t mess with this blog post; find the instructions and start installing Git, SVN, Java 6, Maven 2, and Ant!”

But: transparency and the idea of instructive failure really obligate me to be up front about what I’m dealing with. And I think that we need more discussions about the gritty reality and challenges involved in working with code, so I’m offering up my own specifics, in the hopes that being open about them will be useful in some way. So–

Recommendations

1. Find out what your campus offers in terms of support. There’s an IT department: do they offer tech support that goes beyond working with email and installing virus protections? Do they offer introductory classes in things like HTML, CSS, and PHP? If they do, take them — especially if you’re one of those people who feels most secure and able to learn when there’s an expert nearby. I’m lucky — UW offers a really full set of workshops. There’s also the UW Libraries Digital Initiatives Project.

2. Be aware of the support limits: lack of funds, and a lack of grant availability:

Most grants for project development (including the NEH start-up grants) are open to people with PhDs, rather than people working towards them. At my local humanities center, these grants are for faculty. I understand this — at least sort of. It’s the way that things have always been done; funding faculty projects makes sense, since faculty (especially T-T) are ostensibly going to be around for longer than graduate students. And traditionally, graduate students are supposed to be intent upon finishing their dissertations, not building large-scale digital projects. Anything you build from scratch will probably need technical support at some point, whether because of a change in browsers, or some other cause.

The first of those specifics is that there’s never just one language you need to learn: you can know several, and not be savvy about working with GitHub, etc.  I took my Java class because it was the one that was open to students who hadn’t taken prereqs, and I loved it. Object-oriented programming is great, and it’s been useful. But it’s not enough, in and of itself (and happily, I knew that when I started learning it.) Coding in any particular language is one skill; integration skills are also necessary. Learn your way around the Linux operating system — and/or bash scripting — though these are languages, they serve a different purpose than HTML/CSS/JavaScript, etc. You’ll use them if you’re doing custom installs of tools on your system, according to your preferences — or if you’re installing a particular tool on your website.

Learn to be okay with making mistakes.

Here’s the rest of my take on what the gritty reality of learning to work with code like specifically from my perspective as a PhD student:

1. Program timeline issues:

The average time that it takes to complete a Ph.D. in the humanities is…”more than nine years?” Other results say 8.5 years, 9.5 years…it’s hard to say. I’m in my 9th year, and I’m revising, and will be done soon, and on the market this fall. I’ve had support the full time, first through guaranteed funding, and then through annually renewed funding as a TA in UW’s Interdisciplinary Writing Program. Because the UW is an R1 school that relies on graduate student instructors for most of its lower-division writing classes, and because the UW’s general ed. requirements include a mandatory composition requirement for everyone  (including transfers), and don’t allow students to test out of it, I knew that I could be relatively sure of getting funding. Not all schools have that kind of infrastructure. If you’re thinking about learning to code, and starting a large scale DH project, then you need to think about what the possibilities are for students who don’t finish within 5-7 years. Are there opportunities for you to keep teaching? Is teaching what you want, as opposed to taking a leave of absence?

2. Support issues for digital projects, vs. digital dissertations:

You wouldn’t know from reading my dissertation that I’m a digital humanist. I think it’s arguably still a digital humanities-influenced dissertation, because frankly, the research wouldn’t have been possible if not for resources like ECCO, EEBO, Google Books, and the various newspaper databases around, and my understanding of creative ways to search within them. Though it’s about literature and economics, like Visible Prices, VP isn’t involved. I could certainly write a dissertation on it — but in itself, that wouldn’t get it built, and the discussions in the dissertation wouldn’t be as rich or useful if they didn’t address the challenges of actually building it. Most of the discussions of digital dissertations and theses that I’ve run across have been about the value of a traditional diss with 4 long chapters vs. a diss with 10-12 microchapters — or about the issue of preserving a digital dissertation as formats change. Those are definitely valid issues — but what I haven’t seen discussed is the funding that would be required to get a digital dissertation (assuming that it were something other than an Omeka-based exhibit) developed and supported in the first place.

I could, of course, put off working on VP until I have a tenure-track job….and then put it off until I get tenure…and then … — in short, no. That doesn’t feel like a good option. Visible Prices might be really exciting, but I have a strong sense that it needs to be firmly in progress before I get a traditional job — not something to be started after that.

3. The ethics of seeking collaborators, for graduate students:

I’ll start by quoting Tara Andrews here, on the two main answers about whether you need to learn to code as a digital humanist:

  1. No, as long as you can think systematically and understand the possibilities that digital methods open to humanities research, who cares if you know how to run a compiler? That’s what collaboration is for.
  2. Of course you have to learn to code, because otherwise you will never fully understand the possibilities, and anyway you will simply not get anywhere if you sit around waiting for others to provide the tools for your specific problems.

I’m pretty strongly inclined towards the second answer — not just for understanding possibilities, but also for understanding limitations, and generally, to be able to appreciate what devs do, and to be a *good* collaborator. In terms of seeking collaborators, I’ve felt a bit limited by a couple of tensions. The major one is time: VP isn’t my job; and it’s only recently that it’s been formally recognized by my university as an important part of my work. (This is not to say that my dissertation director hasn’t been encouraging; he has.) But the time I have to work on it is limited by the pressures of both dissertating and teaching; and I’m not sure that those make *me* a good collaborator, or that there’s an obvious way to become a better one. My prospective collaborators, many of whom would be undergraduate and graduate students, have schedules that are no less fraught. And they see themselves as needing money, more than intellectual credibility or CV lines. Nor do I want to contribute to the whole Eternal September phenomenon.

I also don’t quite know what will happen to the project. Certainly, I hope that it will become a workable reality; my committee hopes that it will help get me a job, very possibly at an institution that is interested in developing it further. What exactly happens to my collaborator(s) at that point? — especially if they happen to come from non-academic institutions? I can’t help but think that it would be unethical to solicit help when I’m hoping that I’ll be hired somewhere with more official/local institutional support. To quote Andrews again, “a properly equal partnership of this form does usually indicate a truly innovative project, since it implies that there is something there that is academically interesting to multiple fields” — but I’m not really sure that I’m in a position right now to offer a “properly equal partnership.” And as Bethany Nowviskie has said previously, “consciously ignoring disparities in the institutional status of your collaborators is just as bad as being unthinkingly complicit in the problems these disparities create.” I’m hoping to make VP a major part of my job application, meaning that where I move, it moves. Frankly, at this stage in my career, I don’t think I can afford not to do that. And this puts me back into the realm of looking for “consultants,” i.e., staff, rather than collaborators, and offering to pay them in my limited cashflow, or in knitting. Or salted butter caramels, and other gluten-free treats.

I’m certainly not giving upon the possibility of modifying Simile’s Timeline. Obstacles happen; so does failure, and this isn’t a failure — just a big, hairy yak, from my perspective.

Last week, in a slightly different context, I was asked about my future career plans — whether they were more about a traditional faculty position, or an alt-ac position. I said at the time that I didn’t know — that I thought I would be happy in either, and that my experience thus far had taught me that it was much better to be flexible than rigid. That’s still true, but I realize that the other reason for hedging, which I couldn’t articulate at the time, was that I’m not sure which one will be more effective, in terms of improving the gritty realities of working with code as a digital humanist. I think that graduate students will need strong advocates with experience of those gritty realities on both sides of that divide, as long as it exists. And that if there are going to be digital dissertations, or projects, or projects-as-dissertations, then there will need to be traditional faculty to direct and support them.

I’m really looking forward to seeing how the constraints of collaboration will be affected by DHCommons — and hoping that they’ll be lessened. I wish I had a more upbeat ending for this post, rather than a yak, but this won’t be the first yak I’ve shaved; nor, I’m sure, will it be the last.