Taking learning seriously

May 30, 2024

Like many programmers, I’ve always enjoyed learning new things. But over the past year, I’ve started taking learning seriously in a way that I never did before — at least outside of a formal academic setting.

Earlier in my career, learning was basically a given: almost any interesting project I could take on would involve diving into things I was unfamiliar with. But at a certain point, this stopped being true. As I gained more experience, I realized that I’d need to make a conscious effort to prioritize learning; otherwise, it would get easier and easier to stay in my comfort zone.

Over time, I’ve landed on a few small practices that work well for me. They’re not groundbreaking, but in combination they’ve made a pretty big difference.

Spaced repetition

Perhaps this is an obvious one. Maybe you’re thinking, “Surely he’s not surprised that spaced repetition is useful for learning!”

It’s not that SR is new to me — I first encountered it when I was learning German more than 15 years ago. I used Anki on and off over the years, but eventually stopped when my language skills got to a certain level.

But until recently, I never really considered using it for more complex topics — things that are less obviously about memorization. I was inspired to give it a try due to Michael Nielsen and Andy Matuschak, who’ve written persuasively about the benefits of SR in developing conceptual understanding.

It was surprising to me how much value I get from preparing the cards/prompts. The review is obviously critical, but — for complex topics at least — I feel like writing the prompts is quite helpful, and even enjoyable.

It’s also a hack that forces me to pay closer attention when I’m reading reference material. Normally, if I’m reading a textbook like Fundamentals of Computer Graphics, it’s difficult to pay close attention and to really understand what I’m reading. But I’m more likely to do that if I read with the goal of writing some Anki prompts.

TILs

Like spaced repetition, this is another practice that led to some unexpected benefits.

Back in November of last year, I started a TIL (today I learned) repository. Since then, I’ve published 16 entries — a bit more than one every two weeks.

To be honest, I can’t quite remember what my motivations were. If anything, I thought that writing some of these things down would help me remember them, or at least give me an obvious place to search when I’d forgotten. But it’s turned out a bit differently than I expected.

What actually happens is this: I run across something that’s worth a TIL post, and the simple fact that I’m writing about it makes me explore it more deeply and try to understand it more fully. Once I’m ready to publish it, I’ve already gotten most of the benefit!

You’d think you could get most of the same benefits by taking careful notes, but there’s something powerful about making things public — it forces you to put an extra bit of thought and care into them.

Side projects

I recently tweeted about how I’ve changed my approach to side projects:

One of the best decisions I've made in the past few years is to stop treating side projects like work projects.

E.g.
- "doesn't something like that already exist?"
- "you shouldn't implement that yourself"

Both make sense at work, but wrong attitude for side projects imo.

— Patrick Dubroy (@dubroy) May 3, 2024

Previously, I tended to work on things that were either useful, novel, or valuable (i.e., could possibly be turned into some kind of business). It’s almost as if I was trying to satisfy a hypothetical Hacker News commenter.

But lately, I’ve started to take on projects purely to learn something. The things I’m building are ostensibly pointless or useless, but I learn a lot from the process of building them.

For example, here are some of my projects from the past few months:

• A bytecode interpreter for parsing expression grammars¹ — because I’d never written a bytecode interpreter before.
• A JavaScript library that implements the same semantics as the Scratch programming language² — because I wanted to better understand Scratch’s semantics.
• A 3D software renderer³, to learn Rust and to brush up on my geometry and linear algebra skills.

You may notice a theme here: building a toy implementation of some existing thing, in order to better understand the core concepts. This is also new to me, but now that I’m in the habit of it, I want to do it more and more.

For example, I’ve been learning NumPy, and now I’m itching to write my own little ndarray library.

YMMV

…of course. These are a few things that work for me. Consider giving them a try, maybe they’ll work for you too.

If there are other tactics you’d recommend, I’d love to hear about them. You can send me an email or respond on Twitter.