I saw an ad for a new kind of pant: stylish as suit pants, but flexible as sweatpants. I didn’t have time to order them now. But I saved the link in a new tab in my clothes database—an Airtable that tracks all the clothes I own.
This crystallised some thoughts about external systems that have been brewing at the back of my mind. In particular, about the gears-level principles that make some of them useful, and powerful,
When I say “external”, I am pointing to things like spreadsheets, apps, databases, organisations, notebooks, institutions, room layouts… and distinguishing those from minds, thoughts and habits. (Though this distinction isn’t exact, as will be clear below, and some of these ideas are at an early stage.)
Externalising systems allows the following benefits...
1. Gathering answers to unsearchable queries
There are often things I want lists of, which are very hard to Google or research. For example:
List of groundbreaking discoveries that seem trivial in hindsight
List of different kinds of confusion, identified by their phenomenological qualia
List of good-faith arguments which are elaborate and rigorous, though uncertain, and which turned out to be wrong
etc.
Currently there is no search engine (but the human mind) capable of finding many of these answers (if I am expecting a certain level of quality). But for that reason researching the lists is also very hard.
The only way I can build these lists is by accumulating those nuggets of insight over time.
And the way I make that happen, is to make sure to have external systems which are ready to capture those insights as they appear.
2. Seizing serendipity
Luck favours the prepared mind.
Consider the following anecdote:
Richard Feynman was fond of giving the following advice on how to be a genius. [As an example, he said that] you have to keep a dozen of your favorite problems constantly present in your mind, although by and large they will lay in a dormant state. Every time you hear or read a new trick or a new result, test it against each of your twelve problems to see whether it helps. Every once in a while there will be a hit, and people will say: “How did he do it? He must be a genius!”
I think this is true far beyond beyond intellectual discovery. In order for the most valuable companies to exist, there must be VCs ready to fund those companies when their founders are toying with the ideas. In order for the best jokes to exist, there must be audiences ready to hear them.
3. Collision of producers and consumers
Wikipedia has a page on “Bayes theorem”.
But it doesn’t have a page on things like “The particular confusion that many people feel when trying to apply conservation of expected evidence to scenario X”.
Why?
One answer is that more detailed pages aren’t as useful. But I think that can’t be the entire truth. Some of the greatest insights in science take a lot of sentences to explain (or, even if they have catchy conclusions, they depend on sub-steps which are hard to explain).
Rather, the survival of Wikipedia pages depends on both those who want to edit and those who want to read the page being able to find it. It depends on collisions, the emergence of natural Schelling points for accumulating content on a topic. And that’s probably something like exponentially harder to accomplish the longer your thing takes to describe and search for.
Collisions don’t just have to occur between different contributors. They must also occur across time.
For example, sometimes when I’ve had 3 different task management systems going, I end up just using a document at the end of the day. Because I can’t trust that if I leave a task in any one of the systems, future Jacob will return to that same system to find it.
4. Allowing collaboration
External systems allow multiple people to contribute. This usually requires some formalism (a database, mathematical notation, lexicons, …), and some sacrifice of flexibility (which grows superlinearly as the number of contributors grow).
5. Defining systems extensionally rather than intensionally
These are terms from analytic philosophy. Roughly, the “intension” of the concept “dog” is a furry, four-legged mammal which evolved to be friendly and cooperative with a human owner. The “extension” of “dog” is simply the set of all dogs: {Goofy, Sunny, Bo, Beast, Clifford, …}
If you’re defining a concept extensionally, you can simply point to examples as soon as you have some fleeting intuitive sense of what you’re after, but long before you can articulate explicit necessary and sufficient conditions for the concept.
Similarly, an externalised system can grow organically, before anyone knows what it is going to become.
6. Learning from mistakes
I have a packing list database, that I use when I travel. I input some parameters about how long I’ll be gone and how warm the location is, and it’ll output a checklist for everything I need to bring.
It’s got at least 30 items per trip.
One unexpected benefit from this, is that whenever I forget something—sunglasses, plug converters, snacks—I have a way to ensure I never make that mistake again. I simply add it to my database, and as long as future Jacob uses the database, he’ll avoid repeating my error.
This is similar to Ray Dalio’s Principles. I recall him suggesting that the act of writing down and reifying his guiding wisdom gave him a way to seize mistakes and turn them into a stronger future self.
This is also true for the Github repo of the current project I’m working on. Whenever I visit our site and find a bug, I have a habit of immediately filing an issue, for it to be solved later. There is a pipeline whereby these real-world nuggets of user experience—hard-worn lessons from interacting with the app “in-the-field”, that you couldn’t practically have predicted from first principles—get converted into a better app. So, whenever a new bug is picked up by me or a user, in addition to annoyance, it causes a little flinch of excitement (though the same might not be true for our main developer...). This also relates to the fact that we’re dealing in code. Any mistake can be improved in such a way that no future user will experience it.
I saw an ad for a new kind of pant: stylish as suit pants, but flexible as sweatpants. I didn’t have time to order them now. But I saved the link in a new tab in my clothes database—an Airtable that tracks all the clothes I own.
This crystallised some thoughts about external systems that have been brewing at the back of my mind. In particular, about the gears-level principles that make some of them useful, and powerful,
When I say “external”, I am pointing to things like spreadsheets, apps, databases, organisations, notebooks, institutions, room layouts… and distinguishing those from minds, thoughts and habits. (Though this distinction isn’t exact, as will be clear below, and some of these ideas are at an early stage.)
Externalising systems allows the following benefits...
1. Gathering answers to unsearchable queries
There are often things I want lists of, which are very hard to Google or research. For example:
List of groundbreaking discoveries that seem trivial in hindsight
List of different kinds of confusion, identified by their phenomenological qualia
List of good-faith arguments which are elaborate and rigorous, though uncertain, and which turned out to be wrong
etc.
Currently there is no search engine (but the human mind) capable of finding many of these answers (if I am expecting a certain level of quality). But for that reason researching the lists is also very hard.
The only way I can build these lists is by accumulating those nuggets of insight over time.
And the way I make that happen, is to make sure to have external systems which are ready to capture those insights as they appear.
2. Seizing serendipity
Luck favours the prepared mind.
Consider the following anecdote:
I think this is true far beyond beyond intellectual discovery. In order for the most valuable companies to exist, there must be VCs ready to fund those companies when their founders are toying with the ideas. In order for the best jokes to exist, there must be audiences ready to hear them.
3. Collision of producers and consumers
Wikipedia has a page on “Bayes theorem”.
But it doesn’t have a page on things like “The particular confusion that many people feel when trying to apply conservation of expected evidence to scenario X”.
Why?
One answer is that more detailed pages aren’t as useful. But I think that can’t be the entire truth. Some of the greatest insights in science take a lot of sentences to explain (or, even if they have catchy conclusions, they depend on sub-steps which are hard to explain).
Rather, the survival of Wikipedia pages depends on both those who want to edit and those who want to read the page being able to find it. It depends on collisions, the emergence of natural Schelling points for accumulating content on a topic. And that’s probably something like exponentially harder to accomplish the longer your thing takes to describe and search for.
Collisions don’t just have to occur between different contributors. They must also occur across time.
For example, sometimes when I’ve had 3 different task management systems going, I end up just using a document at the end of the day. Because I can’t trust that if I leave a task in any one of the systems, future Jacob will return to that same system to find it.
4. Allowing collaboration
External systems allow multiple people to contribute. This usually requires some formalism (a database, mathematical notation, lexicons, …), and some sacrifice of flexibility (which grows superlinearly as the number of contributors grow).
5. Defining systems extensionally rather than intensionally
These are terms from analytic philosophy. Roughly, the “intension” of the concept “dog” is a furry, four-legged mammal which evolved to be friendly and cooperative with a human owner. The “extension” of “dog” is simply the set of all dogs: {Goofy, Sunny, Bo, Beast, Clifford, …}
If you’re defining a concept extensionally, you can simply point to examples as soon as you have some fleeting intuitive sense of what you’re after, but long before you can articulate explicit necessary and sufficient conditions for the concept.
Similarly, an externalised system can grow organically, before anyone knows what it is going to become.
6. Learning from mistakes
I have a packing list database, that I use when I travel. I input some parameters about how long I’ll be gone and how warm the location is, and it’ll output a checklist for everything I need to bring.
It’s got at least 30 items per trip.
One unexpected benefit from this, is that whenever I forget something—sunglasses, plug converters, snacks—I have a way to ensure I never make that mistake again. I simply add it to my database, and as long as future Jacob uses the database, he’ll avoid repeating my error.
This is similar to Ray Dalio’s Principles. I recall him suggesting that the act of writing down and reifying his guiding wisdom gave him a way to seize mistakes and turn them into a stronger future self.
This is also true for the Github repo of the current project I’m working on. Whenever I visit our site and find a bug, I have a habit of immediately filing an issue, for it to be solved later. There is a pipeline whereby these real-world nuggets of user experience—hard-worn lessons from interacting with the app “in-the-field”, that you couldn’t practically have predicted from first principles—get converted into a better app. So, whenever a new bug is picked up by me or a user, in addition to annoyance, it causes a little flinch of excitement (though the same might not be true for our main developer...). This also relates to the fact that we’re dealing in code. Any mistake can be improved in such a way that no future user will experience it.