Rules of programming experiments

Rules of programming experiments:

• it doesn’t have to be good
• it doesn’t have to work
• you have to learn something

I wrote this in a talk slide once:

and I wanted to say a tiny bit more about it. I think one other thing that defines “programming experiments” for me is – often the experiment doesn’t take that much time (maybe 4 hours on a Wednesday evening), and when I’m done I don’t have to maintain it or anything. This makes it a lot more tractable for me than stuff like “work on actual real open source projects” which I have exactly 0 energy for after programming at work.

I also spent 12 weeks doing programming experiments full time at the recurse center and it was awesome. These days I have substantially less time to devote to them :)

A few examples of things that have fallen into this category for me:

• Spending some time on a train running strace on “killall”
• writing an operating system in rust (this took 3 weeks which is a pretty long time, but fell very far short of “operating system”, and I learned a ton. huge success.)
• investigating Hadoop by stracing some code that interacts with HDFS (diving into HDFS)
• how does SQLite work?
• learning about LD_PRELOAD

and, well, a bunch more on this blog. I think it’s an interesting reason to write programs because the program itself is totally incidental (I usually put them on the internet, but certainly not for anyone to use or anything). It’s more about

• does this work?
• what happens if I do this?
• can I write a small program that helps me look at IMPORTANT_NEW_CONCEPT? (like threading?)