Smashing the distraction stack for fun and profit
In a recent post, Ned Batchelder, said "I was already three or four levels deep on the distraction stack, so I went and looked." This phrase fascinated me. Those of us who write software, or work with other complex technical tasks, often have to solve problems on several levels simultaneously, and I have long thought of this process as being similar to the way functions are called in software programmes.
Each function in a programme is dedicated to performing some task, but it may well need to call other functions to do this. The computer can only deal with one function at once, so it first needs to save the details of the calling function before beginning to process the function that is being called. The usual way of doing this is in a data structure called a stack. (In other contexts, this kind of structure might be referred to as a last-in-first-out queue, or a LIFO.) If the called function needs to call another function, it too "pushes its state" onto the stack before making the call. As each of the called functions finishes processing and returns, the state of the function that called it can be retreived, and that function can carry on where it left off. When that function in turn completes, its state in turn is sitting on the top of the stack waiting for retreival.
When researching a new technique, or finding the solution to a problem, this is often what you do. You get to a point where you can't carry on your current line of research without first solving some other problem. At this point, you make a mental note of where you are up to, and go off to solve the problem, repeating as necessary, and hoping that you don't have to hold mental state for too many things. As you solve each of the secondary problems, you back up to the point at which you got stuck, and at which you are now presumably not stuck any more.
Of course, it's not just when solving problems (in which case you pretty much have to follow this through to the bitter end). Sometimes, you are studying, and you find something that you should understand before moving on. This can lead to the same process of parking your mental state and taking some detour. There is often a choice as to whether you should do this now (stack-based processing) or queue the problem elsewhere for off-line processing. Whether you do this will generally depend on why you're doing what you're doing at the time. In Ned's case, he decided to indulge himself and go and check up an arcane detail of the HTML specification. Under other circumstances, you might have to carry on in the interests of progress and deny yourself the satisfaction of full knowledge.
From now on, when I'm busy with private-time research projects, and free to enjoy the diversions, I'll revel in the notion that I'm somewhere in the distraction stack.