Author Archives: Paige Morgan

Today I have mostly been… (my Day of DH schedule)

Here it is, almost 7 p.m., and I’m just managing to get my posts up. But this is what my day has looked like so far.

6:30 a.m.: wake up to news that a friend has gone missing on a solo hike. Worry; pray; worry; rage; pray. Make breakfast, coffee.

7:15 a.m.: chat with long-distance partner, both about life in general, and about a logo that I’m designing for a departmental program.

8:00 a.m.: shower, dress.

8:30-11:30 a.m: Walk to campus, and prep for the class I’m teaching at 11:30. It’s a writing link, meaning that it’s a full 5-credit composition class that’s paired with a class in a specific discipline (this quarter, Geography). Because I’m teaching while trying to finish a dissertation, I’ve been trying to avoid doing more than minimal teaching work on non-teaching days — so most of my prep is happening this morning (though it’s according to a schedule that included classroom activities that I managed to prep last week, when the quarter began).

My students have gotten their first essay prompt for the other class, and I’d asked them to annotate it in Google Docs with their questions and comments, so that we could break it down and get started on it today. I need to see whether their annotations provide material that I can easily build on, and try and get a measure of how they’re approaching the assignment. Happily, they’ve asked great questions, and made good comments. I mark out a couple of things to build on.

I’ve also asked them all to provide brief answers to a short question (in this case, “Name one situation (any situation) where you would not want to use writing (unless you absolutely had to.) Why do you think that writing wouldn’t be an ideal strategy?”). My purpose in doing this is to just get them more comfortable talking about writing, and how they make decisions as writers (both in academic and non-academic contexts). Again, I’m hoping that I’ll be able to build on what they’re saying, and draw them into discussion in a way that taps into their instincts about writing without triggering their fear-of-academic-writing reflexes. And again, I am fortunate — I see some really great connections between their posts. And some interesting situations: they would not want to use writing to tell someone how to fly a plane if it were about to crash, to break up with someone, to negotiate with bees (or with anyone who was so dead set against them that the writing would have no effect).

I make a plan to talk with them about the characteristics of writing that make it difficult to use in the situations they mentioned, and then to ask them “What if you *have* to use writing in this situation? What would your priorities be, and what would you have to do to mitigate the difficulties?” I want to say to them that I often think that the academic classroom is a place where writing is not ideal — so that it’s a process of trying to make it work, rather than strive for perfection. But I don’t know whether that will fit, and really, I’ll be happy as long as the discussion we have feels useful, rather than falls flat.

11:30 a.m.-12:50 p.m.: TEACH. And it goes fabulously — except for a minor techfail that my normal fix doesn’t solve. (One more thing to add to the to-do list). The discussion of the Daily Question goes well; as does the discussion of the essay prompt annotation. We break down the assignment into a list of concrete steps, and make a plan to get started on the first part of it for Wednesday’s class. We also look at the Working Syllabus which they created. They’d listed skills and challenges that they wanted to work on for the quarter; I asked them to identify which ones they think are most important for this assignment, based on the discussion we’ve had about their annotation. They identify Organization/Effective use of space, Making sure that they’ve fulfilled the assignment’s requirements, and Using the vocabulary of geography correctly. I think these are great priorities, and I send them off, with praise and encouragement.

1:00-1:30 p.m. — Buy, and manage to scarf down most of a lunch from the campus cafeteria, and print several documents from the class to share at a TA meeting.

1:30-3:00 p.m.: TA meeting, where I hear what other linked writing class instructors are doing, and where we talk through any issues we’re having. There are a couple, but on the whole, it sounds like everyone is figuring out the rhythm of the quarter, and rapport with lecture course instructors, etc.

3:00-3:50 p.m.: meeting with a faculty member about the logo I was working on this morning, and the project to increase visibility of a particular program. I can’t say anything about this, except that I’m learning interesting things that I think will be useful, assuming I end up in a teaching job.

3:50-4:00 p.m.:  STARVING. Buy a small cottage cheese and fruit from cafeteria. Think that I need to coordinate better in order to have cottage cheese and fruit from home on hand.

4:00-4:30 p.m.: review documents that I’m copyediting and fact-checking for another department (a paying job); send time estimate and a couple of clarifying questions to my contact.

4:30-4:40 p.m.: try to catch up on the news and such. I buy tickets for the Opening Night Gala of the Seattle International Film Festival, featuring Joss Whedon’s Much Ado About Nothing! I will get to have a drink in the same room as Nathan Fillion!

My friend in Scotland hasn’t been found yet. I am frightened for his wife and daughter.

4:40-5:00 p.m.: attempt to sort out snafu regarding a badly printed course reader that does not contain the correct pages of a particular text, for a prof who’s teaching abroad and knows that I am a fixer. She’s asking for a particular set of pages, but looking at them, they don’t contain the material she thinks they do. I flip though the book to find that material, and copy both sections.

5:00-5:20 p.m.: walk home from campus. Realize that I forgot to customize my farm box order (oops!), so I shall have a mystery box of produce arriving tomorrow. (Well, creativity in the kitchen is fun.)

5:20-5:30p.m.: Scan book pages, email to professor, explaining why I’ve included pages that she hadn’t asked for, and where the particular excerpt she mentioned starts.

5:40-5:50 p.m.: chat with Sarah, my co-organizer for the Demystifying Digital Humanities workshops we’ve been running throughout this year. We have a meeting with the Simpson Center for the Humanities Associate Director tomorrow, to talk about re-applying for funding next year.

5:50-6:40 p.m.: respond to a couple of emails, and find the other post that I wanted to publish for this event; check it over, edit it slightly for clarity, and get it up.

6:40-7:30: write this timeline.

Still on my list?

Make dinner

Knock out at least 1000 words of diss (I’m trying to send off part of a chapter revision to my director). The 1000 words shouldn’t be too bad — they’re mainly shorter signposting discussions that I tend to leave out, if I don’t think about them carefully. Still, they need to get done.

Come back and write a follow-up to that other post.

Check the proposed metadata for the Blake Society’s Voice Project page (I’m a trustee for the Society) — this is something that I’m really behind on, and I’m embarrassed about it, especially after I’ve emphasized how important it is.

 

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.