copy texts

cc.md

@@ -0,0 +1,165 @@
+---
+title: Coding Contingencies
+---
+
+Chapter 1 is not a written as a text, but runs a simulation.
+Coding Contingencies (CC) is a procedural take on how different characters got to code.
+
+How did they 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.
+
+Personal decisions, trending technologies, curiosity and boredom, to name a few. A talk on Code Golf as form of frugality, a collegue passionate about live coding that drags you to an algorave night, a crypto-boyfriend, the tech stack of a company, a drastic turn of events, etc. etc.
+
+These contingencies are situated in precise contexts.
+Programming then is not just sharing code, but sharing context.
+It's providing a point of view and a perspective to look at the world, before attempting to get some grip onto it with a script.
+
+Using the simulation as a writing machine we can articulate these CC with some benefits:
+
+1. Suspension of judgment
+   Within the scope of the simulation it's not necessary to label good or bad choices.
+   (That would have been the case for a machine learning writing device, for example)
+   One character could decide one morning to write their own operative system from scratch using Red Stone circuits in Minecraft, and it would be fine.
+   Due to the nature of the process, even the most absurd starting point it's a valid and powerful narrative device.
+   In this way it becomes easier to explore marginal cases, improbabilities, and non-conform situations.
+2. Discrete temporality
+   A simulation does not happen all at once, instead it is a process that evolves through time.
+   This happens in both discrete steps and long-term iterations.
+   Discrete steps can be further subdivided, with the possibility of magnifying details.
+   Discrete steps can be grouped together, that results in the ability of zooming in and out a story.
+
+3. Partiality
+   Partecipants entangle gradually, and do not come as a monolithic block.
+   They can be imagined as lines: merging together and branching away, tying and loosening knots, preserving memories. (Ingold)
+   This leads to multi-facets characters, where not all the elements needs to interact with each other all the time. (Haraway)
+
+4. Orientation
+   Zooming out from the particular, we get a glimpse of a more gradient and diffuse process.
+   A subtle sense of direction emerge through (simulated) randomness.
+   (By design) this simulation sees software as a mean to orientate these trajectory.
+   How does certain programming languages facilitate certain ways of thinking, and totally block some others?
+
+This procedure helps us to think about software as cultural object. Something "deeply woven into contemporary life –economically, culturally, creatively, politically– in manners both obvious and nearly invisible." (Software Studies, 2009), and not just as technical tool existing in a vacuum.
+
+---
+
+software contingencies
+
+```
+------+.
+|`.    | `.
+| `+--+---+
+|   |  |   |
++---+--+.  |
+ `. | `.|
+   `+------+
+```
+
+the simulation
+
+first we need things to simulate:
+
+-   actors
+-   programming languages
+-   use cases
+
+the simplest simulation
+
+aha how do we define actors?
+
+it reminds me of this OOO statement:
+objects sink into themselves
+that is an effective and graphical way to describe technical reference pages and auto generated API specs, with nested nested nested layers of list.
+
+to avoid that
+let's define actors not for what they are but for what they do
+(that is fun bc then i wrote grandma, that means functional grandma, that means not someone that has grandchildren but someone that does grandparent functions ??? ok this is not fun anymore and i am sorry)
+
+> notes
+
+-   expand simplest simulation: few elements, 1:1:1 relation
+-   more context for the ooo statement, or keep it for later
+-   the grandma joke is not super fun
+
+-   actors
+
+    -   web designer
+    -   interaction designer
+    -   graphic designer
+    -   musician
+    -   teacher
+    -   student
+    -   grandma
+
+-   programming languages
+
+    -   javascript
+    -   python
+    -   vvvv
+    -   pure data
+    -   haskelz
+    -   rust
+
+-   use cases
+    -   research
+    -   work
+    -   art
+    -   fun
+    -   activism
+
+then we need to combine thigs from the three categories
+
+00 web designer, rust, activism
+01 teacher, python, work
+02 grandma, rust, fun
+03 interaction designer, vvvv, art
+04 musician, pure data, work
+05 musician, haskel, research
+06 student, python, art
+07 student, javascript, work
+08 student, javascript, fun
+09 graphic designer, haskel, research
+...
+
+side note
+the first in a series
+NOT is the series on theory in italian by NERO editions
+their first pubblication was Capitalist Realism, Mark Fisher and it was a declaration of intents.
+at some point every first is a declaration of intents.
+but is that so also in random generated series?
+at first one is tempted to write: no
+the random generated series is random, and its first element is random as every other.  
+ but taking a step back, zooming out, one wonders: which element is the first? where is the declaration of intents?
+could the command that generate the random series be the first, significative, element of the series itself?
+
+now that the setup is done, the simulation can start.
+
+to build something meaningful out of these random combinations we can balance between what is defined and what is not.
+leveraging on the unknown of the simulation gives room for narrations.
+
+so for example we have #04
+
+a musician what is their background?
+which kind of music do they play?
+where are they based?
+
+using pure data an open source visual programming language
+works in real-time
+focus on interaction and sound design
+
+for work which kind of occupation?
+is it for interactive installations?
+to teach sound design?
+for live gigs?
+
+see how there are a lot of open questions in the first and third fields, while the programming language is slightly more defined and fixed. this is a good starting point. obviously a programming language is vast and complex and with dozen of features one could be interested in, but for the sake of our system it is useful to leave these things unsaid.
+
+we can use the software as a pivot to orientate the relation between the actor and their intentions.
+
+from where they are coming and where do they want to go?
+who took them there?
+what do they need?
+which particular aspect of pure data resonates with their view of the world?
+is it the open source nature and the licensing of the source code?
+the welcoming community thriving around the programming language?
+or the visual paradigm that facilitates the thinking about and connecting abstractions together?

