Get a monthly update on my podcast, writing and whatever else I'm up to.
Learning When to Learn
Hello, CoRecursive newsletter subscriber,
It’s August now, and I have a new episode out here:
It's about learning, and this is a topic very dear to my own heart. The episode shares some history of learning research and imparts some guidelines for embarking on a learning side project while also being an entertaining listen.
There is, besides these learning guidelines, a higher-level question. What should I learn? What should I throw myself into? I have a process for answering that question. Let me explain.
I have so many side learning projects that I want to take on. And I have a firm belief, always, that the current project will enable me to do extraordinary things. To become amazing at some new skill or build some tremendous new creation.
The Parens Closet
I remember years and years ago, having some time off at Christmas with my now wife. But I had gotten Practical Common Lisp, Peter Seibel's book, and was so excited about it. Kourtney wanted to do some things with our time off, one of which was cleaning out our closet. The apartment building had originally been a three-story university hall 30 years earlier, and when they subdivided it into apartments, the apartments had strange shapes, including an infinitely large front closet that had collected a lot of junk.
She thought cleaning out this closet would be a fun project for us to tackle at a leisurely pace with our couple remaining days off. But I approached it aggressively – trying to work as quickly as possible –because I had already planned exactly what I'd do with my time off, working through Practical Common Lisp. I needed to get the closet done to get back to figuring out how to install SLIME, the editor recommended by the book.
The beginning of a learning project is always so magical. I can picture what amazing things I'll know on the other side and how I'll be a better person. I always seem to forget about the effort.
And then, as things progress, the feeling can change. Frustration can mount, or things can seem to move too fast or too slow or just get confusing. With Practical Common Lisp, I remember lots of confusion around emacs. ( There were strong recommendations in the book to 'just learn to use emacs, and you'll thank me later.' )
Later, Christmas break is over, and my momentum is gone. The vision of the value of learning LISP and the reality of what the learning project can bestow come into conflict.
At this point in a learning project, I can be pretty hard on myself. If I were a mentor and had a student in front of me, I would never say what's in my internal dialogue when I'm trying to get myself going. A lot of 'what's wrong with you,'' you can do this,' and 'Real developer could do this.'
My criticism of myself does work. I convince myself via an inner dialogue that my identity as a developer is tied up in getting through the book and forcing myself to keep going, but it just makes a bear to deal with.
The early joy about showing Kourtney Emacs and explaining why it's cool shifts to frantically working through a book that was supposed to be fun and getting frustrated when interrupted because doesn't she understand what's on the line here; my ability as a developer is being questioned. But isn't this just a book you got for fun? Yes, but ... it's hard to explain the internal criticism that pushed me forward. But yeah, this is how I learned a lot of things. I would summon my inner critic to move me forward. It's not fun.
I'm older and wiser now, and I've got a better approach. First, I'd like to tell my past self and you that the learning project may not matter. I don't want to knock that LISP book, but LISP didn't change anything magical about my thinking, and my forced emacs skills helped with nothing. Peter was wrong about that.
And life is only so long. There are only so many things you can throw yourself at, and it's perfectly rational to bail on a project. Maybe what you've learned is the very real and practical knowledge that this is not for you. Not right now.
Because life is about tradeoffs, and it doesn't make sense to force yourself into something. So that's my first tip: Stop early and have some self-compassion.
After that, it's about starting more cautiously.
Starting More Cautiously
Peter's book was interesting. And I liked it, I swear. But just because something tests your abilities and teaches you something doesn't mean it is valuable for your life or career.
All those things I told myself about the stakes of that book, all those quotes about learning Lisp changing who you are - making you fundamentally better – were not true. It was more like an intellectual quest, like learning about the civil war - then some transformative hero's journey into the land of parens.
That's not a knock on LISP. It's a statement about expectations. Starting something new is always fun and exciting. All the potential! All the promise! But that excitement is different than the motivation to keep going at it, the motivation for actually working through things week after week. So now, what I do is, because I still get excited about a project's potential is that I delay. That is what I recommend.
If I get excited about starting some new side project, I write it down. I use Roam, but any place you store notes can work. And in it, I have a page called future projects, and I add my new project ideas there.
A project has to spend time waiting there before I start it.
When Learn LISP has to sit next to Learn Rust, Learn Transformers, Learn Spanish, build a podcast app, and 32 other projects, then it puts it into a more realistic context.
And then the thing I do when I really want to start working on this project, instead of starting, is investing time in planning: OK, I want to learn LISP.. well which LISP? What are the popular books? What about Clojure? What do I want to get out of this project? Spend time planning a project, and you will get better at executing them
My future projects list is constantly growing, but not as fast as it used to, because half the new things I get excited about are already on there, with a partial plan or at least some random links.
This way, instead of spending time starting to learn Lisp and then switching to build a personal website and then switching to learning LISP and circling around, I can be a bit more conscious about it and get more done on time horizons of years, while on the horizons of weeks, I'm doing less. It's productivity by doing less.
Doctors have a phrase for the benefits of inaction: "Don't just do something, stand there." It's meant to trigger you to slow down and think before you jump into something. And that is my advice. Don't start a project right away. And don't be too hard on yourself if a project isn't working out or isn't engaging you.
Anyhow, my podcast episode is about learning, learning how to program, and the research on the best ways to approach it.
Give it a listen, and let me know what you think.
Get a monthly update on my podcast, writing and whatever else I'm up to.
Adam Gordon Bell Feb 2nd Beautiful Code Welcome to February and a new CoRecursive episode: Beautiful Code - Inside Greg Wilson's Vision for Software Design Greg Wilson has been on a decades-long quest to transform how we teach and talk about software design. From getting rejections for using the term "beautiful code," to empowering scientists through workshops on Python and Unix, Greg has pushed to bridge the gap between theory and practice. In this episode, Greg shares his failures and...
Adam Gordon Bell Jan 2nd Brain Injury Sparks Python Mastery Welcome to 2024 and a new CoRecursive episode: Code As A Lifeline What if your dreams were suddenly ripped away? What if your talents vanished, your passions erased? That’s what happened to Jason McDonald when a traumatic brain injury at 16 ravaged his planned destiny of becoming a doctor. Jason painfully rebuilt his identity from scratch - relearning to read, write, and even speak. A serendipitous discovery of coding ignited a new...