The Particular Finest

Presented by aurynn shaw

To-do is Crap


Getting Things Done is the process of putting yourself at the mercy of a neverending series of lists; the things I’m doing today, the things I’m doing tomorrow. This week.

This year.

A series of checkboxes, nested to try to capture the complexity and nuance of achievement. Tasks have sub-tasks, each of which has a subtask. Once all the sub-tasks are complete, is the task complete? Does it end?


To-do lists don’t work very well for me. I’ve tried; I loved the UI and delight of Clear; Siri and Reminders is great for tracking ephemera, concepts that don’t need nuance or depth.

When programming, however, it gets harder. A bug ticket isn’t a task; it’s an invitation to explore, a quest given to delve the deepest bowels of a dark world and return, triumphant.

Too often, however, that ticket IS a task. It attempts to be a single construct to capture everything within a bug, no matter how many systems it may touch.

Some depth is captured, through sloppy web forms and occasional updates, but so much more is lost. Notes and ideas, dead-ends and half-formed thoughts during the work, lost from exploration.

The Lab Notebook Analogy

I read a great article1 about how most scientists are trained to keep a lab notebook; a place where random ideas and writings end up, where thoughts and intermediate insights can live, can capture that missing nuance.

Programmers, however, aren’t trained like that. We don’t think in terms of intermediates; our tools all too often reflect binary states. Fixed or broken, complete or incomplete.

Our commit logs start to capture this information, why changes have been made. Discipline or tool hackery is required to commit frequently, however, and my commit logs never capture I’m going to try this approach”, only This commit has these effects. Touches these files.”

Our existing systems suck for this, and we should be doing something better.

Capture Doingness

I approached this problem by building a tool to capture context as I program; the scattered thoughts that accompany my design and development ideas. Our agile workflow often requires that I change contexts quickly, focus on a new area, and lose what I was doing.

Reading through code, trying to refresh my mental state days or weeks later is difficult. Comments are only so detailed, and occasionally outdated. How it works is captured, but rarely why, the process that led to those choices.

My tool asks me what I’m doing, and why.

Tentatively, I’ve named it mangle.


mangle exists entirely on the *NIX commandline; a Python script and some shell aliasing, backed by a simplistic database.

Data is organised around tasks (yes, I know, the hypocrisy), which is a vague container for a series of things that relate to a group of things to do.

Adding an item to the list of current tasks is simply
$ m doing "A description here"
and querying for current tasks is
$ m ?
Logging work or thoughts is just as trivial,
$ m + "some thing I did"

with an intelligent mechanism to apply the doing-ness to the last section I was working in.

Changing the task is a sub-command to adding,
$ m + "some other thing" for {task id}

which tries to use easy-to-use sentence-like structures.


It’s intentionally an opinionated tool, and intentionally backs on to a Proper Database.

Using the shell as the primary input was intentional; easy argument separation was a must. Typing a quick command into an open terminal is also much easier than browsing to a webpage, or interacting with my phone.

Command structures are always of the sort $ m command arg subcommand arg eschewing conventional commandline flag parsing.


Forming the habit to use mangle was easy; most of my notes are on physical paper, switching to digital was trivial.

Maintaining the habit continues to be easy; I want to remember what I’ve done, why I tried something.

Have the feeling of accomplishment, that a week was well-spent.

Unfortunately, a bug or two early on can be damning; recovering corrupted data is a pain, and there’s always other things to do.

The bug will stay unfixed, the tool unusable, and the entire experience remarkably frustrating.


There’s a few more bugs I’d like to clean up on mangle before I release it to the world; I’ll post a link on the Particular Finest once it’s available.

Until then, what are your tools around capturing context? How do you keep yourself in the loop?

  1. Made of Bugs » Software Engineers should keep lab notebooks