thesis/rug/provisional_text_dump.md

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

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.

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.

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

How can documentation create new spaces around code? Where new spaces means spaces for who are excluded.

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.

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.

Think about the efforts to create safe spaces to learn.

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.