It’s been a long silence for me on this homepage. Stuff has been happening, but somehow I didn’t find the time to write much.

I’m trying out a new thing. I have a lot of stuff I want to learn some day, but I don’t have the time to learn all of it (and often I also don’t have the leftover energy to do personal-development type stuff, but that is another problem). I’ve had a bunch of systems to remember the interesting things I want to learn - a file on my disk, then a more complex file on my disk, then my laptop crashed, then Google Keep.

So the new thing I’m trying is that I’m adding a new page here called Things to learn. When I find a new thing I want to deeply understand some day, I write it into the list. And when I (some day) feel like diving into a thing, I will pick one up from the list, spend a bunch of time learning it, and then I’ll write a thing, put it on my website and link it from there.

Why this might be good:

• I won’t hopefully end up forgetting and then relearning the same stuff.
• Writing something down makes it easier to spot confusion or weak spots in understanding. (Maybe it’s because I spend a lot of time reviewing code. Seeing something written in monospace font makes me go like “huh I’m not sure please write a test”.)
• I will produce stuff :)

Let’s see how it goes.

Documented systems

Oh by the way, there is a more general thing I’ve been trying which I think might be useful for me.

So CFAR teaches this thing they call “systematization”. (CFAR - Putting Names on Things ™) Examples are:

• Having your underwear in the top shelf, then the socks, then shorts, etc., and keeping it that way.
• A checklist you follow when you need to pack up for a flight.
• Putting all your appointments and other fixed commitments into Google Calendar.

Systems are useful, because they standardize things. Preparing a flight checklist once and then following it 10 times is easier than figuring out if there’s anything important you’re forgetting 10 times at different occassions.

I have a few systems. They have come to be mostly “on their own”, and I might not remember the reason they turned out the way they are.

I want to try making my systems explicit - by writing down a documentation for what each system looks like, what problems does it solve, and such. I want that because:

• It makes sure the system actually is there for something. This prevents a failure mode I’ve been in after my CFAR workshop, which I once called “cargo cult rationality”. It’s running around beating at random things with CFAR techniques, trying to be a great and conscientious rationalist. (I guess “cargo cult rationality” is also a thing worth writing about some day…)
• It stores the system out of my mind. For example, I have a system for which things to have in my backpack and where. It tends to deteriorate, and when the chaos threatens to overwhelm my backpack, I can just refer to the explicit description of what goes where, and maybe update it if needed. I don’t have to solve the problem of “figure out the optimal things to put into my backpack and where to put them” every time it gets too messy.
• It enables debugging.

The way I think of it right now is to have a “source code for my systems”, sort of. Right now I have a like 5-page Google doc with a mix of where things go in my apartment, how to pack for things, and where things go in my backpack, and the motivation and open problems for each.