In early November I had the opportunity to participate in the Speaking in Code conference at the Scholars’ Lab at the University of Virginia in Charlottesville, a summit on the use of technology alongside humanities research run by the Lab’s director Bethany Nowviskie and her unbelievably talented, incredibly helpful and congenial team.

The conference was a good 7 hour drive from NYC, but it was the vivid height of autumn and the gorgeous Virginia countryside helped clear my mind. I was excited to see my friends among the attendees and meet other attendees for the first time, some well-known ‘visionaries’ in the field, and others talented practitioners across the DH (Digital Humanities) world whose work I did not know. For many of the attendees, I too would be among the latter category. The conference was slated to be a singular experience, a handful of diverse DH practitioners in an environment expressly defined as one of professional and personal respect for diversity. A rich and varied community of coders, each exploring the issues and opportunities presented by software in DH scholarship.

This was new.

Inspired by the desire to surface deep issues in DH into discourse, the first ‘question’ of the conference was a central one – the seeming disconnect between ‘tacit’ and ‘explicit’ knowledge. I understood this to be like the experiential lessons learned when handed a lump of play-doh as a child versus having its elasticity, strength, etc. described and demonstrated in vocabulary and numbers. A similar disconnect can be seen between technology knowledge (that of computer scientists and/or coders) and scholarship knowledge (that of humanists) in a wide range of DH study from pedagogy, scholarly communication, collaboration, discourse and ‘building’. Historian/Maker Bill Turkel presented on his work, detailing many ways a cognitive leap between these knowledge types is possible – interfacing with the (literally) tangible through the use of robotics, circuitry, new software and interfaces and even 3d ‘made’ objects. The intersection of theory, physical and software skills that these physical computing approaches require (and embody) helped initiate a vigorous discussion.

Play, it was clear, was central. Popping the hood, getting in there and making art out of spaghetti. DH education could benefit greatly from an effective adaptation to the fact that in some cases the discourse, learning and collaborating that underlie the scholarship/software relation could use a little less university and a little more kindergarten.

At its core, however large or small the group and whatever process and tools they employ, DH also requires the application of novel ways of thinking and new ‘processing’ software (or hardware) on sometimes-familiar source data. Humanists often do not even think of their sources as data, but in fact nearly every imaginable body on which research can be done can be seen as data – ripe for a panoply of potential DH analyses (sociological, historical, anthropological, archaeological, literary or otherwise). That having been said, the concepts and consequences of DH are likewise dazzlingly complicated and ever-dynamic, at any moment as varied as there are teams and practitioners. The manifold considerations that shape DH compel all manner of solo, pair and group collaboration efforts.

We who do DH are working towards and preparing for this goal of knowledge exchange and collaboration. The question arose, given that many Computer Science degree requirements include some form of humanities, what about the reverse? Should effective, ‘tacit’-knowledge oriented computer science classes be part of a standard educational curriculum? In addition to courses, shouldn’t more humanities departments permit the use of a programming language to fulfill a DH practitioner’s language requirements? Coding helps make sure good theories of logical thinking and problem-solving are instilled in the ‘coder’ even as computers and the production of software fade into the background. It helps students to understand that which is increasingly hidden for the benefit of the ‘user’ behind hand-held devices with slick, simple, tactile interfaces.

This is not to say all slick, simple, tactile interfaces are bad – far from it! Stefan Sinclair lead the next presentation and set the stage for our ongoing discussion, showing us some engaging and intriguing ‘procedural’ interface design. He also lead us in an exercise of team design, in which we learned that the unexplained but implicit forms of ‘tacit’ knowledge in this new culture of learning were not physically embedded (indeed, occluded) in a discipline – we do learn by doing, but in not so formulaic a pattern – rather, the formulas and ‘muscle memory’ of design and coding are stepping stones to the ideas that drive us. Great design accomplishes these goals, as evidenced in a number of Stefan’s projects to date.

More in Part 2.

Please note: Many of the ideas expressed in this essay emerged from a conversation between the assembled ‘Speaking in Code’ participants. Given the interactive nature of this summit, attribution of each idea to its likeliest proponent would be impossible. Any credit is due to all who attended and it is my hope that recounting these ideas will stimulate new practices and concepts to inhabit and expand the reader’s own creativity.