script

contents/final.md

@@ -1,50 +1,132 @@
-# Ok time to wrap it up
+# Hello worlding
 
-In this presentation i will look at the work made across the 2 years to reflect on how it changed my understanding of code documentation.
+In this presentation i will look at the work made across the 2 years to reflect on how it changed my understanding of programming and code documentation.
 
 Code documentation here is intended as a broad set of practices: comments in code, readme files, tutorials, guides, references etc., but also moments of collective learning, workshops, pair programming and collaborative versioning.
 
 These aspects are usually marginal in software development: byproducts surrounding the real thing, extra work, and demand of resources often not available in the scarce economy around documentation.
 
-I would like to focus on these marginal zones, bring them to the center and reflect on how do they enrich practices of programming, opening entry points and backdoors into the making of software. 
+I would like to focus on these marginal zones, bring them to the center and reflect on how do they enrich practices of programming, opening entry points and backdoors into the making of software for people that are usually left out.
 
 The institutional required list of things done during these two years is left in the background, squint your eyes and move the cursor to the edges to see through. 
 
+## Getting startled
 
-## Brief thesis overview for context
+- coming to xpub with some previous experience in software development
+- a practice mainly used to develop interactive tools
+- visual art, performance and dance
+- but also corporate web design / development
 
-Excerpts from [Hello Worlding](https://hub.xpub.nl/soupboat/~kamo/thesis/) 
+<br>
 
+- coding embedding different values
+- coding as craftmanship, coding as service, coding to understand our surroundings
+- code as solution, coding as profession, code as product
 
-> I started this research for of two reasons. The first is that I love programming because is like learning another language: not just a new bag of words and a different grammar, but a whole new way of thinking, a lens through which to look at the world. Coding means __to express ideas with the reduced vocabulary of a programming language.__ As in poetry, these constraints stimulate creativity, and encourage a diligent yet playful approach. Working with different programming languages and on different systems __transforms thinking in multivarious ways, and that is extremely exciting__.
+<br>
 
-> The second reason is that I want to __share this excitement with others__, especially with my friends. __To be able to think and make sense together of what's happening around us, and come up with alternatives or responses or tools that suit us better.__ Because of the steep learning curve of programming and the other barriers previously mentioned, this has often not been possible. But now we know that there are other ways in, and that it is possible to open up even more.
+- enroll in XPUB, meet the group
+- different backgrounds different skills different values
+- different ways of working together
+- 1 important thing in common
+- (soup)
 
-___
+<br>
 
-> Code documentation is an ideal publishing surface to create worlds around software, and to orientate software in the world.
+- how to program together with different programming knowledge
 
-___
+<br>
 
-> The nature of code documentation is __to create entry points for people to participate in programming practices__. To encode and filter knowledge, and ultimately to share it with others. This "nature", however, does not come without issues. It makes a __lot of assumptions about who's reading__, expecting experts, or engineers, or dudes. Its __language is unwelcoming__: too dense, too technical, very gendered and unable to address anyone but the neurotypical-white-cis-male programmer. Documentation requires an __enormous amount of care, energy and time to be maintained,__ and it's done always out of budget, always as a side project, always at the end, and only if there's time left.
+- first months: 
+- incredible
+- new things: self-hosting, soupboat as shared space, the terminal, python
+- sharing knowledges a lot (see workshops)
+- the terror of modifying files in the soupboat and break everything
+- only timid and minimal modification in the homepage
+- lot of different prototypes with my classmates!
+- cute to look back and see the level where we started 
+- (see tech questions in soup-gen, cringe & funny & empowering)
 
-> Even if it does a questionable job at creating entry points, code documentation still has a lot of __potential as a backdoor__. It's a publishing surface whose reach extends through time and space. Time because **it meets programmers at different moments in their lives: from the _hello world_ till the _how to uninstall_**, and it influences thinking about software continuously, and from different perspectives. Space because it comes in __many different possible formats__, and can shapeshift to serve different occasions: from simple .txt files to entire websites, from coding workshops to comments in the source code to series of video tutorial. The question then becomes: __can we make use of these backdoors to infiltrate programming practices and open more entry points from within?__ 
+<br>
 
+- some prototypes found their way through the two years :) 
+- (see text weaving, from si16 to the screenless office workshop to jian final project)
+- some others no! but have been documented! so wont be forgotten
+- first things to take home: started documenting things
+- the famous documentation workout that was one of the objective to achieve in these two years :) 
 
+<br>
 
-## Code documentation as
+- but also traumatic!
+- suffered moments of severe stress after first two SIs
+- friction and contrast between:
+- care within the group, attention to group dynamics
+- group expectations and ambitions for projects
+- deadlines and production plans
 
+<br>
 
