Offline knowledge, buses, and note-taking

19 May 2019

In a team having knowledge that lives only in your head is a terrible thing.

So we should get the computers to remember things, and allow the humans to do the creative parts.

Writing software is a creative activity. You start with a blank text file and end up convincing people to give you their identity details in exchange for the ability to poke someone over Facebook. If that's not creative I don't know what is.

"The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination." -- Fred Brookes, The Mythical Man-Month

However, not only are humans forgetful, but having just a single person who knows how to do a thing is a huge risk. Some of you may know this concept as your project's "bus factor" -- how many people would have to get hit by a bus for your project to fall over. To make sure your project is resilient to buses (and more mundane problems, like forgetfulness) you need to make sure lots of people can do any given task - i.e. get information out of your head.

Knowing that brains are a bad storage place for reference information is not a new idea. This is the basic idea behind documentation. But before you can have effective documentation, first you need to have a place to put those things. A scheme for encouraging documentation.

I'm not going to talk about technical documentation here, for a couple of reasons. Firstly, I'm not qualified, given I don't think I document very well (apologies to my team mates), but also because the practice of documenting isn't that complex, in my opinion. You just need to make time to do it.

The thing that's been interesting me recently is how to manage your personal documentation - keeping track of your upcoming work and staying on top of it, while maintaining enough headspace to stay focussed on your current problem.

One of the best ways of improving your productivity is to stop yourself thinking of things you have to do, and allow yourself to think how to do them. This is only possible if you have systems to do your remembering for you, giving you the space to do the creative problem solving part.

The key thing that needs to happen to allow you to do that is to get things out of your head and into your system. Your system can be digital, notebook based, post-it based, whatever. How you actually record things doesn't matter, but there are a few key characteristics I think are important for your system to work well:

1. You need to be able to know where to look next

For it to be effective, it must be clear what your immediate priorities are. As in 10 minutes to an hour immediate. Looking at it should tell you precisely and accurately what your next task should be, with enough detail that you could go away and find further context for the task if necessary.

2. You need to be able to add all incoming tasks to it

Working life adds tasks to your inbox all the time. These will not come at convenient moments when you can think about when in your next week you'll be able to do it. Taking the time to schedule and prioritise every incoming task will kill all momentum on your current task. Your system therefore needs to allow you to quickly (in under 10 seconds) add any incoming task to an appropriate place that you can guarantee you will pick it up later, and in time that you won't miss any associated deadline.

3. It must be always available

There is no use in a system that you only have to hand 70% of the time, as it will only capture at most 70% of the things you want to track. This will leave you trying to think of things again, rather than about them. Or, just as bad, you will come up with potentially multiple other places to record tasks, making all your lists ineffective at helping you decide what to do next.

What I have found wonderful is that these principles apply equally well to both personal organisational lists and shared ones, working as part of a team. Different methods of applying them work better for each environment (my phone is a bad place for shared work priorities to live, for example), but applying the principles helps me with prioritisation and decision problems wherever I have them.

More like this: