Can computer scientists — the people who think about the foundations of computing and programming — help us to solve human problems such as having too many things to do, and not enough time in which to do them?
That’s the premise of Algorithms to Live By (US link) a book by Brian Christian and Tom Griffiths. It’s an appealing idea to any economist. We tend to think of everyday decisions as a branch of applied mathematics, which is what computer science is.
To be clear, using computer science is not the same as using computers. Computer scientists have devoted decades to problems such as sorting information, setting priorities and networking. Many of the algorithms they have developed for computers can also work for human beings. An algorithm, after all, is not a computer program. It’s a structured procedure, a kind of recipe. (Algorithms are named after a 9th-century Persian mathematician, Al-Khwārizmī, but they predate his work by thousands of years.)
So, what is the optimal recipe for working through the to-do list? Perhaps it is simpler than you think: do all the jobs on the list in any order, as it will take the same amount of time in the end. There is a touch of brilliance in this advice but it also seems to show that computer science will never shed light on the stress and wheel-spinning that we feel when we have too much to do.
Or so I thought. Then I read a 1970 paper by the computer scientist Peter Denning, which describes a problem that computers can have when multitasking. Most computers do not literally multitask; instead, like humans, they switch rapidly between one thing and another. A computer will flit between updating your screen with a Pokémon, downloading more videos from the internet, and checking to see if you have clicked the keyboard or moved the mouse, among many other processes. But even a computer cannot do an unlimited number of tasks and, at a certain point, disaster can strike.
The problem stems from the use of readily accessible “caches” to store data. To understand caches, imagine a pianist playing from two or three sheets of music in front of her. Those sheets are in the fastest cache. There are other sheets behind them, accessible in a few moments. Then there are larger but slower caches: music in the piano stool; more up in the attic, and yet more in a music shop. There is a trade-off between the volume of information and the speed with which it can be accessed.
This set-up is no problem if the pianist only plays one complete piece at a time. But if she is asked to switch every minute or so, then some of her time will be taken retrieving a piece of music from the piano stool. If she must change every few seconds, then she will be unable to play a note; all her time will be taken switching sheet music between the stand and the piano stool.
It is the same with a computer cache: there will be a hierarchy — from super-fast memory in the microprocessor itself all the way down to a hard drive (slow) and offsite back-up (very slow). To speed things up, the computer will copy the data it needs for the current task into a fast cache. If the tasks need to be switched too often, the machine will spend all its time copying data for one task into the cache, only to switch tasks, wipe the cache and fill it with something new. At the limit, nothing will ever be achieved. Denning described this regrettable state of affairs as “thrashing”.
We’ve all had days filled with nothing but thrashing, constantly switching focus from one task to another but never actually doing anything. Can we borrow a solution from the computers? The most straightforward solution is to get a bigger cache; that is easier for a computer than for a human, alas.
The obvious alternative is to switch tasks less often. Computers practice “interrupt coalescing”, or lumping little tasks together. A shopping list helps prevent unnecessary return trips to the shop. You can put your bills in a pile and deal with them once a month.
But we often find it difficult not to flit from one task to another. Computer science says there’s a reason for the pain: there is a trade-off between being swiftly responsive and marking out chunks of time to be productive. If you want to respond to your boss’s emails within five minutes, you must check email at least once every five minutes. If you want to go off-grid for a week to work on your novel, your response time must slow to a week.
Any solution should acknowledge that trade-off. Decide on an acceptable response time and interrupt yourself accordingly. If you think it’s perfectly fine to answer emails within four hours — fine by most standards — then you only need to check your email once every four hours, not once every four minutes. As Christian and Griffiths advise, decide how responsive you want to be. If you want to get things done, be no more responsive than that.
Written for and first published at FT.com.