@ -86,6 +86,22 @@ BTW at the moment it's just a list of things that come to mind while playing bas
### Tool grip
Tool as a way to access reality, to gain grip to the world.
Tool as a way to access reality, to gain grip onto the world.
There is something different in how do we create tool for ourselves, and how do we create tool for others.
There is something different in how we do create tool for ourselves, and how we do create tool for others.
See [GRS](../grs) for an intro about this.
### Coding contingencies
> Code is always addressed to someone. [...] We do not write code for our computers, but rather we write it for humans to read and use. [Jesse Li (2020)](https://blog.jse.li/posts/software/)
Coding is not just production of software, but also production of knowledge. A dialogue between human and more-than-human actors. The guestlist of this conference of the bits is often compiled by chance: the choice of a particular programming language, the coding style, the development environment and ecosystem, the infrastructure that runs the code, and so on, are the result of specific contingencies.
These contingencies are situated in precise contexts, and these contexts are different one from another. Programming is not just sharing code, but sharing context. It's to provide a point of view and a perspective to look at the world, before attempting to get some grip onto it with a script. That's the reason why even if source code, even when obscure and obfuscated, speaks for itself, it cannot always cast light around its surroundings. To make place for the code turns to be a necessary act of care in the process of sharing knowledge.
<!-- next paragraph has potential but like this is a no -->
Code ages fast. Because it moves at lightspeed into fiber optic cables, its tempo flows at a total different pace compared to the velocity of our cultural daily life.
@ -86,7 +86,10 @@ During the course of 3 weeks develop and execute hands-on:
- embrace loss, confusion, dilettance, and serendipity.
```
Ideas for the Hackpact:
## 1 Hackpact:
- README.md-fy old repo on git:
There are 60 repos in my xpub git, most of them without a clear entry point for others. One idea could be to write a daily [README](https://en.wikipedia.org/wiki/README) file in order to make the projects more accessible. [Make a README](https://www.makeareadme.com/) is a good starting point. Experiment with writing style and approach.
### README.md-fy old repo on git:
There are 60 repository in my xpub git, most of them without a clear entry point for others. One idea could be to write a daily [README](https://en.wikipedia.org/wiki/README) file in order to make the projects more accessible. [Make a README](https://www.makeareadme.com/) is a good starting point. Experiment with writing style and approach. Try to understand what is relevant besides technicalities. Could it offer not just a practical kickstart but also a critical perspective on the tool?
What does it mean though to return to old projects? Ewww.
