The third section is focused on worlding, and the relation between code, documentation practices and political aesthetic.
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)
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.
if you cite Haraway better explain why it's important for you etc
```
Ellen Ullman is a programmer and writer, one of the few women working as developer in the Silicon Valley during the 80s and 90s. The combination of coming from the humanities, being a self-taught programmer, and especially being a woman made her the archetypical outsider in the IT industry. At the same time, this very position granted her a unique ethnographic perspective, capable of looking critically at this environment, both from the inside and from the outside. In more than one passage for example, she laments the general lack of literacy between many of her coworkers.
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.
_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.
Note that this work of care is not always possible. Sometimes the context doesn't feel safe to be so exposed, or there are no energies, or time, or means available. Sometimes it is necessary to act in a more nuanced way. To leave breadcrumbs and sow seeds. Or to raise voice and be firm. Different ways for different moments.
There could be several approaches for making worlds around software. Here are some keywords to refer to the kind of flow these worlding practices activate. To _reclaim_ is to get something back: something that was stolen, or taken away, or lost, or forgotten. To _reenchant_ means to intercept and reorientate towards different directions. To readjust a process, or to move for a different purpose. To _reassure_ serves as prompt to keep going. It helps making meaning together, and refresh ideas. It offers way to register choices, keep track and share what has been done so far.
These labels are open and loose, overlapping and not mutually exclusive, temporary and on the move. They are meant to change, to expire fast, and going bad even faster: they require continuous treatments and repeated efforts. That's why I'm naming them all after the _re_ prefix: to aknowledge their being in progress, second hand again, already contaminated. Borrowed by friends and foes, that had borrowed themselves from someone else. One should diffidate of these categories because they're instable. Nonetheless, they offer ways to visualize different strategies to create worlds around software.
There seems to be a risk in reducing sociality around software to a conflict between "friends and foes": a risk to reproduce forms of exclusion and violence typical of the IT world. To just swap good and bad, and offer clean solutions.
Try instead to apply Chantal Mouffle's concept of agonistic politics to software development, intended as struggle between different hegemonic projects. But maybe is to much of a stretch
Think about the works around queerying technologies, from Zach Blass to Trans\*feminist servers, to Queerying UNIX, to 360 degrees of proximity, the Queer motto API.
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.
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.
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
We tend to put ourselves in difficult situations. By aknowledging complex problems, we aknowledge also the impossibility for simple solutions.
It would be easier to believe in technosolutionism: to think that issues such as biased algorithms or discrimination in IT could simply be solved by installing a new product, or updating our software to the last version, or writing code documentation following a new innovative framework.
But then what are we doing? If all these efforts to write documentation are not revolutionary, if they don't bear solutions, it they tackle minimal portions of major and systemic issues. Where is the twist in this idea of code documentation as publishing practice?