complexity.md

@@ -0,0 +1,9 @@
+---
+title: Complexity
+---
+
+-   I'm trying to learn how to approach complexity as an environment.
+-   How to stay complex without forcing the result being complicated
+-   how to reduce complexity without loosing value.
+-   This usually happens when diverse actors participate in the process
+-   when ideas and practices traverse through the software without being totally framed into it.

contexts.md

@@ -0,0 +1,21 @@
+---
+title: Contexts
+---
+
+list of (possible) communities that relate to situated software
+
+[specific]
+every group in xpub
+un \* salta
+aiep
+non linear
+varia
+
+a b s t r a c t i n g
+
+[generic]
+students and tutors in study programs that relate with software studies
+collectives, organizations, associations with focus on digital technologies
+professionals working with digital technologies
+
+too vagueeee

devices.md

@@ -0,0 +1,17 @@
+---
+title: Devices
+---
+
+-   tools
+-   thoughts
+-   anecdotes
+-   excercises
+-   prompts
+-   strategies
+-   references
+-   toolkit
+-   practices
+-   maps
+-   coordinates
+-   memes
+-   readme

hackpact01.md

@@ -0,0 +1,9 @@
+---
+title: Hackpact 01
+---
+
+-   #01 Where does software documentation begin and where does it end?
+-   What about README files, tutorials, guidelines, comments in the source code, and demos?
+-   How porous or tentacular is this surface?
+-   Set some references by looking back at the works made last year and read them through the axis of code and care.
+-   Explore common templates of documentation and their habitability.

hackpact02.md

