- December 11, 2013
This is an old blogpost that I wrote in 2013. To me, it marked the beginning of a personal journey that I'm still on today. Over the last 7 years, the way I look at research, learning, and work has completely changed. But in essence, it's all here. In other words, this blogpost is mainly here for nostalgic purposes.
Coding the Humanities is not about technology or even programming. It is all about tools. Software is a blind spot for the humanities. While our discipline is deeply invested in self-reflection, we hardly ever think about the digital tools that we use to produce and disseminate these deep thoughts. As a result, we fail to see the obvious. The applications that facilitate our teaching and research, were not written for us, let alone developed by us. In act, they are unfit for our needs.
In our research, we use a wordprocessor for almost everything. This factotum is part of a larger suite of proprietary enterprise applications, which is appropriately named after its intended use context. In an office setting this swiss army knife may be highly effective, but for research purposes it is rather blunt. Our pimped up typewriter does not offer any form of semantic mark up, has no citation management, and discourages collaboration.
In teaching, the situation is possibly even more dire. While the omnipresent word processor is a mismatch with our research practice, most online teaching platfforms go to the other extreme: they are indistinguishable from it. Or at least its appearance. Their user interfaces exactly mimics the classroom setting. Its conceptual metaphors are sessions, discussions, assignments, etc. This also means, however, that they make little to no effort to actually enhance our practice. Digital tools have the potential to radically change the way scholars teach and students learn. Unfortunately, this promise remains unfulfilled.
Even worse than the inadequacy of the individual research and teaching tools we use, may be the fact that they keep research and teaching completely separated. Of course, it is possible to embed text documents, hyperlinks and presentations in our teaching platforms, but that is about as far as the integration goes. We complain about the ever-increasing disconnect between our teaching and research, but do not realise that our current tools do nothing to help us bridge that gap.
No matter how bad our workflow is, we do not talk about tools. Humanities' scholar have more important things to discuss. We are interested in content, not in the structures that create it. We thereby selectively ignore most twentieth century theory which should have taught us to focus on the structures that produce knowledge rather than on their results.
How different is the situation in software development. Programmers shape their work environment until it fits their individual needs. However, this shaping and tweaking does not happen in isolation. It is done in a constant dialogue with the community. Developers fight entire wars over text editors and IDE's (Integrated Development Environments). If they do not like a certain framework or library, they write their own, add missing features, or fork the project. And this process of discussion and deliberation is not limited to the virtual environment. Standing desks, shoes, and dietary regimes are very much part of it.
Deliberate use of tools marks the difference between craftmanship and dumb labor. By solving all problems with their hammers, humanities' scholars reduce all problems to nails. Appropriate tools not only increase efficiency, they also enhance the ability to differentiate between different problems, and enable solutions to problems that have not even been discovered. Practice, not content, drives a field forwards. It is this very insight that motivates Coding the Humanities.
Photo by T R A V E L E R G E E K on Unsplash