thesis/chapters/02_backdoors.md

## 2. Documentation as a backdoor


Exploring and stretching coding contingencies using code documentation practices as a backdoor to inject context in software.

Coding contingencies are conditions we found ourselves in. Not entirelly by chance, but on entirelly by choice as well. Sometimes these contingencies are economical: in order to work in this studio, you need to program with this framework. Sometimes affective: a friend shares the excitement over a new visual programming language. Sometimes


Politics of participation & representation
    from transfeminist servers to queer motto api to 360 degrees of proximity
    from alt-text poetry to p5js inclusivity guidelines to soupboat
Aesthetic practices
    uxn ecosystem: introspective programming
    the screenless office and chimeric worlding
    aesthetic programming and software studies


```placeholder
- when the entry points are blocked one has to search for backdoors
- little context for backdoors
- not only to participate in the making of software
- but also to inject values,
```

Here documentation is seen as a surface that could host principles in close contact with algorithms, letting them entangle and shape each other. A way to orientate our instruments towards "non-extractive relationships, but in the meantime, being accountable for the ones they are complicit with." (A Wishlist for Trans\*feminist Servers, 2022)


```placeholder
- a way to transform coding contingencies? see introduction / move it here?
- programming as a way of sharing context
- what is contingent in this context? (meaning slightly out of reach)
- materiality? text editors? popular languages? economics?
- what can be changed?
```

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.

The IT class in a public school. The job requirements for working in a tech company. An Arduino board received as gift for birthday. A colleague passionate about experimental music that drags you to a live coding concert.

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 (Ullman, 2017). 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 engaging with the sociality and communities around it.

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." (Fuller, Manovich and Wardrip-Fruin, 2009), and not just as technical tool existing in a vacuum.

An object that, in turn, can be used to probe its surroundings. Who is developing? Who is going to use it? Who is paying for it and why? How is it structured? It is a big and centralized system or a loose collection of small and interchangeable tools? How long is it supposed to last? How can be fixed if it breaks?

The main focus of this chapter is to explore software documentation as a surface where these kind of questions can be addressed. A place where the complexity of code doesn't blackbox ideas, and choices behind development can really be open source.

A way to situate programming in specific contexts.


```placeholder
- to expose people usually out of reach to different contexts
- literacy and exposition to certain concepts
- care vs attention economy
```

If we follow mainstream narratives, programming strives to be purely technical. Immaculate from the sin of politics. It's not rare to read comments online from users that demand to keep politics out from code repositories. Faithful to the western tradition of separate fields of study, coding wants just to be coding. All about performance and speed, new updates and features. A space where all problems are mechanical and can be solved.

But it wouldn't be fair to think that programmers simply don't care. Sometimes it's just a matter of being exposed to certain ways of thinking. Before the bachelor at the Accademy of Fine Arts for example, I've never been exposed to the writings of Donna Haraway, and I had no idea that concepts from feminism could have been so relevant also for me.

```note
if you cite Haraway better explain why it's important for you etc
```



Here code documentation could work as a backdoor: hacking its way to people that have never been exposed to certain topics. A way to offer an entry points to other worlds, and ground political choices into technical details.

from reaching a public to creating a public


### politics of participation and representation

#### from the trans\*feminists servers manifesto to the queer motto api to the 360 degrees of proximity

rethink participation in coding practice through femminist perspectives is not just swapping who can participate and who can not. doing so would just replicate current forms of exclusion.

the trans\*femminist servers wishlist engages with a more messy entangled complex way of understanding participation and technology
a way to open up for plurality, for questioning, for instability, for safety, for situatedness

1

these principles are reflected in the documentation of the queer motto api, that question the idea of software as a smooth service always available, with a motto generator that sometimes refuses to work, needs to REST or take a nap, or strikes to celebrate particular days such as the 8th march

by publishing in the form of an API, `ok what is an api in 2 words no meme of restaurant` the project engage by nature with other projects, such as the transmediale website, that uses it to display one random motto every day.

who wants to integrate the queer motto api services needs to come at terms with the condition offered from the readme

the readme of the API offer an understanding of the various technical process involved in the classic idea of software-as-service, but re - narrating them from a feminist perspective

