Digital Humanists as Master Builders

I’ve been thinking about the now relatively long-standing debate in Digital Humanities about ‘who’s in and who’s out’ and wondering if there’s an angle we haven’t been considering (by writing ‘we’ this makes an assumption I’m ‘in’, of course, which I have to admit feels both presumptive given there’s a chance I don’t fit someone else’s criteria and odd given I’m a Senior Lecturer in Digital Humanities). My suggestion is that we need to stop only thinking about the specific technical skills a digital humanist needs, and consider the function the (extra)discipline plays in the broader community, as well as the role(s) it is likely to need to play in the future. It’s becoming clearer, even to a natural pessimist like myself, that humanists are only going to build more digital tools, methods and services as the years progress. I’m contacted fairly regularly by people considering starting digital projects but unsure either how to start or what standards are expected. In New Zealand, if they were building a house, they might contact a Master Builder – a builder accredited by a trade organisation that the customer can trust will either do a good job or be held accountable (to some degree) if they don’t. Often they’ll coordinate subcontractors like plumbers and electricians, to make sure everyone does a good job at the right time, or work with a project manager performing that role. Some Master Builders might be old hands who built houses for years but are now a bit creaky and prefer to manage teams of younger builders who do the work under their guidance. The younger builders (quite possibly accredited themselves) are probably keen on the flash new materials and techniques, and possibly more up to date than their older colleague, but as their elder and better he would probably be the person you’d prefer to go to in a pinch.

So what’s my point? My point is that there might be a layer on top of the list of DH skills you need to display to be ‘in’, and that layer might be almost as important as the list itself. If our practice is to be useful to our peers, they (humanities students, teachers and researchers, and perhaps cultural heritage and influences professionals who haven’t done much digital work) need to know i] Who to contact if they’re interested in developing a digital project to good standards and ii] That the person they’re talking to will – if they can’t do it themselves for whatever reason – guide them in the right direction. What characteristics might a ‘card carrying’ (that could be a weird idea) DHer exhibit, in no particular order?

  • Membership in ADHO or a Constituent Organisation, and evidence of participation in ADHO or CO events, THATCamps etc.
  • An awarenes of the range of digital tools, methods and services used across the digital humanities community, and the standards required for them. (The layer underneath this is obviously crucially important, but it will shift over the decades and is best discussed within the community, as regularly happens and will hopefully never stop. Geoffrey Rockwell’s suggestions in a recent edition of Humanist prompted this post to some degree, leading to this list overlapping in places).
  • A degree in the humanities, a record of ongoing engagement with one or more fields, and an understanding of the broad intellectual terrain.
  • Evidence of publication in quality scholarly publications. (This one is difficult. It’s important to indicate an understanding of traditional scholarly norms and an ability to implement them to trade standard, but I don’t want to give the impression I’m referring to a narrow range of traditional analog academic publishing options. It’s also debatable, because I know of several people who I doubt have published but I respect very highly as digital humanists. What I can say is that if it isn’t a current expectation it probably will be in the future, at least for practising within universities.)
  • Experience building and consulting on digital humanities projects.
  • An understanding of project management methodologies and software development best practices.
  • An understanding of the requirements digital archiving, preservation, and data management present.
  • An awareness of local and international funding agencies, and an understanding of how to gain funding for digital projects.
  • An awareness of the history of digital humanities and humanities computing.
  • An awareness of significant digital humanities projects and key people in the local and international communities.
  • Engagement with the digital humanities community via trade publications, social media, and online seminars.
  • Update (a fairly fundamental oversight, actually): Understanding and support for community values like the importance of learning to code, inclusiveness, egalitarianism, and the broader DIY ethos.

Lists like this are sometimes embarassingly self-serving, but you get the idea. I guess it boils down to the fact that I’m more concerned about the type of person someone gets when they make that phonecall to engage a digital humanist than the specific skills that DHer might have. If we (only) try to legislate for a narrow range of skills we’ll find ourselves in the same position computer scientists did in the 1960s, when Ceruzzi notes there were heated debates about who could call themselves a ‘computer programmer’ or not. The rate of change was so great back then that every time they identified a skill requirement another would pop up.Although defining a list of trade skills is crucial for training purposes, it’s possibly more important to ensure people who represent themselves as DHers are capable of guiding our colleagues in the right direction. Let’s face it, it’s quite conceivable that someone could engage an expert in TEI or topic modelling and get very poor advice for their digital project on 3D modelling of paper ships. What would be worse for our community: that someone who doesn’t have a specific skill represents us well, or that someone with it makes us all look bad?

References

P.E. Ceruzzi, A history of modern computing, MIT Press; Cambridge, Mass., 2003, p.105.