You cannot select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
121 lines
6.1 KiB
Markdown
121 lines
6.1 KiB
Markdown
# Provisional txt dump
|
|
|
|
## Software without documentation
|
|
|
|
Software without documentation is invisible.
|
|
|
|
Therefore it is important to document it. Software without documentation tends to slip away, to disappear. Therefore it is important to have some notes on how does it work, how does it tackle the problem to solve.
|
|
|
|
These guidelines are helpful when sharing programs with others, as well with future selves. They provide an entry into the messy relationship between developers and machine.
|
|
|
|
## bonus caption for eventual images
|
|
|
|
Being programming slightly different from cycling, people tend to forget what their code does, and how did it get there. (Maybe because it doesn't involve muscle memory?)
|
|
|
|
Software documentation is a defensive mechanism operated from our past selves to protect the present and future ones.
|
|
|
|
Cuneiform writing and comments. (even though this is cuneiform writing and syntax highlighting)
|
|
|
|
### Education and initiation
|
|
|
|
```note
|
|
not sure where to put this yet
|
|
it is to elaborate why this idea of backdoors vs for example just rebranding
|
|
```
|
|
|
|
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?
|
|
|
|
Three sources that could be explored here relate to an alternative to the model of technosolutionism
|
|
|
|
- the plot of her undoing - saidiya hartman - the undoing of the plot
|
|
- federico campagna - technics and magic - _taqiyya_, _kitman_ and secret - education vs initiation
|
|
- a way of saying from bergamo dialect about cinders and embers
|
|
|
|
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.
|
|
|
|
<!-- 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. -->
|
|
|
|
|
|
|
|
|
|
```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
|
|
```
|
|
|
|
- queer technologies?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
### 2.2 Technical is political
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
### 2.3 Hello Worlding
|
|
|
|
|
|
```
|
|
reclaim take back
|
|
reenchant intercept
|
|
reassure keep going
|
|
|
|
reclaim renegotiate, recuperate, remember, refuse, reactivate
|
|
reenchant redirect, rebirth, reboot, rebrand, redeem
|
|
reassure refrain, refresh, regret, reaffirm, register, readme
|
|
```
|
|
|
|
### reclaim
|
|
|
|
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.
|
|
|
|
```placeholder
|
|
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
|
|
```
|
|
```placeholder
|
|
How can documentation create new spaces around code? Where new spaces means spaces for who are excluded.
|
|
```
|
|
|
|
```placeholder
|
|
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.
|
|
```
|
|
|
|
```placeholder
|
|
Think about projects related to accessibility, and space built by and for people with diverse ability. Alt-text poetry could be a good starting point.
|
|
```
|
|
|
|
```placeholder
|
|
Think about the efforts to create safe spaces to learn.
|
|
```
|
|
|
|
```note
|
|
A couple of brainstorming paragraphs feel free to skip sorry for the inconvenience
|
|
```
|
|
|
|
Writing code documentation is tricky because requires some degree of astral projection. Who's writing is asked to leave their body and describe code from a different perspective. From the point of view of someone else. Unlearn what seems to be obvious and be generous with future readers.
|
|
|
|
|
|
Learn to code is like learning another language: not just a new bag of words and a different grammar, but rather a different way to think. It means not just learning what are the things that move and the ones that are fixed, but also how they relate and make meaning together.
|
|
|
|
Coding means to express ideas with the reduced vocabulary of a programming language.
|