In our first class, naturally, we talked about what DH is, which led to the consideration of what qualifies someone as a DH practitioner. And that discussion turned out to be pretty enlightening, with the use of some provocative (in a good sense) metaphors.
To get people riled up, I brought up Stephen Ramsay’s oft-commented-upon, semi-serious (very serious?) suggestion that to be a respected, or perhaps respectable, practitioner of DH one must be a coder. As Ramsay admitted, he made the suggestion with partly the same intention, “to piss off half the room,” and he further greatly broadened his stance just a few paragraphs later, saying that what he really meant was a facility to build things, that
But, nonetheless, I decided to push the point with the newbies in the class (which, for all intents and purposes, might as well include me).
One of the students, Matt Younglove, who is a music doctoral student, argued otherwise. Composers, after all, don’t necessarily need to be able to play instruments. He noted a famous center in Paris where composers are not allowed to touch the equipment; rather, there are very highly skilled technicians (musician-technicians?) who do that. [Update: As Matt mentioned below, it’s IRCAM] The composers are composers nonetheless, still producing music — just as a DH’er who doesn’t code, but might be deeply involved in designing or building a tool would still be producing DH work.
Which begged the question: OK, composers are producing music as a DH’er produces DH projects, but doesn’t a composer still have to have a sense of the instrument(s) for which she’s composing? A composer who writes a chord for a saxophone (or, as Homer Simpson once called it, a “saxomophone”), or who has a soprano singing a note an octave below middle C is not, really, a composer in the true sense of the word. Similarly, someone with DH pretensions who wants to build something, but doesn’t know the capabilities, strengths, and limitations of the tools and code she’s working with isn’t much of a digital humanist.
But the students, again, pushed back. The point is having a major role in making or using a tool, finding a new form of dissemination, etc. Not everyone needs to be able to code to do that.
I’m not sure where I stand. Playing devil’s advocate once more, I suggested that part of being in a field is having the ability to evaluate work in the field. So how can I evaluate a project if I can’t in any way parse the code? How can I know whether the decision to program a project in Ruby led to different capabilities and limits than if it had been done in Python?
Dan Fawcett, and ACS Ph.D student, suggested another metaphor. Maybe DH is more like a language for a native speaker: even if we can’t articulate its structures (curse you, whoever banished sentence diagramming from our schools!), we still can tell what works and what doesn’t, what’s proper English and what’s not. Here too, I’m not sure the metaphor is totally apt–maybe because I’ve read the papers of too many undergraduates who do not seem to have a full grasp of their native tongue. But it’s an interesting thought: that one can have a general grasp of, say, the differences among languages, codecs, etc. without having to know the nuts and bolts.
Let me issue a couple of clarifications here. First, none of us were arguing in favor of ignorance, but rather trying to think about the limits. I actually agree with the students on a lot of this. Second, as you can see from the syllabus, a significant part of this course involves an introduction to building and making on a basic (although not BASIC) level: html, CSS, Python. But also on a much higher level: CMS management. We’ll see how it goes.