Get Everything Done

If anyone wants to dig into these ideas at a real layer, then I encourage you to explore watching an Operating Systems lecture series or the like. A lot of the development of operating systems revolves around how to manage doing more things than the CPU has time to do "right now".

The same results as they find there tend to apply to human work as well, with caveats, with the most important things being that there isn't one right answer. Realtime systems have to take a different strategy than general-purpose operating systems which have to take a different approach than high-performance computing environments. To give you a rough idea of the three styles:

Real time systems tend to require responsiveness above everything else. This generally means that they need to work with "controlled cleanup" that is regulated, and where everything is "timeboxed" into small units with guaranteed interruptions between them. This means that we can ensure that the system will always be able to process new inputs at least every X units of time for whatever our X timebox is. There's the concept of garbage collection in computers, and realtime systems generally are very careful about how they do cleanup, with tight controls on how much can get into a system and how much is "left lying around" for later cleanup, because that cleanup can suddenly pile up into a set of things that will take longer than your X timebox to cleanup, ruining your responsiveness (in programming language theory this is the Garbage Collection spike or lag or overhead). In constrained embedded real time systems, cooperative multi-tasking might be the only way to go, but it requires every single task to be able to give up control at just the right moment.

For very high-performance systems, you're dealing with a massive amount of data that has to be run that is expensive, difficult, and time consuming. Here, getting through the data and maximizing throughput is most important, because context switching between tasks can bring your system to a standstill. In these systems, you often have a single queue that people register their "batch" for and then they wait in the queue until it's their turn, and then they have uncontested access to the system. This means you might have to wait a little bit to get going, but when you do, you'll have full access to the complete power of the system.

The hardest one, but the one that most people use every day is the general operating system. In this system, being able to work with lots of different tasks without becoming useless is the key. It's okay to have a little lag, but you can't make it happen all the time. These systems have evolved a lot over time and most systems today generally make use of pre-emptive multitasking, which means that there is something external that interrupts the processes at appropriate intervals to see whether they are going to switch to doing something else. The challenge is in how often these interrupts happen, how to manage them, and how to select what process to switch to, or whether to keep going on the current one.

http://en.wikipedia.org/wiki/Preemption_(computing)
http://en.wikipedia.org/wiki/Cooperative_multitasking
http://en.wikipedia.org/wiki/Process_management_(computing)

There's also lots of ramifications related to organization of our tasks and our work. For example, one optimization made by the Big Bag of Pages memory collection system was to sort data into different types, but only a few sets of big bags, which then allowed for review to happen over that data quickly, and to reduce the costs of going through your data and cleaning things up. This is something that GTD takes advantage of, by trying to create a few sets of relevant contexts and lists, with a process that clearly indicates which task goes where. The benefit is that during review in the day, you can review much faster, and then you can save a lot of review for a later date (weekly review), which helps reduce your in the moment processing overheads.

On the other hand, there are cases in operating systems where this algorithm won't help, because you don't know ahead of time how you can "group" things. You can look at managing your tasks as managing inputs and outputs as well, and there's a whole field of research on this as well:

http://en.wikipedia.org/wiki/I/O_scheduling

Simple scanning is very similar to the C-SCAN algorithm.

There's definitely a limit to the computer analogy. Not only do computers not face resistance, they also don't have nearly the same difficulties with large numbers of tasks. They can multi-task, literally. You can throw many thousands of tasks at a computer and rely on the context switching happening fast enough that ever task is likely to get enough CPU time.

I think things get a little more interesting when you look at what you have with resource constraint situations, such as embedded devices with very small memories, or very large HPC systems that have even bigger problems to crunch over, or how people managed systems when the processors were much, much slower, and memory much more limited. Even today, there's interesting stuff going on to deal with what happens when a modern system gets overloaded.

However, it's also the case that humans have a lot less clear goals, with a lot less clear paths, with a lot less clear sense of why. Anytime you have fuzziness, computers tend to struggle until we start taking pages from human neuroscience.

Charles:

