When it comes to personal projects, when does it make sense to work quickly and when does it make sense to work slowly? I've been talking to people about how they balance client work with personal projects. It can be tempting to focus on client work because that comes with clear tasks and feedback. People's requests set a quick pace. For personal projects, though, the pace is up to you.

It's easy to adopt the same kinds of productivity structures used in the workplace. You can make to-do lists and project plans. You can set your own deadlines. I want to make sure that I explore different approaches, though. I don't want to just settle into familiar patterns.

2014-04-07 Working fast and slow #experiment

I work on personal projects more slowly than I work on client projects. When I work on client tasks, I search and code and tweak at a rapid speed, and it feels great to get a lot of things done. My personal projects tend to be a bit more meandering. I juggle different interests. I reflect and take more notes.

Probably the biggest difference between client work and personal projects is that I tend to focus on one or two client tasks at a time, and I let myself spread out over more personal projects. I cope with that by publishing lots of little notes along the way. The notes make it easier for me to pick up where I left off. They also let other people learn from intermediate steps, which is great for not feeling guilty about moving on. (Related post: Planning my learning; it's okay to learn in a spiral)

Still, it's good to examine assumptions. I assume that:

• doing this lets me work in a way that's natural to me: what if it's just a matter of habit or skill?
• it's okay to be less focused or driven in my learning, because forcing focus takes effort: it's probably just the initial effort, though, and after that, momentum can be useful
• combinations of topics can be surprisingly interesting or useful: are they really? Is this switching approach more effective than a serial one or one with larger chunks?
• a breadth-first approach is more useful to me than a depth-first one: would it help to tweak the depth for each chunk?

2014-04-02 On thinking about a variety of topics – a mesh of learning #my-learning

One of my assumptions is that combining topics leads to more than the sum of the parts. I took a closer look at what I write about and why. What do I want from learning and sharing? How can I make things even better?

2014-04-02 Evaluating my sharing #sharing #decision

Emacs tinkering is both intellectually stimulating and useful to other people. It also works well with applied rationality, Quantified Self, and other geekery. I can align sketchnoting by focusing on technical topics and  on making it easier to package things I've learned. Blogging and packaging happen to be things I've been learning about along the way. Personal finance is a little disconnected from other topics, but we'll see how this experiment with the Frugal FIRE show works out.

If I had to choose one cluster of topics, though, it would be the geek stuff. I have the most fun exploring it, and I am most interested in the conversations around it.

What does that mean, then? Maybe I'll try the idea of a learning sprint: to focus all (or almost all) my energies on one topic or project each week. I can work up to it gradually, starting with 2-4 hour blocks of time.

2014-04-02 Imagining learning sprints #my-learning

Because really, the rate-limiting factor for my personal projects is attention more than anything else. If I experiment with reducing my choices (so: Emacs basics, Emacs chats, open source, Quantified Self), that will probably make it easier to get the ball rolling.

2014-03-28 Identifying rate-limiting factors in my work #kaizen

So I'm still not adopting the taskmaster approach, but I'm reminding myself of a specific set of areas that I want to explore, gently guiding the butterflies of my interest down that way.

We'll see how it works out!