Ted Leung points to two great posts related to aspects of GTD from a programmer's perspective.

Ben Hyde says:

For example he has an interrupt queue. New information is queued up; he calls that the inbox. With reasonable regularity our automaton comes around and drains the interrupt queue. In a software context interrupt processing is very high priority, which means it locks out all kinds of other presumably useful work. To avoid the risk inherent in that lock-out you make a rule that time limits the interrupt queue processing. N units of time per item say.

Oliver Steele says:

GTD can be thought of as a really sophisticated priority queue, and a decision procedure for deciding what to execute immediately and what to place in the queue. Each item in the queue has metadata: whether it has multiple steps, whether it requires additional information, its priority, external deadlines, and the context that the item requires: people, place, time, and energy.

I think it's going to be neat to watch how coders and engineers dissect and remix the basic GTD process outside the limits of manila folders and "@internet" check lists.

Lately, I keep thinking how "next actions" in particular remind me of "Yesterday's Weather" and "You Aren't Gonna Need It" in eXtreme Programming. That idea that you want to stay focused on the very next thing and not get sidetracked by a Big Design Up Front that doesn't account for practical details, your instincts or, uh, reality. (Oddly, it also reminds me of Eisenhower's classic of Project Management: "The plan is nothing: planning is everything.")

Like I said the other day, this is a system that has been heavily refined for the needs of desk jockeys and managerial types. To watch how the basic principles of flow, prioritization, and review get hacked on by nerds should continue to make for fascinating and instructive reading.