Category: Hacker and Professor

As discussed in previous posts in this series, navigating the waters of the scholarly and technical assumptions each of us bring to the Perseids collaboration is not always simple.  Some of this disconnect has been beneficial to the project — when we each stick to our respective roles and areas of expertise we have very little redundancy of effort.

 

But, when it comes to joint decisions about the direction of the project, our Hacker and Professor run into some disagreements. Bridget regularly has to remind the team that the inclusion of new unplanned features and workflows mean that other things we had hoped for would have to wait or be dropped entirely. But Marie-Claire can be frustrated by the “workplan-waving.” This recurring issue stems in part from Marie-Claire not being able to fully assess the complexity of the technical solutions, and Bridget not understanding what drives the scholarly and pedagogical requests. These misunderstandings make it difficult for them to decide which things should remain in the workplan and which new avenues should be pursued with students.

 

So, in keeping with the experimental nature of Perseids, The Hacker and the Professor have embarked on a skills exchange as an experiment of their own. Bridget has been coaching Marie-Claire through a self-initiated journey into programming and web design. Marie-Claire has been mentoring Bridget through an assignment she normally gives to her Greek mythology classes, which aims to analyze the transmission of a classical Greek myth through its representation on an ancient artifact.

 

It has been a truly fascinating journey so far. What follows are some of the thoughts they have about their skills exchange.

 

Bridget

First, I have to confess that my interest in helping Marie-Claire obtain some more technical skills is not entirely altruistic … I hate the part of my job that requires that I be realistic about timeframes and the effort needed to develop code. I want Marie-Claire to gain these skills for her own growth, but also so that when we prioritize the work the burden for understanding what takes time is more fully shared. I am not a natural teacher though and I am incredibly thankful for the outstanding free resources available for this. The Khan Academy site in particular has been great in providing a logical order to tackle topics, exercises, and examples to work through.  (A side-benefit of this for the project is that it has been allowing us to think more concretely about certain features of the ePortfolio and self-assessment tools that we hope to make available on Perseids). We then take those examples and Marie-Claire applies them in the context of work she is doing with her students using the Perseids platform.  

 

I do believe that I have the better end of the bargain here though. Marie-Claire is a world-class teacher who cares tremendously about her students and her subject, and I could not ask for a better mentor. As a young college student I was focused on getting out into the real world as quickly as possible to save time and money and didn’t take advantage of my education to explore some of the topics in ancient religion and myth that serve as the underpinnings for our society. I have passed by thousands of objects in museums and public spaces without thinking about what they say about our social history and our internal perceptions of ourselves, our human relationships, and our culture. I have tried over the years to be more well-read and informed in a self-directed, and often misguided, sort of way, but doing so without context makes it hard to get engaged with the material. Reading the primary and secondary sources with a specific question in mind changes that. What I find particularly interesting about this experiment is that when we first embarked on it, I found myself getting distracted by thinking about superficial aspects of the digital tools that could enhance presentation of the material or my eventual reporting on it. But as I delve deeper into the actual content and discuss the questions I have on it with Marie-Claire, aspects of digital presentation and publication are actually quite far from my mind. I am very curious to see if and how they reenter the picture as I get closer to producing the results of my little research project.

 

Marie-Claire

Learning programming has been an exhilarating experience so far. Let me be clear: I am not saying that it all comes easy and everything is great. Quite the contrary. I struggle through the basics and often get stuck on little things. I also often get it into my head to undertake projects that are too difficult at my current level and I sink into quagmires. Yet, every small success is a reward, and Bridget’s support, patience, and encouragement is a constant motivation. In fact, I feel that I’m getting the better end of the bargain in our skills exchange, because I have access to Bridget’s advice and experience, without which it would be very difficult not to be intimidated by the material. The excellent Khan Academy tutorials also do a great job of rewarding every bit of progress. I am constantly reminded of the very similar effort I had to make when I was learning Greek and Latin, and the immense joy of discovery I experienced as I got better. As a teacher, I never want to lose sight of the challenge of learning.

 

In fact, becoming a better teacher motivates me through this learning experience. Anything I learn, my students will get to learn too. So as I make my way through my lessons and the sessions with Bridget, my head is buzzing with ideas for student projects that will take advantage of these skills and transmit them to my students. As a Classics professor, I strive for my discipline to be taught better and more widely, so that the wealth of wisdom and beauty that we inherited from the ancient world be made accessible to as broad an audience as possible. In today’s world, that includes code and programming. These techniques enable us to study our field in deeper and more meaningful ways than we ever could before and to disseminate the results in sustainable ways. Technology also makes our discipline more inclusive than ever before, because it allows us to approach the Humanities from a common middle ground that crosses cultural and social gaps.

 

