kamo
/
thesis
1
2
Fork 0
Code Issues Pull Requests Releases Wiki Activity
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.
main
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from '834886b040'
${ noResults }
thesis/readme.md

7.5 KiB
Raw Blame History

TODO: a file where to keep references

Worlding and Software

3D cover

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 economical, cultural, creative, political, and technical contexts. 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 offer 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, and advertisement?

Enter documentation

Could software documentation:

  1. be a mean to explore these contingencies?
  2. be an ideal surface to build worlds?
  3. be an interface between different knowledges?
  4. be a device to trigger different kinds of economy around situated software?

How can situated practices inform the process of documenting software? And how can situated software inform the process of technical writing?

Table of Contents (draft)

exploratory documentation aspects + 2 frogmouth birds

  1. Coding Contingencies (2000)
    Situate software as cultural object and propose documentation as a surface to explore it.

    1. Context around software, besides technicality (500)

    2. Introduce issues around software (1000)

      1. Biased and hostile environments
        • Toxic masculinity, encoded chauvinism, western monoculture
      2. Evergrowing complexity
        • Intimidating learning curve, disproportion of means, mistification
      3. The universal solution™
        • Techno solutionism, gray tech, ideology

    3. Propose documentation as a surface to address these issues (500)

      1. Welcoming diverse knowledges
      2. Lowering barriers and create entry points
      3. Orientate software in the world

  2. Documentation as an interface (3000)
    Aknowledge documentation as crossroad for different actors, as intersection between code, machines, developers, users. Articulate it as a vantage point from where to reason about software.

    1. Define software documentation

      1. From printed manuals to discord servers (small historical overview)
      2. Dyataxis framework: Reference, How-to, Guide, Tutorial.

    2. Welcoming diverse knowledges

      • Who is writing?

      • Documentation as subaltern work?

      • Documentation as a form of care

      • Who will read?

      • Read the feminist manual (Karayanni, 2021)

      • Programming for the millions (Ullman, 2016)

    3. Lowering barriers and create entry points

      • Who is addressed?

      • welcome.js (Bridle, 2016)

      • Debugging (P5js Education Working Group, 2015)

      • Who can access?

      • Wheatering software winter (100R, 2022)

    4. Orientate software in the world

      • Who is making the software?

      • Post-meritocracy manifesto (Ehmke, 2018)

      • How are we making it?

      • Patterns of Software (Gabriel, 1996)

      • Situated Software (Shirky, 2004)

      • Aesthetic Programming (Geoff & Soon, 2022)

      • Ways of Being (Bridle, 2022)

  3. Situated software requires situated documentation (3000)

    • Documenting situated practices as an ongoing process. A recipe in the making.
      • Techno-solutionism reversed: are we the solution to our tools' problems?
      • A praise for partial solutions
    • Situated software lifecycle. Inner public, outer public.
      • Inner public is the target audience of a situated software. The community where it has been developed. Private public.
      • Outer public is others: different communities that approach to it later on or for different purposes. Public public.
      • What role plays documentation in these two moments?
    • Code as common. Documentation as loose interface between different needs.
      • Situated documentation is tailored on specific needs, and produced from specific perspectives. How can it resonate with different ones?