I think you've captured the gist of things perfectly fine, and that's probably plenty good enough for application into your own life.

As a point on priority, general-purpose operating systems often do have the concept of high, mid, and low priority, but something really key about that is that almost all of the tasks (well over 99%) are in the mid priority. Effective operation of that priority system depends on having most of the tasks in the mid category. Moreover, priority doesn't have anything to do with importance in this case, but responsiveness. So high priority tasks are able to "choke out" mid and low priority tasks, and low priority tasks can never choke out mid and high priority tasks.

In that case, if you have only one or two high priority tasks, and only a few low priority tasks, then you're in good shape. You *always* take care of the high priority ones, and the low priority ones are *specifically* tasks that you are happy to have run almost never. I imagine a good use of such an approach could be having your "one big thing" as a high priority task that you always take care of, and then everything else in a mid-priority group, and then maybe a list of Youtube videos or the like to watch, which you can do or not do without consequence.

I personally think context is the more appropriate grouping mechanism (this is also more similar to the BiBoP model), but I think the mistake a lot of people make with contexts is misunderstanding their use. They're there as a convenience to help you ignore what you don't want to see at certain times, to make it easier to focus. It's a little like a closed list (not quite, though, since you don't have the shrinking effect). People often make too many contexts that they don't need. I think Mark's AutoFocus recommendation of a Home and Work list is an excellent use of the Context idea, and personally I've only found the Work and Home contexts really useful for active tasks.

As for finding new algorithms, I think Mark has been remarkably thorough in his review of different approaches. And as is often the case in C.S., the simplest processes often win out over seemingly more optimal ones because of their lower overheads.

I think for me, the thing that I'm leveraging the most at the moment is actually a networking concept. With an operating system, you can in theory spawn as many processes to do work as you want, and each active process will do work until it is put away and another one is brought onto the active queue. However, each process has a level of active overhead involved in terms of memory and context that has to exist in order to have that process in the execution queue.

When you are writing a network application, a naive way to do it is to take every message/input that is received and spawn a process to deal with that message immediately. If the number of messages is relatively low, then the operating system can easily context switch between them and manage it. However, if the inputs get too high, then the processes bog down because of the overhead of managing all of those processes. In high throughput systems, you generally don't spawn new processes, but instead you have a fixed set of handlers that are tuned to the capacity of your system. When a message is received, it is queued up to be handled on an event queue, then, when a given handler finishes responding to one input, it goes and finds another input off of the event queue and continues working. Each handler just keeps grabbing events whenever the handler has finished its last one. This results in many fewer active processes running and the whole system processing events much faster.

I find the idea of limiting your work-in-progress to be a powerful analogue in personal time management. This is where I think AutoFocus has a distinct advantage, as its dismissal process is very good at really keeping your work in progress low if you allow it to do its job. Similarly, that's why Ivy Lee works well for me, because it lets me limit my work in progress. In that past, and for many people, I think this is something they struggle with in GTD. Technically, GTD includes a WIP limit concept, but it's so "intuitive" that people miss it, and they run the system into the ground because rather than looking at their current huge range of obligations that they clearly have nowhere near enough time to finish and putting a lot of stuff on their backburner (Someday/Maybe) or simply getting rid of it, they try to keep it on their active projects list, and then just get overwhelmed.

I think this is where maybe Mark's systems are a little weaker compared to something like Personal Kanban, which makes this concept really explicit. This is why, IMO, you have so many people talk about their long lists collapsing when they get too big. But, as Mark has pointed out, you have to be willing to embrace dismissal without the negative energy that a lot of people have around it. Some things aren't going to be worked on "immediately" and that's okay. I find that the more I embrace this idea, the more stuff I actually do. I found that a lot of times, my backlogs of work disappear when I switch from not being crisp about my WIP and then getting crisp. All of a sudden, before I know it, my list has shrunk down and things are just done, and all those things I was worried I wouldn't get to are now the only things sitting on my list, ready to be done.

I think a lot of this is universal, but you just have to figure out what systems best let you implement the principles effectively in your life.