You can always capture my attention with scholarly work labeled infrastructure, and even better if the first section in it emphasizes that we’re going to be concerned with boring stuff. I live for boring stuff. This may be an adaptive strategy that my mind developed to contend with living in fairly bleak ecosystems for much of my early adulthood where the primary visual features were electrical lines, boxes, sheds, pipes…the things that we like to hide, or fail to see.
The Ethnography of Infrastructure therefore rocketed up to the top of my reading list when it was endorsed by two colleagues on my social media (thank you!). I was further astonished to see that it was published in the American Behavioral Scientist, and with an affiliation to UC San Diego—my own intellectual home turf, as it were, just like engaging with the mundane, invisible and boring. I had my first scholarly encounters with engineering on the campus of UC San Diego when I transitioned into a multi-disciplinary postdoc that was situated in the liminal space (we call this “cross-appointed” in academia) between cognitive science and the “combinatorial” entity of computer science and engineering, two departments that were themselves each an amalgamation of multidisciplinary topics and concerns not always appreciated outside of their walls. This was also the time and place where I first began to use qualitative methods, which has continued to be an approach we value in the Developer Success Lab, supplementing our survey studies and intervention projects with both qualitative interviews and open text items that allow us to contextualize our operationalizations with the direct voices and tangible experiences of participants.
This paper is an older one, and it’s only my own fault (or enjoyment, as I prefer to take a Lucky 10,000 approach to such things) that I hadn’t ever read it. Right from the beginning, Star establishes that we are going to get meta, and we are going to be challenged to think more carefully about where we see information about the world, and also that the writing is going to be fun: “It takes some digging to unearth the dramas inherent in system design creating, to restore narrative to what appears to be dead lists.” I would set aside some time to consume this paper and to reflect on each paragraph’s proposals. If you’ve never read this style of paper before, it will feel very different from a quantitative research paper with its methods, statistics, and results sections. However, as you read you can note the conceptual rigor that you are being carried along by: Star interweaves references to concepts and ethnographic thinking and thinkers into specific and tangible examples of human experience that range from conversations between scientists, to digital libraries, to the choices made about sizes of cars or the color of bandages. Along the way, you are challenged to consider the values that are frequently implicit in these choices, and those left out.
There are many lines in this paper that knock you back and make you think. For instance: “With any form of work, there are always people whose work goes unnoticed or is not formally recognized (cleaners, janitors, maids, and often parents, for instance).” I have been interested for a long time in who the unnoticed people are in software development, and I think that many software folks are interested in this too. Particularly in the realm of infrastructure, being unnoticed is often described to me by “infrastructure people” (there is no single title that truly captures it across engineering, so please feel free to self-audit and self-identify into or out of this category) as both a good or a bad thing. Infrastructure frequently sets an explicit goal of enabling other developers to forget about its existence. At the same time, infrastructure people report to me that the people part of their self-identity is infected with this invisibility. And this is a problem because recognition gates resources.
The Ethnography of Infrastructure is deeply interested in field work and what field work can give us, and in developing names and language for the ways that decisions are baked into the information designs that we interact with. Despite not being specifically focused on the concerns of software teams and despite its age, I recommend this paper as a meditative read that can help you think about learning to see (or feel, or hear, or touch as the case may be) those decisions. I was also struck by the fact that the unique experiences of infrastructure workers in software have themselves remained relatively less visible in the larger software research literature–a motivating gap for our upcoming study on this. I am not sure whether qualitative scholars would describe it this way, but the quantitative researcher in me also sees a great deal of commentary about cause and effect in this paper and how paying attention to choices made over time can help us understand the meaning of people’s choices that we previously dismissed. For example, Star elegantly describes how “An extra keyboard stroke might as well be an extra 10 pushups” when it interrupts the experiential work of a user, and that paying attention to the size of that impact (seeing it in the first place, and believing it is real in the second place) is a path to greater understanding. At the end of reading this paper I felt that it had succeeded not just in making me curious about the “boring,” but in showing that few things in the world are boring at all when we really engage with them.
Creative Commons Attribution 4.0 International License (CC-BY 4.0)