Computing Conviviality

Conviviality is a state of being between members of group whose work within that group is felt by all to be meaningful, cohesive and enlivening. Classic descriptions of what it is like to engage in convivial work include the crop-mowing scene in Anna Karenina, where Tolstoy describes the aristocrat Levin's experience of sharing the manual labour with his workers. For Tolstoy, the aristocratic socialist that he was, the portrait of Levin was pretty much a self-portrait. But he knew conviviality was a thing relating work and technology.

Conviviality with modern technology is hard to conceive of. We may all be on Facebook, or are editing the odd shared spreadsheet, but each of us is pursuing personal goals and personal ambition: how can I look good by doing this? will this get me promoted? can I publish about this activity and become famous? This is particularly the tragedy of modern universities - even for academics who preach socialist principles, often the flip side is an ego which seeks to publish their excoriations of the system as a big-hitting journal paper. 

Conviviality entails the loss of ego as far as possible; it entails service to the group over the climb to the top. But most importantly, conviviality entails collective technological work. This is where things get very complicated for conviviality in the 21st century.

Our computer technology allows each of us to transform our environment in remarkable ways. For Illich, whose study of conviviality is one of the most penetrating, the antithesis of conviviality was represented by the mechanical digger: unlike the shovel which required the collective effort of many to dig a hole, the JCB could do the work of 100 people in one go. Computers are not shovels; they are JCBs. 

Heidegger had an interesting way of talking about the fruits of human technological labour: it served, he argued, to reorder nature into what he called the "standing reserve" - the world as revealed to us as "instrumental". Through such reordering, a field could become a coalmine, or a river bank could become a point of crossing with a bridge.  With computer technology, the standing reserve that is manipulated is often data: a disordered collection of data becomes categoried and compartmentalised; a stream of categorised data can coordinate new human action for a common purpose. In this way, technological work can be convivial perhaps - except that it rarely feels like it. 

Heidegger's metaphor can be useful if we are to reconceive conviviality in a the digital age. The problem is that computer tools are generally not very good tools for doing the jobs they are intended to do. This is partly because the design of tools is generally shaped by the work-as-imagined by the software developers, not the work-as-done by the actual users. In trying to engage in the work-as-done, users have to find ways of working around the work-as-imagined in order to solve their problems. Typically this involves many mouse clicks, the frustration that the interface doesn't make the "thing that you want it to do" easy, or that the system simply doesn't work as expected. These experiences apply particularly to educational technology. In my institution, where we've recently introduced Canvas and Teams, it is noticeable how much time is being spent by academics dealing with an interface which, whilst it is much better than Blackboard, still demonstrates the difference between work-as-imagined and work-as-done. 

This requires both what David Graeber calls "imaginative labour", and an awful lot of tedious clicking - so the high-level intellectual work of academics is replaced with low-level interface work.

A possible homologue of Heidegger's river bank or empty field is the software designer's interface constraints. Although such things are the product of technology, and in some sense, already "standing-reserve", it also presents humans with natural challenges in the form of stress, boredom, etc. The problem is that everybody is having to build their own bridge through the interface - the scope for collectively working with each other to build a bridge that everyone can use is constrained by barriers in the software, or institutional barriers which stop people getting access to aspects of the software which might be changed for the better for all. The second problem is that even if it was possible to build a bridge across the software's "river bank" for all, there would still be a gap between "work-as-imagined" and "work-as-done" for new users of the system.

Conviviality requires co-design. Enid Mumford's work on co-designing systems with nurses in the 1980s and 90s has become very important to me recently: she certainly deserves much greater recognition (and an alumnus of Liverpool University). For Mumford in the 80s, coding was sufficiently common to all forms of interface so that it enabled her to find ways of engaging nurses at quite a technical level in the functionality of the system, so that they could shape it to reflect work-as-done.

Today, the equivalent level of commonality is the Application Programming Interface. Good computer systems today are built of services, and good systems with good APIs make all the underlying services available to anyone who wants to access the data providing they have sufficient privileges. 

I've spent some time recently working with professional service staff and academics in working with APIs to achieve effective and efficient solutions to the problems of the interfaces. While the solutions we have developed together can be redistributed to other staff, it is much better if the means for creating those solutions is shared so that everybody understands how they can build bridges together. This is not to say that everybody should learn to program, but it is to say that engaging with a deeper technical understanding of systems is to open doors to deeper institutional discussions about the problems that academics and support staff face.

Conviviality occurs when we recognise the problems that each of us face, and relate them to our own problems, whilst recognising that working together can help us all. Coding creates a universal framework for articulating and sharing deep problems - it is not something that is done TO people: that merely creates a new set of constraints of "work as imagined". The magic only works if it is done WITH people.