As you can see, I am the dreamer in the Perseids team… For me, programming is very much like fine arts, music, or languages. It is creative, yet also exacting, and forces me to think in a disciplined fashion. Hopefully, that will help me stick to the workplan.

 

Alright, enough musing. Can we talk about code now?

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

Marie-Claire Beaulieu and I have a running joke between us playing on the difference between “professing” and “hacking.” When we have a Perseids Project hackathon, the hackers “hack” and the professors “profess.”  This is meant to be funny, but it also exposes a more serious question — how, in a digital humanities project, do you manage the different approaches and expectations developers and humanists bring to project in a way that is productive and encourages rather than discourages continued collaboration?

The inspiration for this blog post comes from our presentation at DH 2015 in Sydney, “Building Tools that Build Digital Humanists.” This paper was actually mistitled in a way that highlights this very point of potential disconnect — what we should have called it was something like “Building tools while building Digital Humanists” because otherwise it implies that the tools themselves provide the magic solution of how to develop digital skills.  Eliminating the tool as black box is a primary motivator behind many of the design decisions we make on Perseids. Exposing humanities scholars, researchers and students to the inner workings of the software tools we build for them, the raw data on which they operate, and the development process itself has resulted in some unexpected benefits and challenges.

We have been following what I call an Agile-inspired approach to building tools for Perseids.  We engage the users at every step of the process, releasing features for them to work with well before the tools are fully finished.  This is a fairly common practice in software development, but it introduces some unique challenges in academic environments, where programming and other resources are typically in much shorter supply, and where we often cannot finish what we start. Agile methods take for granted that there will be another sprint.

It sometimes feels a bit like looking for the silver lining in the clouds, but we have found that using tools mid-development with constant, and maybe even a bit too in-your-face, access to the raw data structures can open a window into exactly how the tools let users manipulate and shape the data. The process has allowed both students and researchers to understand their role in the creation, curation and annotation of texts through the scientific process of creating and using the data. It has also exposed the critical role the humanist plays as product designer and tester of the tools we develop to support the research and publication process.  Or, as Stephen Ramsay says, as “builders and makers.” (Ramsay, Stephen. (2011). “On Building.” http://stephenramsay.us/text/2011/01/11/on-building/ )  

It also builds their digital skills. We have scholars working with us who, prior to becoming involved in the project, had no programming background or experience with XML files, and are now developing their own analytical tools and services in XQuery and managing their JSON configuration files through GitHub.  One researcher, initially very hesitant about her computer skills and afraid of breaking the system, is now our star quality assurance expert who eagerly tests new releases and can be counted on to find and report the bugs within hours if not minutes. Enterprising students and professors have become emboldened to develop additional solutions that cleverly work around current limitations in the system and which inform our design process and feature list.

It’s not all roses though.  Our development approach of rapid prototyping has led to many misunderstandings about exactly how experimental certain features are, and dashed hopes about how soon things that we trial can be brought to readiness for actual use.  

Another real challenge is that for projects that are funded in spurts you want to try to make sure that the code you write can be easily taken up and added to by new developers, but with code that changes so rapidly, keeping documentation up to date can be daunting and it is often the first thing that has to go when time runs short.

I am trying to be better about managing expectations about what we can realistically do by when, and imposing discipline in the form of requiring user stories and well defined requirements for new features, but as a developer in this environment it is not always easy to say no, especially when it’s the shiny new features that grab attention, while the amount of work needed to make them real is not always easily justifiable.  

I think it’s worth it though.  One of my favorite quotes from the group of scholars who make up our ad-hoc software development team on Perseids is the following, from Drs. Robert and Vanessa Gorman of the University of Nebraska Lincoln:

“The principal power of the Perseids/Arethusa system is the information it puts into the hands of student and instructor.”

It is this perspective that keeps me going when I’ve had to explain for the upteenth time why the system looks and feels a bit like Frankenstein. We have quite enjoyed working with the monster in our lab here, and we feel that it is precisely this wires-exposed nature of Perseids that is inspiring and fosters learning and experimentation.

Bridget Almas,
Perseids Hacker