@@ -0,0 +1,13 @@
+---
+title: Hackpact 02
+---
+
+-   #02 Write documentation & focus on its contents and style
+-   Write documentation for selected prototypes from the many made last year.
+-   Could this process create a new public, or transform their original ones?
+-   As initial case study focus on the [Padliography](https://hub.xpub.nl/soupboat/padliography/), a tool developed within XPUB to keep track of the amount of scattered Etherpad documents used to take notes and work togheter.
+-   During last year it's been used only in the context of our class, but after some adjustments it's now flexible enough to be offered also to other constellations orbiting around the _XPUB & Lens-Based wiki_.
+
+-   What does it mean to offer it to someone else?
+-   How to talk the same language in different contexts?
+-   How to be clear without oversimplifying?

hackpact03.md

@@ -0,0 +1,12 @@
+---
+title: Hackpact 03
+---
+
+-   #03 Write documentation & focus on the process of writing
+-   Open the writing process and experiment collaborative practices for the documentation of the [Workbook](https://hub.xpub.nl/soupboat/workbook/)
+-   A tool developed together with Supi to keep track and annotate configurations for different instruments and facilitate learning process.
+-   Write the documentation together.
+-   Could there be multiple voices or is necessary to keep a single point of view?
+-   What does it mean to write with different intensities?
+-   Can we imagine ways to zoom in and out details level?
+-   How different knowledges can participate in the process?

hackpact04.md

@@ -0,0 +1,18 @@
+---
+title: Hackpact 04
+---
+
+-   #04 Write documentation & focus on the surrounding context
+
+-   Expand the research to tap into ongoing projects outside XPUB, such as freelance work and parallel research
+-   candidate could be : [Object Oriented Choreography](../ooc-summer-session/), a performative project of mine related to networked technologies, VR and contemporary dance.
+
+-   Are there ways to make the documentation process more sustainable (socially, economically)?
+-   Are there strategies to overcome low-resources environments?
+-   Search for escamotages to create space and energies to document.
+-   Use documentation to work with collaborators, clients, and end-users and approach code from multiple point of view.
+
+-   Try to infiltrate the industry of software development through documentation.
+-   Attempt to expose their public to these issues in subtle ways.
+-   Offer entry points and escape routes from the automatic outcomes proposed by tech solutionism.
+-   Offer alternatives to sedimented roles in the care of software.

hackpact05.md

@@ -0,0 +1,20 @@
+---
+title: Hackpact 05
+---
+
+-   #05 Write documentation & focus on who is writing it
+
+-   What are the relations between documentation and the community around a software?
+-   Experiment with versioning.
+-   Try to have several instances of the same documentation.
+-   Try to question who gets to write and who gets to read the documentation.
+-   Shift the moment in which the documentation happens.
+-   Where the documentation is hosted?
+
+-   Question the nature of the documentation
+-   what does it take for granted?
+-   For what kind of public it is produced
+-   what kind of public does it produce?
+-   How does it normalize the context around the software?
+-   What are its politics of access?
+-   How does it create entry points and how does it gatekeep?

hackpact06.md

@@ -0,0 +1,10 @@
+---
+title: Hackpact 06 07 08
+---
+
+-   #06 #07 #08 Towards final project
+
+-   Collect and organize the outcomes from the different hackpacts.
+-   Trace trends and synthetize common and diverting aspects.
+-   Research for a surface that could host this different facets.
+-   How can it inhabit the usual places where documentation is hosted?

list-multiplicity-mol-law.md

@@ -0,0 +1,5 @@
+---
+title: List and multiplicity (Mol and Law)
+---
+
+A list doesn’t have to impose a single mode of ordering on what is included in it. Items in the list aren’t necessarily responses to the same questions but may hang together in other ways, for instance socially, because a list may be the result of the work of di√erent people who have each added something to it. Yet it remains open, for a list di√ers from a classification in that it recognizes its incompleteness. It doesn’t even need to seek complete- ness. If someone comes along with something to add to the list, something that emerges as important, this may indeed be added to it.

narrative.md

@@ -0,0 +1,7 @@
+---
+title: Narrative
+---
+
+Close to the Machine is a nice book from Ellen Ulman.
+It talks about people working with software.
+It's narrative.

project.md

@@ -0,0 +1,5 @@
+---
+title: Project
+---
+
+Compile a list of resources to explore the documentation of coding related practices from a community-oriented perspective, as a process of sharing knowledge and making worlds together around situated software.

size.md

@@ -0,0 +1,7 @@
+---
+title: Size
+---
+
+Expanding a bit on: situated software.
+Which kind of situatedness am I thinking of ? ? ?
+In order to get there let's recall what happened in the last 25 years aroud my phisical body. (In a sparse order)

sumiyaki.md

@@ -0,0 +1,28 @@
+---
+title: Sumiyaki
+---
+
+Sumiyaki Monogatari is a manga from Shigeyasu Takeno based on the book Sumiyaki Nikki, by Toshikatsu Ue.
+Sumiyaki Monogatari -> Tales of a Charcoal Burner (2005)
+Sumiyaki Nikki -> Diary of a Charcoal Burner (1988)
+
+It is a story about a young charchoal burner that works alone in the rural area of the Wakayama prefecture, Japan in the late fifties.
+The atmosphere of the story is really charming: it mixes the knowledge about a craft to the folklore of rural Japan.
+There are here two differents takes on daily life: one about the work and one about the world.
+Two different grips on reality.
+A firm hold on logs, branches and wood, and slippery dreams with yokai and spirits.
+The charchoal burner job is one of fatigue and extreme efforts, yet the story doesn't feel frustrated or miserable.
+
+(ok this is not to romanticize physical work, the good ol' times, Japan, or this lonely boy starring at the fire in the kiln almost burning his face off)
+
+The point is: it reminds me of the struggle of programming.
+And it makes me wonder: there would ever be this kind of poetry around software development?
+Every craft is surrounded by stories, narratives and myths.
+What narrations surround software?
+Matrix and the green source code floating around? OK, but that is fantasy.
+The series with the hacker jailbreaking crimes? E va be, again fantasy.
+Black Mirror? Horror and dystopia.
+What is wrong with software?
+
+Close to the Machine, by Ellen Ullman is a nice reference here: she writes about struggles of software and struggles of daily life.
+The book is exaclty like the tales of the charchoal burner: it mixes situated knowledge and days in the life of a (female!) software developer, with the folklore and myths haunting the Silicon Valley across the eighties / nineties. Probably this folklore called neoliberalism is to blame, when there are so few poetic accounts of software development. Probably is also not so easy.