Blogging as I learn

Many of my technical blog posts report on a finished state. I usually talk about how I completed a goal or solved a problem to varying degrees of depth. Some posts are "how to" guides; other posts are retrospectives. Writing posts when you have finished a project is exciting. You can share how you made something. I love reading such posts written by others, and I enjoy writing them.

With that said, finished projects are only part of the learning process. For longer projects, there may be value in documenting as you go, rather than waiting for your end state.

Over the winter holidays, I decided to try my hand at blogging as I learn. I started working on a challenge to compress 1 GB of Wikipedia (the enwik9 dataset) as much as possible. Before working on the challenge, I knew very little about compression. I spent hours over multiple days coding towards different solutions, during which time I learned a lot. Most of what I learned was not novel to the world -- i.e. I learned that dictionary coding is effective, something that was theorized decades ago! -- but it was novel to me. I was learning.

I wrote down what I did as I strived toward compressing the Wikipedia dataset. I wrote about directions that worked, like dictionary coding, and ideas I tried that did not work out, like square rooting tokenized numbers. I would usually not write about what didn't work, but doing so for this project was both personally helpful and may be helpful to others, too. As I wrote, I came up with some new ideas. I noticed areas where I made mistakes in my calculations. I made new mental connections about the problem I was trying to solve.

Documenting what you learn not to do is just as valuable as writing about what works. Say you are writing about web caching. If you learned that a certain combination of headers does not achieve your goal, that is knowledge you could document, either for yourself in private (so you can remember later!) or in public (so others can learn, too!). I use this particular example because I wrote a blog post yesterday on web caching because I needed to get my thoughts on paper.

Friends suggested several solutions to a problem. It felt helpful to write down the what, why, and how I solved a problem, alongside other options I considered. I haven't learned all I want to learn about caching, but it is a start.

Someone may see your post and provide ideas, which was the case with my compression post (no doubt in part attributable to the first blog post in the series trending on Hacker News). Many kind readers have suggested new directions for my compression experiments based on my writing so far.

It is uncomfortable documenting things that don't work out. I struggled with this with my compression series. After writing four posts where I openly provide the context that I am learning and may be wrong, it still feels a tad strange. I find writing as I learn here on this blog helpful. Perhaps you will, too.