September 10th, 2019 · 17 comments
In computer programming, it’s common to split your program into multiple different threads that run simultaneously, as this often simplifies application design.
Imagine, for example, you’re creating a basic game. You might have one thread dedicated to updating the graphics on the screen, another thread dedicated to calculating the next move, and another monitoring the mouse to see if the user is trying to click.
You could, of course, write a single-threaded program that explicitly switches back and forth between working on these different tasks, but it’s often much easier for the programmer to write independent threads, each dedicated to its own part of the larger system.
In a world before multi-core processors, these threads weren’t actually running simultaneously, as the underlying processor could only execute one instruction at a time. What it did instead was switch rapidly between the threads, executing a few instructions from one, before moving on to the next, then the next, and then back to the first, and so on — providing a staccato-paced pseudo-simultaneity that was close enough to true parallel processing to serve the desired purpose.
Something I’ve noticed is that many modern knowledge workers approach their work like a multi-threaded computer program. They’ve agreed to many, many different projects, investigations, queries and small tasks, and attempt, each day, to keep advancing them all in parallel by turning their attention rapidly from one to another — replying to an email here, dashing off a quick message there, and so on — like a CPU dividing its cycles between different pieces of code.
The problem with this analogy is that the human brain is not a computer processor. A silicon chip etched with microscopic circuits switches cleanly from instruction to instruction, agnostic to the greater context from which the current instruction arrived: op codes are executed; electrons flow; the circuit clears; the next op code is loaded.
The human brain is messier.
When you switch your brain to a new “thread,” a whole complicated mess of neural activity begins to activate the proper sub-networks and suppress others. This takes time. When you then rapidly switch to another “thread,” that work doesn’t clear instantaneously like electrons emptying from a circuit, but instead lingers, causing conflict with the new task.
To make matters worse, the idle “threads” don’t sit passively in memory, waiting quietly to be summoned by your neural processor, they’re instead an active presence, generating middle-of-the-night anxiety, and pulling at your attention. To paraphrase David Allen, the more commitments lurking in your mind, the more psychic toll they exert.
This is all to say that the closer I look at the evidence regarding how our brains function, the more I’m convinced that we’re designed to be single-threaded, working on things one at a time, waiting to reach a natural stopping point before moving on to what’s next.
So why do we tolerate all the negative side-effects generated from trying to force our neurons to poorly simulate parallel programs? Because it’s easier, in the moment, than trying to develop professional workflows that better respect our brains’ fundamental nature.
This explanation is understandable. But to a computer scientist trained in optimality, it also seems far from acceptable.