01 cleanup and last paragraph wip

carpet/provisional_text_dump.md

@@ -0,0 +1,17 @@
+# 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)

chapters/01_who_is_reading.md

@@ -79,7 +79,9 @@ Far from being just an isolated problem, this crudity is deeply embedded in the
 
 Ellen Ullman accounts on the emotional dumbness of her _real programmers_ colleagues give an insight of a problematic behavior, first intercepted and then capitalized by the IT industry. _"In meetings, they behave like children. They tell each other to shut up. The call each other idiots. They throw balled-up paper. One day, a team member screams at his Korean colleague, 'Speak English!' (A moment of silence follow this outburst, at least.)"_ (Ullman, 1997; 2017)
 
-Programming means to deal with picky stubborn machines that don't overlook a single typo. It requires a high tolerance for failure. It is frustrating. But to project this frustration onto other users, as in the Read The Fucking Manual typical response to a request for help, it's a kind of negative solidarity (Fisher, 2013) that poses serious barriers to participation in the making of software.        
+Programming means to deal with picky stubborn machines that don't overlook a single typo. It requires a high tolerance for failure. It is frustrating. But to project this frustration onto other users, as in the `Read The Fucking Manual` response to a request for help, it's a kind of negative solidarity (Fisher, 2013) that poses serious barriers to participation in the making of software.        
+
+`vvvv & evvvvil documentation ? is an example of really really bad documentation. dunno tho if want to give space to that guy`
 
 Instead... 
 
@@ -95,22 +97,13 @@ Instead...
     -   programming for the millions (ullman, 2016)
     -   read the feminist manual (karagianni, 2021 )
 
----
+- manuals often address just male developers
-
+- often documentation doesn't offer entry points for beginners, or a sense of direction
-# Provisional txt dump
+- bro culture ? ? ? (could be the transition from previous section) (could be the example with evvvvil help patches)
-
+- refer to a specific cultural niche ? see ullman, even tho need to counter balance with other examples
-## 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)