thesis/chapters/00_coding_contingencies.md

1. Coding Contingencies (2000)

Situate software as cultural object and propose documentation as a surface to explore it.

1.1 Context around software, besides technicality

How do you choose a particular programming language, a coding paradigm, a development environment, an infrastructure where to run the code, and so on? These are not just technical choices, but rather coding contingencies.

Personal decisions, trending technologies, curiosity and boredom, to name a few. A talk that touch on esolangs as form of frugality, a collegue passionate about live coding that drags you to an algorave night, a crypto-boyfriend, the tech stack of a company, a drastic turn of events, etc. etc.

These contingencies are situated in specific contexts.

Programming then is not just sharing code, but sharing context. A significant statement about our relationship to the world, and how we organize our understanding of it (Ulman, 1998). A point of view and a perspective to look at reality, before attempting to get some grip onto it with a script. A way to deal with both the software and hardware circumstances of code (Marino, 2020), but also create space and relations with non-code entities (Mackenzie, 2006).

It's an approach that helps us to think about software as a cultural object. Something "deeply woven into contemporary life –economically, culturally, creatively, politically– in manners both obvious and nearly invisible." (Software Studies, 2009), and not just as technical tool existing in a vacuum.

---

An object that, in turn, can be used to probe its surrounding environment. Who is developing it? Who is paying? For what reason? Who is gonna use it? How is it structured? It is a big and centralized system or a loose collection of small and interchangable tools?

There is a difference in scale of space and time between our biological and social selves, and the internal clock of a computer, or the reach of its network. This often lead us to picture wrong images of the technological complexity we are participating in. That's why in order to debug complexity we probably first need to debug software (Shirky, 2014). Understand how does it work, or why it doesn't work the way we expect, either in its technical, cultural, or environmental outcomes.

To participate in the making of software it's a way to attuning with the troubled times we are living in. A chance to gain understanding and agency on things that often slips away from our awareness because too big and slow, or small and fast. Relying on the unthinkable speed of microprocessors and the phantasmal aura of wi-fi, we can make some sense of the unkown of software (Chun, 2022), and the alien and complex systems they constitute.

This is a process that does not stop with programming, and is both more and less than just an engineering problem. It is more because of its public nature, the fine mesh of exchanges and compromises in the communication between people and machine, and between people and people, and between people and resources, and resources and time, and so on. But is it also less than that in the way that when it works, it works, and code disappears.

In this economy of interactions and interfaces issues emerge.

1.2 Introduce issues around software

Outline a map of critical issues related to software culture, grouping them in three main flavours:

1. Biased and hostile environments

   • Toxic masculinity
   • encoded chauvinism
   • western monoculture

2. Evergrowing complexity

   • Intimidating learning curve
   • disproportion of means
   • mistification

3. The universal solution™

   • Techno solutionism
   • gray tech
   • ideology

1.3 Propose documentation as a surface to address these issues

1. Welcoming diverse knowledges
2. Lowering barriers and create entry points
3. Orientate software in the world

• (500)