Week 11

This week’s had me thinking a lot about the nature of scrappy and DIY work, and when it becomes too much.

I really appreciated Cecile and Merriam’s reflections on how, at Bard College, they lacked a robust budget to build up their program’s technological infrastructure; in response, they relied on free tools and also built networks with colleagues who could loan materials. I think this is a terrific idea for many reasons: it builds relationships and avoids siloed programs; it shares resources in what is likely an environmentally friendly way; it sets up students to be resourceful in working on DH projects in similarly under-resourced settings outside the institution. (One of my own most valuable experiences in graduate school for library science involved a web designer teacher letting us know that we were free to use all the subscription software available in our department’s computer lab, but that she planned to teach us how to do all our assignments using the software that is available on a Windows PC — because she knew many of us would work in spaces where that was our only option. I cannot stress how useful that was to me; I can hack a wild amount of web design in Word and Paint.)

At the same time, I think we run a risk when we encourage construction of this kind of scrappy infrastructure: Risam reminds us of the emotional labor of digital carework for diversity, and this builds upon the emotional labor required to construct DIY DH spaces: the labor of relationship building, of maintaining equipment lending programs, of sustaining projects built with free technology that may not have any enduring investment supporting it.

It’s fun and exciting to pull things together on a shoestring budget, often in the face of seemingly impossible odds. But, does it really model care to suggest that this is the way to go? What is the boundary that we need to model for saying: if there’s no infrastructural support from the institution, the personal/emotional/relational cost is too high. I’m not really sure; it might differ in every institution, every project, and for every team and individual. But: how do we teach that this boundary can and should exist, if we want to cultivate DH workers who perform care for themselves, their work, and their communities?

1 thought on “Week 11

  1. Katina Rogers (she/her)

    YES, this is such a tricky tradeoff. I’m reminded of this 2011 piece by Bethany Nowviskie, “A Skunk in the Library” (https://nowviskie.org/2011/a-skunk-in-the-library/):

    > A “skunkworks” (all one word) describes a small and nimble technical team, deliberately and self-consciously and (yes) quite unfairly freed from much of the surrounding bureaucracy of the larger organization in which it finds itself. This enviable cutting of slack and tolerance of the renegade is offset by placement, on the shoulders of the skunkworks team, of greatly raised expectations of innovation. […]

    > Which brings me to this. ‘Skunkworks’ is a pretty evocative name for this concept, and it’s a slightly dangerous one to apply in a library. Why dangerous? Well, there’s a level of honesty and self-awareness involved in not calling them snuggly bunnies. How easily do you imagine skunks are tolerated within an overall library culture that values consensus and teamwork, rightly wants to see innovation blooming everywhere, seems to be moving (if fitfully) toward erasure of privileged status within its own ranks, and which retains a certain lovely – and, (let’s admit it) often gendered – self-conception of its members as the handmaidens of scholarship, people with a calling – with a vocation to serve?

    > That last bit (the service vocation) is the kicker.”

    Anyway, it’s a long talk and there’s a lot more to it, but what I think is worth considering is the ways that a push toward scrappy/DIY mentalities can mean that the expectation to do more with less becomes further and further entrenched. When is it caring to make something happen despite the odds, and when is it more caring to say no, we can’t actually pull that off?

Comments are closed.