author and publisher.
The Programmer’s Rememberall
Published in PragPub Magazine
In the popular Harry Potter series, one of the characters (Neville, if I remember correctly) gets a gift of a
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
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
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,
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
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”
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.
Stop Practicing and Start Growing
July 11, 2016
January 25, 2016
It's an Experiment
May 18, 2015