|
|
|
|
|
|
by gavinhoward
944 days ago
|
|
|
I appreciate the author explaining this. I have had a Theory of what software is myself, mostly based on "Programming as Theory Building," but it is good to see it put into words. I struggle to build "theory of mind," which means I can't read code written by other people. This means I can't get or keep a software job, so it sucks. At the same time, it is a superpower in personal projects because I can somehow document my own theory of mind. It's counterintuitive, but my inability to build a theory of mind about other people causes me to assume less about what they know, which translates into good Theory docs. My best example is [1]. [1]: https://git.gavinhoward.com/gavin/bc/src/commit/22253a3a64db... |
|
|
The thing is imo, you have a theory of mind on which you build. This building is done in a very structured way and works well for you. I believe the gist is, you have premises, eg. values of a code base, and build further on that, layer by layer.
The OP explains a pain point with sofware engineering, which also applies here: a theory cannot be fully expressed. The code and documentation flows out of the theory, they are artefacts, products of it. Still those are not encompassing the theory in itself, which in fact only exists in the originator's mind.
The job of many sw engineers is to get insights into such theories by inspecting the code and documentation, using it and approaching these from different angles. A bit like archeology.