errors, service availability, consent and refusal, tokenism, all the terms neutralized by the normativity of everyday tech are here reactivated as powerful narrative devices

2

```note
the concept of service could be link with 360 degree of proximity
```

code documentation is knowledge transmission, traditionally passed from top to bottom as in comunicating vessels

there are other ways however: where knowledge can be cultivated horizontally, emergent and reinforced by processes of collective learning, where transmission is not intended just one-way

feminists federating
fluid processes - not purely technical architecture, but affective infrastructure

process of collective learning and knowledge transmission 360 degrees of proximities

```placeholder
call with artemis and mika

- ask to record for note taking (not published)

- overview  code documentation
- entry point / backdoor
- surface: language formats and approaches
- practice: participation, representation, aesthetic

- documentation practices and politics of participation
- from wishlist for transfeminist servers to queer motto api to 360 degrees
- relation between wishlist and code documentation

- about 360
- where does it come from?
- how does it work? already started?
- does it involve also writing code documentation?

- situated code documentation? iterative? always the same? always different? depends on the context?

pls use our nicknames
estragon
e.zn

```



#### from alt-text as poetry to the discussion about accessibility in p5js to the soupboat

alt-text as poetry is a project by Bojana Coklyat and Shannon Finnegan
published as a website and other flexible formats it's an ode to the alt attribute in html image tag

alt-text is an essential part of web accessibility. it offers text descriptions which makes visual content accessible to people who are blind, low vision, or have certain cognitive disabilities

```note
rewrite or quote?
```

> Alt-text is an essential part of web accessibility. It is a system of text descriptions built into websites, which makes visual content accessible to people who are blind, low vision, or have certain cognitive disabilities. Alt-text has existed since the 1990s, but it is often over-looked altogether or understood solely through the lens of compliance. The resulting alt-text is often written in a reluctant, perfunctory style, but it has tremendous expressive potential. __This workbook re-frames alt-text as a type of poetry__ and provides exercises to practice writing it. __We don‘t just want alt-text users to be able to access visual content on the internet, we want them to feel a sense of belonging in digital spaces__
(from alt text as poetry)

the project could be seen as a whole piece of documentation dedicated to a single html attribute.
it activates a ways of thinking that goes beyond the technical, dealing more with the programmers and the users, than with the underlying machine.
HTML doesn't really complain about missing alt attributes, and that lead through the years to neglect its value for accessibility

here code documentation is used to encourage certain practices
not only to re frame alt-text as a type of poetry, but also to create a sense of belonging in digital space for people usually ignored by visual culture

---

in the discussions around the development of p5.js once i read an interesting thread about having in every script  a mandatory `describeElement()` function offering a text description of the running sketch (so are called p5.js scripts). p5js graphics are based on the html canvas element, that instead of organizing its contents in more or less semantic way as html does, presents only a matrices of pixels. this is a big hustle for screen readers and accessibility. the `describeElement()` function is the same as the one of  alt attribute, describing what's happening on screen.

the interesting part of the discussion was about this function to be mandatory in order to make the script run

and it is interesting to think how it would be reflected in the library documentation:
to which kinds of world would a choice like that openn?
not relegating them to the background, but instead making them as important as all the other (technical) choices that were made when desining the language

as for now it's not happened. open source projects like this one are collective effort, and to take big decisions with breaking changes like this one is always complex and slow

---

from my side: last year when developing my space on the soupboat i decided not to display images if they don't come with alt text

decision like these aren't really different from how a type system work, or how the syntax of a certain function is written. everything has been decided by someone. these decisions can create or claim new and safe spaces for participating to programming practice, or validate this participation

create / claim new spaces for participation, validate participation

```note
àhah ugly writing is difficult at the beginning but then gets funny
```

###  aesthetic practices - hello worlding


```note
adjust re-enchanting ?
```

Reenchanting code cannot be just a process of rebranding. Cannot be just a matter of changing the visual identity of the documentation, or washing it green or pink or black, or to capitalize on the inclusion of minorities.

Re-enchanting code means to create new narrations around software. As the artist James Bridle writes trying to untangle the complex social and environmental implications of digital computation: _"Technology is not mere tool making and tool use: it is the making of metaphors"._ (James Bridle, 2018) These metaphors, like code documentation, influence the way we think and use our tools.

