introduction maybe ok

main
km0 2 years ago
parent 8af79b1888
commit f6893c19d7

@ -1,6 +1,5 @@
## 0. Intro ## 0. Intro
There are two flows around code documentation: There are two flows around code documentation:
![A square in center. A roster enter from the front with a plain arrow. A barn owl enter from the back, with a dashed arrow. ](../img/backdoor.jpg "Two flows around code documentation: entry points and backdoors.") ![A square in center. A roster enter from the front with a plain arrow. A barn owl enter from the back, with a dashed arrow. ](../img/backdoor.jpg "Two flows around code documentation: entry points and backdoors.")
@ -13,12 +12,12 @@ Documentation as a backdoor where to inject context into software: to host princ
This research explores these two currents, with the thesis that code documentation is an ideal publishing surface to create worlds around software, and to orientate software in the world. This research explores these two currents, with the thesis that 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 on who's reading, expecting experts, or engineers, or dudes. Its language is often unwelcoming: too dense, too technical, very gendered and unable to address anyone apart the neurotypical-white-cis-male programmer. Documentation requires an huuge amount of care, energy and time to be maintained, and it's done always out of budget, always as side project, always at the end, and only if there's time left. These points will be addressed in the first chapter. 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 on who's reading, expecting experts, or engineers, or dudes. Its language is unwelcoming: too dense, too technical, very gendered and unable to address anyone apart the neurotypical-white-cis-male programmer. Documentation requires an huuge amount of care, energy and time to be maintained, and it's done always out of budget, always as side project, always at the end, and only if there's time left. The first chapter will raise these points to remark how often code documentation acts as a barrier, gatekeeping access to the making of software.
Even doing a questionable job at creating entry points, code documentation still has a lot of potential as a backdoor. It's a publishing surface which reach stretches through time and space. Time because it meets programmers in different moments of their life: from the _hello world_ till the _how to uninstall_, and it affects thinking about software continuously, and from different perspectives. Space because it comes with many different possible formats, and can shapeshift to serve diverse occasions: from simple `.txt` files to entire websites, from coding workshops to comments in the source code to series of video tutorial. Even doing a questionable job at creating entry points, code documentation still has a lot of potential as a backdoor. It's a publishing surface which reach stretches through time and space. Time because it meets programmers in different moments of their life: from the _hello world_ till the _how to uninstall_, and it affects thinking about software continuously, and from different perspectives. Space because it comes with many different possible formats, and can shapeshift to serve diverse 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 is: can we make use of these backdoors to infiltrate programming practice and open more entry points from the inside? The question then is: can we make use of these backdoors to infiltrate programming practices and open more entry points from the inside?
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 practices of software development. The second chapter brings some examples to articulate how documentation can be used to orientate code in the world, addressing politics of participation, representation, and authorship in programming. The case studies comes from diverse realities, and from different scales: big collaborative projects as well as small, personal gestures. With their molteplicity, they show how blurred the boundaries of code documentation are. A lack of fixedness that can be used in turn to mold our wishes and values into it. 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 practices of software development. The second chapter will bring some examples to articulate how documentation can be used to orientate code in the world, addressing politics of participation, representation, and authorship in programming. The case studies comes from diverse realities, and from different scales: big collaborative projects as well as small, personal gestures. With their molteplicity, they show how blurred the boundaries of code documentation are. A lack of fixedness that can be used in turn to mold our wishes and values into it.
A term to contextualize (and dismantle?) in these writings is _developer_. By stripping down every trace of professionalism and formal education, let's agree that a developer is someone who tinkers with code. No matter at which level, nor distance, nor experience. No matter if for work, for fun, for study. No matter if one is actively involved in the development of a tool, or comes from the user perspective. Ellen Ullman writes that programming is a disease, but the situation is even worse: code is contagious material, touch it once, and you are a developer. A term to contextualize (and dismantle?) in these writings is _developer_. By stripping down every trace of professionalism and formal education, let's agree that a developer is someone who tinkers with code. No matter at which level, nor distance, nor experience. No matter if for work, for fun, for study. No matter if one is actively involved in the development of a tool, or comes from the user perspective. Ellen Ullman writes that programming is a disease, but the situation is even worse: code is contagious material, touch it once, and you are a developer.

Loading…
Cancel
Save