The Programmer’s Rememberall

—Andy Hunt

10/01/2010
Published in PragPub Magazine

In the popular Harry Potter series, one of the characters (Neville, if I remember correctly) gets a gift of a Rememberall: a magic ball that glows and swirls with magic energy to remind you that you’ve forgotten something important.

The problem is, it doesn’t have a text display (something many of the magic devices at Hogwarts seem to be lacking). It can only tell you that you’ve forgotten something, but it can’t tell you what you’ve forgotten.

For most of us programmers, this thing would be going off all the time.

Remember the Future

There’s no end to all the little things we think will remember later on in the project. But of course, it doesn’t quite work that way. As soon as you find yourself saying, “oh, I’ll remember that later,” stop. You won’t.

There’s a Chinese proverb that says the palest ink is better than the best memory, and that’s exactly right: human memory is notoriously fallible. From introductory psychology classes to police interrogations, experts can have a lot of fun with people proving that their memory isn’t what they think it is. It’s actually pretty easy for your brain to confuse imagined events with real memories. The problem is that memory isn’t written to some static store in the brain like a gigantic disk drive. Instead, each memory is an active process; a small electrochemical machine that can’t stop running or the memory is lost.

And it’s not static at all: every time you access that memory, the memory will be changed a little bit. This happens so often and so automatically that you might consider that every read is a write. In other words, your memories are constantly rewritten in light of your current context: age, experience, worldview, focus, and so on. That incident at your sixth birthday party? It probably didn’t happen that way, and it may not have happened at all. Those decisions you made back at the start of the project? Or even just last week? Do you really remember why you wrote the code the way you did, or why the architecture took that particular direction? Probably not. Your memory has been modified in the meantime, updated with new data and new perceptions.

The solution is to heed the Chinese proverb and use some ink: start and maintain an engineer’s log of notes from design meetings, coding questions and solutions, and so on. You can use one of those composition notebooks that you might have used back in college, or a nice Moleskine, or just a yellow legal pad. I prefer to use something non-electronic (for one thing, it’s harder to modify and revise original notes.) But you might use a set of text files, or a Wiki, to keep notes. That at least has the advantage of being searchable, and possibly time-stamped.

The rule here is simple: if you need to remember it, write it down.

Wait, what?

Nothing is more irritating than being interrupted during the middle of a long coding or debugging session. Once you’ve been interrupted like that, it can take 20 to 30 minutes to get back into your flow and restore your context.

Interruptions play havoc on your memory. What were you doing? Or more importantly, what were you going to do next? It can be really hard to remember these things once the interruption is over and you get back to the task.

But there is a technique that can help: you need a task resumption cue. You’re sitting there, deep in your task, and the phone rings. The boss is standing next to your desk. Whatever the interruptor, you’ve got about a second or two to act before the interruption takes full hold over you. Use that time wisely.

Drop a resumption cue—some small bit of text that will help you remember your context when you come back. For instance, you’re in the middle of typing a line of code and the boss pops up like a cubicle-farmed prairie dog wanting to talk to you. Quickly, just type out the thought in your head: what you’re doing and what you need to do next. This doesn’t need to be full sentences or even anything that makes any sense to anyone else. You might end up with something in the code like this:

int x= add exp handler chk frozbot and xyzzy

You were in the middle of a declaration, but you had just a second to add some text about what you were doing. Now when your interruption goes away (“fell or was pushed”) you can return to your code and more quickly restore your context and resume your task where you left off: “Oh that’s right, I need to finish the exception handle and then go check these other two modules, Frozbot and Xyzzy”

The programmer’s Rememberall is text, plain and simple. Jot yourself a note, leave yourself a task resumption cue, and you’ll be better off than all the wizards at Hogwarts.

Something to think about.

What’s a guru meditation? It’s an in-house joke from the early days of the Amiga computer and refers to an error message from the Amiga OS, baffling to ordinary users and meaningful only to the technically adept.

Keep up to date with my low-volume newsletter and don't miss another article or fresh idea:

Your subscription could not be saved. Please try again.

Your subscription has been successful.