Professing is a rather mysterious activity. We teach, we write, we read, we muse, we talk… seemingly in no particular order. Understandably horrified, our hacker friends wave their workplan at us and tell us that we need to stay in scope, and that such and such feature is not to be released until the second quarter of next year, and what are the requirements please?
There is a method to the madness, I assure my hacker friends. We do have well-defined research and teaching agendas, and our progress (especially for junior professors) is meticulously charted by our institutions. Yet, the flexibility of our schedules and work culture means that we often have the opportunity (and occasionally the obligation) to take up an unplanned project. We are also responsible for mentoring student theses, the topics of which may vary quite widely, and are renewed with every cohort, every academic year.
So how do we build tools and infrastructure with equal parts of professing and hacking? Obviously, this requires true intellectual engagement on both sides, so that the result is not an immediate means to an end, but rather a process whereby Humanities questions and technology are explored and developed at the same time. Writing user stories and requirements allows us to think about our objectives, not only from the user perspective but also from the inside out. What do we want the data to do? And more importantly, how should it do it?
As Bridget Almas pointed out in her latest post, the wires-exposed nature of Perseids is helpful in the course of this experimentation because it lets us think concretely about the objects we are manipulating, namely the data and the technology itself. And yes, we acquire skills that we never thought we would have when we signed up to be Humanists.
Now, does this change professing? Yes and no. No, because experimentation is built into research and teaching. Hitting roadblocks or dead-ends is a natural part of discovery, and the process of learning is one of trial and error. Yes, because we are now placed in a global environment where we must produce data and tools that can be reused in order to ensure any degree of perennity and sustainability. Explaining this to our administrators is not always easy, since expectations for Humanities faculty are centered on single-author publications, especially books and journal articles. Even so, the highly individualized practices of our profession are eroding to make way for teamwork, which in turn requires us to stick to the workplan.
And that’s not half-bad. In my opinion, one of the greatest benefits of this method is the built-in review system. As we think through our projects with our team and scope out the requirements, we go through a back and forth that helps us all to refine our work. Then, when we release new features and workflows, we try it all out in class or in our offices. In the process, we gather a wealth of feedback that we can immediately (or as soon as the workplan allows) put to use in a new iteration. This differs radically from traditional publishing models in the Humanities, in which most feedback is received after any changes can be made. Although our Frankenstein must deal with all sorts of growing pains, at least we piece him together in a positive and forward-looking environment.
Marie-Claire Beaulieu, Perseids Professor