A System for Getting Things Done

Posted: 27 May 2012. Tags: agile data structures productivity abstraction comments

Whenever I have a problem that I need to solve, I tend to draw upon what I know, and what I know is software development (or at least I like to think that I do). Recently, I have come to realize that I need to be more productive with my interests outside of work. My ‘to do’ queue has grown large enough to where things are falling off of it, sometimes because they lose relevancy. I’ve realized I need a system.

Lean

Modern software development practices have drawn upon the Lean methodologies, which were pioneered by Toyota. One of these principles is Kanban, a system for deciding what to do and when to do it in a JIT (just in time) system.

There are 2 important things that get a lot of attention with the Kanban system, and I focused on them when thinking about my system for productivity:

  • Visualize your work

  • Limit work in progress

These things have been getting a lot more attention lately, because influential figures in software development are discussing it publicly. A Harvard Business Review post points out how doing one task at a time can help you do more. Joel Spolsky puts it this way:

“The trick here is that when you manage programmers, specifically, task switches take a really, really, really long time. That’s because programming is the kind of task where you have to keep a lot of things in your head at once. The more things you remember at once, the more productive you are at programming. A programmer coding at full throttle is keeping zillions of things in their head at once: everything from names of variables, data structures, important APIs, the names of utility functions that they wrote and call a lot, even the name of the subdirectory where they store their source code. If you send that programmer to Crete for a three-week vacation, they will forget it all. The human brain seems to move it out of short-term RAM and swaps it out onto a backup tape where it takes forever to retrieve.”

It turns out they are valuable for more than just manufacturing or software development. These ideas are applicable for general productivity as well.

The Old System

Before I dive into how I’ve applied these concepts (and what I want to do to improve it), let me describe to you the system I have been using (I imagine this is a system familiar to some of you). I like to learn new things about software development. A lot. Like, obsessively. The way I’ve been managing this process has usually been to use a solution like Evernote or Notational Velocity (thanks, Shezad!), and went something like this:

  1. Discover thing X that I want to learn.

  2. Add thing X to the back of a ‘to do’ queue.

  3. Never get to thing X. :-(

Step 3 is a recent development, because my obsession for learning means that the list has become rather long. Up until now the queue has been short enough for me to work through the items with my current level of productivity, but that’s no longer true. I needed a change if I wanted to keep up.

The New System

As mentioned before, the Kanban system places emphasis on limiting the amount of work in progress. This is very important in software development; Context switching is very expensive. The way to mitigate this is to focus on one thing at a time, without unexpected interruption.

Now, day-to-day productivity is slightly different, because it’s not quite the same as software development with all those things juggling in your head. However, it’s still very important to limit the amount of work in progress, and only pull the next thing when you are ready. In fact, you don’t even want the next thing to be visible, because you’ll only end up distracted by it. So for the new system, I wanted something where I constrain my immediate productivity goals to a single item, and not even have the others be visible to me.

No Longer a Queue, but instead a Circular Queue

Yes, I’m making an analogy with a software data structures. Stay with me…

One of the other things that I value is that some tasks have higher priority than others. For example, I definitely want to learn Objective-C better, but Ruby is more important to me right now. So the new system needed to have a way to allow for that.

A standard Queue works something like this:

But what I really want is something like this:

The idea here is that if the queue has a fixed length, lets say 5, and you insert into it multiples of an item, then what happens is that when you walk the queue, you are delivered that item more frequently than others. The intent is that items that have more priority than others are inserted in multiples corresponding to their relative priority.

  1. Ruby

  2. Objective-C

  3. Ruby

  4. Read book

  5. Ruby

Each task has the same time weight associated with it. So for example, the above 5 items might all have a weight of 1 hour each, representing 5 hours of productivity.

So if you take this idea of a continuous data structure, with a priority and fixed widths, and marry it to the idea of limiting work in progress (with limited visibility into whats coming next), then what you end up with is a very efficient way to be covering your tasks.

Minimum Viable Product

I’ve wanted to develop an application to facilitate this system for a while now, but because I have other projects currently in development, I haven’t been able to put the rubber to the road, and therefor the system never became reality. Rather than wait until that project bears fruit, I decided to short circuit the process and go analog for the time being. This picture is the result.

It’s a stack of 3x5 cards held together by a clip. The only task visibile is the one I’m working on right now, which limits my work in progress (I don’t know what’s coming next, so I can’t be distracted by it). Right now I’m dedicating 1 hour each to a task. When the hour is up, it’s time to switch, and I take the top card and put it in the back of the stack. It’s analog, and rudimentary, but it’s helped me obtain a huge improvement in throughput. Your mileage may vary.


(c) 2014 Ben Lakey

The words here do not reflect those of my employer.