- `Example:` Master-slave examples on version control software documentation. See [BitKeeper](https://github.com/bitkeeper-scm/bitkeeper/blob/master/doc/HOWTO.  ask#L223)
- `Example:` The military term _deploy_ adopted by CI/CD systems such as the one on GitLab.
- `Example:` The naming of group of servers as _fleet_ on AWS documentation, a term referring to naval formation, again with military connotation.

These metaphors orient code in the world. They reinforce, highlight and validate certain practices. A fleet implies centralized control, a swarm implies direct influences between participants, a federation implies certain degrees of independence, etc.

Nanni Moretti was slapping people in the face to remark the importance of words and their usage. In the movie _Palombella Rossa_, the main character suffered from memory loss after a car accident, and every dialogue was a precious handhold to find back his lost identity. His struggle was less concerning the correct usage of italian language, and more connected to the conceiled history in every word. A missing link between literal meaning of a term, and its broader traditions of uses, misuses, and transformations. The difference between talking and talking within a context.

To re-enchant code then means not only to _find & replace_ terms throughout the documentation, but to re-trace genealogies, to intercept and re-orient narrations, and offer a redemption arc to those projects that were abandoned. To re-enchant code means to coat new systems of meanings around it.




####  uxn ecosystem: re reading esolangs, plan-9, and virtual machines through the ecological lens

A good example is the work of documentation around the Uxn ecosystem, a personal computing stack initiated by the 100 Rabbits collective.

To meet their needs for a portable and lightweight infrastructure, and reduce the energy consumption of their digital tools (in order to live and work on a wind & solar powered sailboat)

The two of them live on a sailboat since, mostly offline and mostly offgrid.

To meet their needs for a portable and lightweight infrastructure they progressively moved away from the industry-standard toolchain

towards a self hosted, self developed, personal computing stack

```placeholder
... Weathering software winter --> plan-9 and esolangs seen through the lens of permacomputing
```
as reported in weathering software winter this years long reserach (and life project) worked as backward exploration of what was left behind by so called progress

the search to rethink personal computing from an ecological perspective touches on several projects left at the margin of tech culture


to finally settle on the idea of virtual machine and emulation with uxn and the varvara computer

in the unx documentation
plan-9 and several esoteric programming languages work as lore
and in this way are reactivated as ground for experimenting alternatives to face the ecological disaster


####  the screenless office read through tiger dingsun's chimeric worlding

```placeholder
tiger dingsun chimeric worlding is a text on graphic design used for worldbuilding
since special issue 16 i started versioning that text replacing graphic design with other practice / surfaces (ex: API as worldbuilding)
version it again for code documentation as worldbuilding
```

Our first project in XPUB was Special Issue 16: a collective exploration of natural language processing with a vernacular turn. It was published as an API, offering several functions to users to play with strings and texts.

During the preparation phases, I started versioning the readings we were trying to incorporate in our research. Applying small changes, replacing some words, shifting the context to resonate with our topic. From here came a new version of _Chimeric Worlding - What Can Graphic Design Learn from Poetics and World-building?_ by Tiger Dingsun, that was transformed in _What Can API Learn From Poetics and World-building?_.

Here the (versioned) author

```placeholder
the screenless office by brendan howell is a project to re imagine computing away from the visual interface of the screen
screen seen as catalyst of capitalism
```

weave the two together with the main concept of worldbuilding as a way to create alternative to capitalism



####  aesthetic programming as a bridge between software studies and creative coding


_Aesthetic Programming - A Handbook of Software Studies_, by Winnie Soon and Geoff Cox is an example on how to weave together these different discourses. The book explains the basic concepts of programming: it starts from variables and loops, to arrive at more complex topics such as machine learning or speech recognition. The technical curriculum offered is in line with other similar resources that target non-engineers. What's different here is a commitment to critically enquiry themes such as colonialism, racism, gender and sexuality, capitalism and class, and how are they embedded in code.

Soon and Cox prepared these lessons for students enrolled in a design institution, and curated the pubblication addressing a public somehow familiar with the discourses around software studies. Thanks to the vantage point of writing documentation for beginners, they could be super explicit and go all out with generous amount of references.



[ fade out towards outro ]