diff --git a/chapters/00. Coding Contingencies.md b/chapters/00. Coding Contingencies.md index 8975fff..49b21f4 100644 --- a/chapters/00. Coding Contingencies.md +++ b/chapters/00. Coding Contingencies.md @@ -99,18 +99,18 @@ The simulation is structured as a series of stages: The first step is to decide on the participants of the simulation. -Although we could sink into a well of details to describe actors in the most accurate way, in a simulation just a detail it's enough to start. +Although we could sink into a well of details to describe actors in the most accurate way, just a detail it's enough to start. -Who and what are they? -When and where are they coding? -And what do they do when they are not in front of a computer? +Who and what are they? +When and where are they coding? +And what do they do when they are not in front of a computer? These and other questions will be unpacked during the simulation. Instead, let's trace some categories: _programmers_, _software_ and _use cases_. -These categories are a way to deal both with the software and hardware circumstances of code (Marino, 2020), but also their relations with _non-code entities_ (Mackenzie, 2006). A more-than-human and more-than-technical set of elements. +These categories are a way to deal both with the software and hardware circumstances of code (Marino, 2020), but also to give space to relations with _non-code entities_ (Mackenzie, 2006). A more-than-human and more-than-technical set of elements. - + In a grey zone where Actor Network Theory (Latour) and Object Oriented Onthology (Harman) overlap, we can think to every element in these categories as an actor, or an object. Hence we can afford, on one hand, to delegate the identity of an actor to its relations with others. Here every iteration and every update of the simulation is an event, an exchange between actants. On the other hand, the unknowable nature of the object leaves room for the simulation to dig deeper, to keep renegotiating the object' state exposing different qualities from time to time. @@ -138,13 +138,13 @@ _Software_ are objects made of code. Here we will refer to a particular subset o ``` Software -- lisp -- cobol - javascript - python - haskel -- assembly - redstone +- assembly +- cobol +- lisp ``` _Use cases_ are fields or objectives one could use code for. This could seem a bit loose, but in the scope of the simulation, it orientates actors in certain directions. Their effect is more like a magnetic force, than the call of destiny. This writing machine is not an hard coded teleological device, but rather a sandbox to generate narratives around software. @@ -193,7 +193,7 @@ Now we need to combine thigs from the three categories. - hacker, red stone, modding - engineer, red stone, research -## ITERATE +## Itearate **DISCLAIMER:** from here on basically just notes for the next steps of the simulation! @@ -272,14 +272,14 @@ Notes: --- -Now that the setup is done, the simulation can start. +Now that the setup is done, the process can start. Every iteration will pose a question to the elements To build something meaningful out of these initial combinations we can balance between what is defined and what is not. Leveraging on the unknown of the simulation gives room for narrations. -### Developer, cobol, work +### 01 00 @@ -295,27 +295,28 @@ Leveraging on the unknown of the simulation gives room for narrations. 02 +- Has never written a line in COBOL. +- Ready to accept the challenge in order to get closer to the mainframe. +- It sounds like the certification of being a real developer™️. + +
+ - Program readability was a commendable design goal, and ahead of its time. But how did it come about that the main emphasis was on readability by managers, instead of readability by programmers? - Was there any evidence at the time that managers wanted to read programs? - Did the COBOL committee seriously believe that the users could not handle grade school operators of `+`, `-` , `x`, `/`? - (Sannet, 1981) -- Has never written a line in COBOL. -- Ready to accept the challenge in order to get the opportunity to get closer to the mainframe. -- It sounds like the certification of being a real developer™️. +
-- The company's processing center is on the ninth floor of a large department store. -- An harshly lit room. -- Women —all Filippinas— it seems, are working heads down, at keypunch machine. -- Red flag: data entry with keypunch instead of computer system at a terminal? -- Data entry systems change, bad habits and exploitment don't. +- The company's processing center is on the ninth floor of a large department store. An harshly lit room. Women —all Filippinas— it seems, are working heads down, at keypunch machine. Data entry with keypunch instead of computer system at a terminal? +- Data entry systems change, bad habits and exploitation don't. - [Workers Leaving the Googleplex](http://www.andrewnormanwilson.com/WorkersGoogleplex.html), 2011 03 -- Haunted by the fear of getting caught as being stupid. Coming to a new system and not knowing how to log-on. Lie low and learn the basics. -- -- +- Haunted by the fear of getting caught as being stupid. +- Coming to a new system and not knowing how to log-on. +- Lie low and learn the basics. 04 @@ -362,7 +363,7 @@ the welcoming community thriving around the programming language? or the visual paradigm that facilitates the thinking about and connecting abstractions together? --> -## INSERT DOCUMENTATION AS ELEMENT +## Enter documentation Notes: @@ -374,7 +375,7 @@ Notes: --- -## WRAP UP +## Wrap up Notes: diff --git a/readme.md b/readme.md index e278ec0..deeb9ba 100644 --- a/readme.md +++ b/readme.md @@ -1,7 +1,49 @@ -# Write write write write write for the thesis +# Worlding and Software ![3D cover](cover.jpg) -But keep all the file in a single place, in order not to mess up. +- I want to write about worlding around software -TODO: rework the thesis outline for this doc +
+ +- How do you chose a particular programming language +- a coding style +- a development environment and ecosystem +- an infrastructure where to run the code +- and so on? +- These are **not just technical choices** +- but rather coding contingencies + +
+ +- These contingencies are situated in precise contexts +- economical +- cultural +- creative +- political +- technical +- Programming then is not just sharing code, but sharing context. +- It's providing a perspective to look at the world +- before attempting to get some grip onto it with a script. + +
+ +- How to provide a point of view through the lens of software? +- Who get to participate in this process of making meaning? +- How to create a discourse for the code to inhabit? +- How to stretch the affordances of code? +- besides +- technicality +- marketing +- advertisement + +## Enter documentation + +- Could software documentation +- _1_ be an ideal surface to build worlds +- _2_ be an interface between different knowledges +- _3_ be a device to trigger different kind of economy +- around situated software? + +- How can situated practices inform the process of documenting software? +-