(A classic from my older blogging days. Enjoy!)

One of the most valuable things I ever did was take the Algorithms class on Coursera. It taught me to think about efficient systems. If you want to know why some operations are fast and some are slow, take the class.

While this is useful for understanding how to manage the efficiency of computer programs, it doesn’t end there. All the lessons apply equally well to much more complex human systems.

Consider the stack. In most programs, the main thread will use a temporary memory space referred to as ‘the stack’. The stack is, by nature, fast. The memory is all in one small space, so reading and manipulating is easy. It’s also a LIFO (last in, first out) system, where new instructions are automatically placed at the top of the stack. When the instructions are finished, the system will continue executing the next layer of the stack until it gets to the bottom.

Our brains act like a stack. As soon as we’re given something new, it goes to the top automatically. Phone rings, top of the stack. Email ping, top of the stack. Slack message, top of the stack.

The stack is a problem for the brain because while the computer is fast at switching tasks, we are not. Additions to our stack are very time-consuming. Every productivity tip about ‘flow’ states is essentially this – protect the stack.

A better place for new tasks is a queue. A queue works just like the line at Starbucks, processed in the order in which they arrive, or FIFO (first in, first out).

Now, getting people to put your tasks in a queue would be a significant improvement. You could work uninterrupted on one task until it was finished, then go to the next task. In theory, this would be maximally efficient. But what if a critical task shows up in the queue? Maybe you don’t want it to be last.

How about the priority queue? This is a handy data structure. It works just like the regular queue, but whenever new items are added, they are placed in the queue according to whatever priority scheme the programmer utilizes. While this is a nice solution, we now have to start thinking about performance. Stacks are used because they’re fast. One write, one read. And the queue is essentially the same. Just stick it at the end. The priority queue requires sorting. Because you have to place the item in a particular spot, you must perform a sort every time a new item gets placed in the queue. You can’t just throw it in the queue; you have to organize it. Every time.

Ever been given a list of tasks, carefully gone through each one, determined which is most important, and then made a handy todo list in order? That’s a priority queue. It’s an improvement, but there’s a dark side. If you’re constantly adding items, it becomes really slow. Every addition requires re-sorting the whole thing. In this situation, it’s easy for nothing to get done except having an organized list of unfinished activities. And since your brain is a stack anyways, the top item keeps being set to “sorting the queue.” It’s not exactly how I like spending the day.

What about items that might need to be done at some point but don’t belong on the queue? The presentation that’s 3 months away. Or remembering to take out the trash in a few days? You should put them in a database. A database is nice because you have clearly defined data rules that you can rely on. Retrieval and archival are, while orders of magnitude slower than the stack, a fairly painless process once we know what to read/write.

The database is your calendar, memos about tasks, and lists to be used later. Need to work on something in a month? Put it in the database, clearly labeled, and access it when needed.

Here’s what it all means for your work day:

  • Since your brain is the stack, avoid putting new items on top. Minimize interruptions. Minimize distractions. Stop checking your email all the time.
  • Since your todo list is a priority queue, avoid continual re-sorting. Organize your queue at the beginning or end of the day. Otherwise, the sort stays in the stack (brain), and you can’t free up that memory (attention).
  • Information that isn’t useful now should be written to the database. If you’ve got a meeting in three days, write down what you need, set an alert, and deal with it later. Be sure to write to the appropriate area of the database; otherwise, retrieval will be slow (Keep your notes organized). Keep this off the priority queue, or sorting the queue will become too time-consuming.

So why not just put everything in the stack? It’s faster anyways, right?

The stack (your brain) has a limited bandwidth. Too many items on the stack will cause an overflow error, where the program runs out of space in the stack and writes to an area outside the buffer, corrupting other data. Ever messed up a critical project when you’re tired and stressed? Blame it on the buffer overflow. A more organized system will use virtual memory to prevent errors, but anyone who’s opened too many tabs in Chrome will know what happens next. Unbearably slow performance, just like when you have 12 “must-do” items on your todo list. Somehow, zero get done.

And as one last idea, there’s no shame in taking a little vacation to defrag. You might feel better. And, after all, you’re not a machine.