| layout | subtitle | title | author | cover-image | date |
|---|---|---|---|---|---|
post |
Things the Humanities can Learn from Software Development I |
When All We Have Is A Hammer |
Yeehaa |
/images/hammer.svg |
2013-12-11 13:57:27 -0800 |
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 fact, 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. This pimped out 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 our inadequate research and teaching tools individually, however, may be the fact that they are completely unrelated. 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 take into account that our 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 or add missing features. This process also is not limited to the virtual environment. Standing desks, shoes, and dietary regimes are very much part of the discussion. While it may seem overkill to some, I believe that such deliberate use of tools marks the difference between craftmanship and dumb labor.
By solving all problems with his hammer, the humanities' scholar reduces all problem to nails. Appropriate tools do 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. Tools not content drive a craft forwards. It is this very insights that motivates Coding the Humanities.