@ -24,10 +24,6 @@ The first flow seems nothing new but the nature of every kind of technical docum
The second one is more labile and subtle: it deals with softer things than software. With political choices that inform technical details, with code close to codes of conduct, with power dynamics and forms of exclusion in the making of software. It is slippery matter, practiced with a range of different approaches, such as reclaiming spaces, enchanting tools and reassuring others. Reading code documentation highlights that the making software does not stop with coding: that there is a massive labor of care besides engineering headaches, and that is valuable as much as technical contributions.
```placeholder
And these different aspect will be addressed in the second part of the thesis.
```
### Coding contingencies
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.
@ -57,7 +53,7 @@ Another term to contextualize (and dismantle?) here is _developer_.
By stripping down every trace of professionalism and formal education, let's agree that a developer is someone who tinkers with code. No matter at which level, nor distance, nor experience. No matter if for work, for fun, for study. No matter if one is actively involved in the development of a tool, or comes from the user perspective. Ellen Ullman writes that programming is a disease, but the situation is even worse: code is contagious material, touch it once and you are a developer.
This thesis explores code documentation more as an interface then as a publishing surface. A permeable passage from us to code, and from code to us.
This thesis explores code documentation as an interface. A permeable passage from us to code, and from code to us.
The first part focuses on who is reading, who is addressed, and who is left out. Code documentation brings an understanding on software by disclosing its magic. It reveals what can be done with it, and where are the limits. By lowering barriers and creating entry points, documentation broadens participation. By reaching not just beginners, but experienced programmers as well, it affects thinking about software continuously, and from different perspectives. In order to create accessible entry points and speak to different people however, it's necessary to question the usage of language, to criticize the amount of energies required for writing, and to address problems of inclusivity within tech communities.
The third section is focused on worlding, and the relation between code, documentation practices and political aesthetic.
```note
it could be nice to have a small glossary / way to situate / elaborate on these terms:
(or even better to use them to organize the chapter and the examples)
coding contingencies context around code, either intentional or contingent
political aesthetic political choices that inform technical choices
worlding aesthetic practices that create narrations around code
would it make sense then to move here the coding contingencies section from the intro?
end elaborate on that a little
```
Possible structure for this chapter:
1. __coding contingencies__
- programming as a way of sharing context
- what is contingent in this context? (meaning slightly out of reach)
- materiality? text editors? popular languages? economics?
- Decoupled documentations? programming tutorials detached from a specific language.
- See [Advanced beginners series](https://robertheaton.com/what-is-an-advanced-beginner/)
- Apparently was difficult to imagine also the end of Lisp, see Patterns of Softwaree
- Javascript Realism. It's easier to imagine the end of the world than the end of node.js (or not?)
2. __Technical is political__
- political choices informing technical choices
- create new spaces / claim space
- aesthetic programming
- p5.js on accessibility features
- trans*femminist servers and 360 degres of proximity
- queer motto api
3. __Hello Worlding__
- p2panda
- uxn ecosystem
- the screenless office
- queer technologies
This section is focused the relation between code and documentation practices, in the form of coding contingencies, political aesthetic and worlding. These terms come from different directions and with different focuses, but all of them offer ways to create context around code.
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)
_References for technology and worlding_: Trans\*feminist Servers, Zach Blas, Tiger Ding Sun, James Bridle, Soon and Cox, Richard Gabriel.
```note
from here on is still a bit scattered, but i plan to feed the contents in the structure as soon as it becomes more clear!
```
```placeholder
2.1 Coding contingencies - see introduction?
```
_Case studies_: The soupboat. Avantwhatever.net. Queer Motto API. The Screenless Office. The uxn ecosystem. `list wip`
### 2.2 Technical is political
### Documentation as backdoor
```note
(need more glue here and there between these paragraphs)
@ -34,11 +83,10 @@ _Aesthetic Programming - A Handbook of Software Studies_, by Winnie Soon and Geo
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.
### Going with the flows
### 2.3 Hello Worlding
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.
There are 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.