-__Code documentation as personal understanding of complicate concepts__
+- ended up centralizing a lot of technical work
+- always available and excited to share / offer skills to make things happen 
+- but not always taking into consideration the overall group engagement with programming
+
+<br>
+
+__realized after many year of collective practice that there's a difference in making something for a group and making something together.__
+
+
+<br>
+
+- the parable of SI18 was healing
+- and as healing works, it hurt a bit on the way
+- smaller groups, rotation between caretakers and contributors, pace uptempo
+- sometimes was difficult to give value to things made in such a rush
+- but on the course of the weekly releases something changed
+- at the beginning we were just giving themes or keywords as prompts
+- later on it transformed to offering formats and inviting particular workflows
+
+<br>
+
+## From code to code documentation
+
+- these ideas of __invitation, offering, proposal__ resonated a lot
+- especially with the concept of _situated software_
+- aka software made with and within a group, on a shared infra- and social- structure
+- coding as care
+
+<br>
+
+- at first wondered if the moment of offering and proposal could have been the format of the __demo__
+- _mother of all demos_ vibe
+- but as an approach felt too frontal and binary
+- developer vs user
+- and i didn't feel really connected with _demoscene_
+
+Eventually i focused on something closer to home: __the friction between being frustrated having to deal with undocumented piece of software, and at the same time never documenting anything.__
+
+And realized that what I'm interested on besides developing tools, is the moment of development itself. And a way to share that moment and its surroundings with others it's code documentation. 
+
+> Code documentation is an interface between the code, the user, the developer, and the world. Living close to the source code, but at the same time being less rigid and more expressive, it seems to be an ideal surface to influence software development practices.
+
+And that was more or less the moment when I started putting more efforts in writing readme files for my coding projects. But also 
+
+- Hosting workshops to share code
+- Organizing documentation sessions to dedicate time to writing docs
+- Printed zines, stickers and gadgets
+
+And learned how diverse and rich practices of code documentation can be: 
+
+__Code documentation as personal understanding__
 
 ![a drawing with a cute bird playing the role of an API between server and client](https://hub.xpub.nl/soupboat/wlist/img/chae_api.jpg)
-Chae's drawings
 
 ![a screenshot of a meme with a soaked sweated man trying not to use the analogy of the restaurant to explain the api](https://hub.xpub.nl/soupboat/~kamo/static/img/miri.jpg)
-Miri's meme  
 
 ![fancy graphic designed documentation to digest flask](https://hub.xpub.nl/soupboat/wlist/img/supi_flask.jpg)
-Supi's DIYry
+
+_Chae's drawing - Miri's meme - Supi's diyry_
+
+<br>
 
 __Code documentation as shared struggle__
 
@@ -54,85 +136,150 @@ __Code documentation as shared struggle__
 ![comment in code](https://hub.xpub.nl/soupboat/~kamo/static/img/comment_4.png)  
 ![comment in code](https://hub.xpub.nl/soupboat/~kamo/static/img/comment_5.png)
 
-Comments in the code screaming for help
+_Comments in the code screaming for help_
 
-
+<br>
-Sessions of pair programming to face technical stress
 
 __Code documentation as collective practice__
 
 ![Documentation for a repeat function with some nice parrot](https://hub.xpub.nl/soupboat/~kamo/thesis/img/SI16_NB.jpg)
+_Folder with Jupiter notebook files, each with a different piece of documentation for SI16_
 
-Folder with Jupiter notebook files, each with a different piece of documentation for SI16
 
 ![piece of flask documentation written with Chae](https://hub.xpub.nl/soupboat/~kamo/static/img/flask.png)  
+_Writing some documentation for Flask together with Chae_
+
+- Code documentation as facilitation to distributed authorship
+- Code documentation as poetic and political writing
+- Code documentation as invitation for others to participate
+- Code documentation as starting point for further explorations 
+- Code documentation as a way to question code
+
+
+
+
+## plans for final publication and grad show
+
+code documentation is a marginal practice, often invisible labor, usually left in the background. for grad show and final pubblication would like to bring it more to the center.
+
+There will be 2 kind of things at the exhibition
+
+### 1. helloworlding.com 
+
+Is a small website to archive a pathways through code documentation practice.
+at the current stage a pathway is an annotated collection of readmes. Readmes are presented with a short intro and link directly at the place where they originally can be found, that is in their repos. 
+
+It will be exhibited on a small screen connected to the Soupboat, for the occasion going on a field trip at the slash gallery.
+
+This archive is a <span class="double"><span>reading</span><span>writing</span></span> machine.
+
+- __reading__ because it's a curated restitution of different practices of code docs
+- __writing__ because it systematizes a research process, offering a surface where to keep track of methods through time, and see through snapshots how they transform over time
+
+Pathways available at the moment:
+
+1. welcoming language as a mode of address
+2. cover arts and visual entry points
+
+_The website will work as an invitation, with the possibility to sign in to receive update about new pathways, and activation._    
+
+### 2. readme readers
+
+Keyword are:
+__readme republishing__
+__readme readers__
+
+There will be printed snapshots of readme files mainly coming from tools developed in the context of the soupboat, bound together as _readme readers_ by means of a custom, loose binding setup.
+
+These readers will be a snapshot of the current pathways curated in [helloworlding.com](helloworlding.com)  
+
+To bring under spotlight a theme that is __a niche in a niche__ requires to create some entry points to be relatable. Code documentation is a surface in the middle of different kinds of audience, so different kind of entry points are necessary.
+These are aspects of code documentation practices I want to be reflected in the installation setup: 
+
+- __proximity to the code__: as a lens to look at it, as an entry point to let people in. as a bait to lure a tech audience not so used to this kind of discourses about sociality around software. 
+
+- __multiplicity__: many different situations, many different ways to document, not 1 size fits all
+
+- __worlding__: documentation can influence the way we think about code. can create worlds around it. system of values different from ultra optimization, productivity and tech solutionism 
+
+that's why for the exhibition im binding the readme readers with __clumsy 3d printed legs__. These legs started as a playful device to make our server run 4x faster, and eventually became one of visible marks of software developed around Soupboat
+
+As binding device they work as:
+
+- a small pack of goofy creatures in the ecosystem of soupboat
+- a playful display for a usually intimidating material 
+- embracing clumsyness, unfinished and provisional states, tryout and failures, commitment to constant gardening and care for code documentation, its readers and all the surroundings 
+
+
+picture picture
+picture picture
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
 
-Writing some documentation for Flask together with Chae
 
-__Code documentation as facilitation to distributed authorship__
 
-- post-it generator, git as cms
 
 
-__Code documentation as poetic and political writing__ 
 
-    - comments in the screenless office
-    - queer motto api readme
 
-__Code documentation as invitation for others to participate__
 
 
 
-__Code documentation as starting point for further explorations__ 
 
-(kiwiboat)
 
-__Code documentation as a way to question code__
 
 
 
 
-## the development of your reading/writing practice across the 2 years,
 
-reading
 
-1
-versioning: search & replace terms in essay to talk about something else
-API as worldbuilding (graphic design => api)
-murderous history of lootboxes (mimic => lootbox)
 
-2
-get to know that something like software studies exist! 
-and it's amazing because software is my passion tm
-birds press, active reading, reading as republishing
 
-writing
 
-dev a lot of small writing machines to write in different ways
-dlist wlist tag pathways soupboat/~kamo 
-readme files and comment in code
-thesis
 
-## the development of your prototyping practice across the 2 years,
 
-software development is my passion
-what i like is: developing tools for others to use
 
-explorations outside the computer:
-birds press and different printing and bookbinding techniques
-3d printing for soupboat and project
 
 
-## your final work and research in the second year,
 
-problematize code documentation practices
+that's why i decided
 
-organized some worshop and small social gatherings around code development
+by legs system
-printed some zines
+- to make them wander aroudn the exhibition space 
-printed some stickers
-writing a lot of readme in many different ways
 
 
-## plans for final publication and grad show (with the understanding that you will continue to work on this after the assessment)
 
 

contents/final_old.md

@@ -0,0 +1,138 @@
+# Ok time to wrap it up
+
+In this presentation i will look at the work made across the 2 years to reflect on how it changed my understanding of code documentation.
+
+Code documentation here is intended as a broad set of practices: comments in code, readme files, tutorials, guides, references etc., but also moments of collective learning, workshops, pair programming and collaborative versioning. 
+
+These aspects are usually marginal in software development: byproducts surrounding the real thing, extra work, and demand of resources often not available in the scarce economy around documentation.  
+
+I would like to focus on these marginal zones, bring them to the center and reflect on how do they enrich practices of programming, opening entry points and backdoors into the making of software. 
+
+The institutional required list of things done during these two years is left in the background, squint your eyes and move the cursor to the edges to see through. 
+
+
+## Brief thesis overview for context
+    
+Excerpts from [Hello Worlding](https://hub.xpub.nl/soupboat/~kamo/thesis/) 
+
+
+> I started this research for of two reasons. The first is that I love programming because is like learning another language: not just a new bag of words and a different grammar, but a whole new way of thinking, a lens through which to look at the world. Coding means __to express ideas with the reduced vocabulary of a programming language.__ As in poetry, these constraints stimulate creativity, and encourage a diligent yet playful approach. Working with different programming languages and on different systems __transforms thinking in multivarious ways, and that is extremely exciting__.
+
+> The second reason is that I want to __share this excitement with others__, especially with my friends. __To be able to think and make sense together of what's happening around us, and come up with alternatives or responses or tools that suit us better.__ Because of the steep learning curve of programming and the other barriers previously mentioned, this has often not been possible. But now we know that there are other ways in, and that it is possible to open up even more.
+
+___
+
+> Code documentation is an ideal publishing surface to create worlds around software, and to orientate software in the world.
+
+___
+
+> The nature of code documentation is __to create entry points for people to participate in programming practices__. To encode and filter knowledge, and ultimately to share it with others. This "nature", however, does not come without issues. It makes a __lot of assumptions about who's reading__, expecting experts, or engineers, or dudes. Its __language is unwelcoming__: too dense, too technical, very gendered and unable to address anyone but the neurotypical-white-cis-male programmer. Documentation requires an __enormous amount of care, energy and time to be maintained,__ and it's done always out of budget, always as a side project, always at the end, and only if there's time left.
+
+> Even if it does a questionable job at creating entry points, code documentation still has a lot of __potential as a backdoor__. It's a publishing surface whose reach extends through time and space. Time because **it meets programmers at different moments in their lives: from the _hello world_ till the _how to uninstall_**, and it influences thinking about software continuously, and from different perspectives. Space because it comes in __many different possible formats__, and can shapeshift to serve different occasions: from simple .txt files to entire websites, from coding workshops to comments in the source code to series of video tutorial. The question then becomes: __can we make use of these backdoors to infiltrate programming practices and open more entry points from within?__ 
+
+
+
+## Code documentation as
+
+
+__Code documentation as personal understanding of complicate concepts__
+
+![a drawing with a cute bird playing the role of an API between server and client](https://hub.xpub.nl/soupboat/wlist/img/chae_api.jpg)  
+Chae's drawings
+
+![a screenshot of a meme with a soaked sweated man trying not to use the analogy of the restaurant to explain the api](https://hub.xpub.nl/soupboat/~kamo/static/img/miri.jpg)  
+Miri's meme  
+
+![fancy graphic designed documentation to digest flask](https://hub.xpub.nl/soupboat/wlist/img/supi_flask.jpg)  
+Supi's DIYry
+
+__Code documentation as shared struggle__ 
+
+![comment in code: ](https://hub.xpub.nl/soupboat/~kamo/static/img/comment_1.png)  
+![comment in code](https://hub.xpub.nl/soupboat/~kamo/static/img/comment_2.png)  
+![comment in code](https://hub.xpub.nl/soupboat/~kamo/static/img/comment_3.png)  
+![comment in code](https://hub.xpub.nl/soupboat/~kamo/static/img/comment_4.png)  
+![comment in code](https://hub.xpub.nl/soupboat/~kamo/static/img/comment_5.png)
+
+Comments in the code screaming for help
+
+
+Sessions of pair programming to face technical stress
+         
+__Code documentation as collective practice__
+
+![Documentation for a repeat function with some nice parrot](https://hub.xpub.nl/soupboat/~kamo/thesis/img/SI16_NB.jpg)
+
+Folder with Jupiter notebook files, each with a different piece of documentation for SI16
+
+![piece of flask documentation written with Chae](https://hub.xpub.nl/soupboat/~kamo/static/img/flask.png)
+
+Writing some documentation for Flask together with Chae
+
+__Code documentation as facilitation to distributed authorship__
+
+- post-it generator, git as cms
+
+
+__Code documentation as poetic and political writing__ 
+    
+    - comments in the screenless office
+    - queer motto api readme
+
+__Code documentation as invitation for others to participate__
+
+
+
+__Code documentation as starting point for further explorations__ 
+
+(kiwiboat)
+
+__Code documentation as a way to question code__
+
+
+
+
+## the development of your reading/writing practice across the 2 years,
+
+reading
+
+1
+versioning: search & replace terms in essay to talk about something else
+API as worldbuilding (graphic design => api)
+murderous history of lootboxes (mimic => lootbox)
+
+2
+get to know that something like software studies exist! 
+and it's amazing because software is my passion tm
+birds press, active reading, reading as republishing
+
+writing
+
+dev a lot of small writing machines to write in different ways
+dlist wlist tag pathways soupboat/~kamo 
+readme files and comment in code
+thesis
+
+## the development of your prototyping practice across the 2 years,
+
+software development is my passion
+what i like is: developing tools for others to use
+
+explorations outside the computer:
+birds press and different printing and bookbinding techniques
+3d printing for soupboat and project
+
+
+## your final work and research in the second year,
+
+problematize code documentation practices
+
+organized some worshop and small social gatherings around code development
+printed some zines
+printed some stickers
+writing a lot of readme in many different ways
+
+
+## plans for final publication and grad show (with the understanding that you will continue to work on this after the assessment)
+
+