__Code documentation as a broad set of practices__: comments in code, readme files, tutorials, guides, references, 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 they can 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.
Eventually 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 with others it's code documentation. Creating entry points and opening backdoors to the making of software.
> __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.
That was more or less the moment when I started being more aware about my and others approach to documentation. And learned how diverse and rich practices of code documentation can be:
![scanned materials for the documentation sessions. some sticker, flyers and text, printed on pink paper](https://hub.xpub.nl/soupboat/~kamo/projects/dyc/gadget.jpg)
_Materials printed for documentation session_
![Scan of the zine Care for Code](https://hub.xpub.nl/soupboat/~kamo/static/img/care_for_code.png)
![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)
![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)
![fancy graphic designed documentation to digest flask](https://hub.xpub.nl/soupboat/wlist/img/supi_flask.jpg)
__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.
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 <spanclass="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
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)
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
To bring under spotlight a theme that is __a niche in a niche__ requires to create some relatable entry points. Code documentation is a surface in the middle of different kinds of audience, so different kind of entry points are necessary.
![soupboat with legs](https://hub.xpub.nl/soupboat/~kamo/thesis/img/soupboat.jpg)
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.
- 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
[helloworlding.com]() will work as a hub to continue the research and practice around code docs, like the archive in the soupboat has done these two years.