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.
43 lines
3.5 KiB
Markdown
43 lines
3.5 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. -->
|