You cannot select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
139 lines
6.9 KiB
Markdown
139 lines
6.9 KiB
Markdown
# 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__
|
|
|
|
|
|
Chae's drawings
|
|
|
|
|
|
Miri's meme
|
|
|
|
|
|
Supi's DIYry
|
|
|
|
__Code documentation as shared struggle__
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Comments in the code screaming for help
|
|
|
|
|
|
Sessions of pair programming to face technical stress
|
|
|
|
__Code documentation as collective practice__
|
|
|
|
|
|
|
|
Folder with Jupiter notebook files, each with a different piece of documentation for SI16
|
|
|
|
|
|
|
|
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)
|
|
|
|
|