The good news is there's not really a way to "get the system wrong" if you've paid any attention at all. You might not do it straight by the book, but if you are indeed GTD, then don't sweat it.

As to how you can get through that pile of books. Reading and self-improvement is one of those things that's hard to place in a GTD system. What I would recommend is setting a goal for how fast to get through the pile. Then figure out how fast you need to finish a book to stay on pace. Read quickly the first go.* The progress you are making would need to be an aspect of your weekly review.

The day-to-day grinding through the material is tougher. Many people find it helpful to make appointments with themselves, i.e. put the reading time on calendar and keep that appointment just like any other meeting.

You mention that you are a programmer, so I have some suggestions in that regard as well. In learning a new language or concept, I find it's more helpful to me if I have a project in mind that I plan to use the new concept or technology for. It's hard for me to stay motivated if I don't have some personal stake in it. So, if you're learning Cocoa programming it would be helpful to brainstorm what you envision your first app or plugin or tool doing and work through the material with that in mind. ( This helps me just because I can't motivate myself very well for this-will-be-useful-someday tasks.) It also helps with motivation if you can set a very near deadline for this. Announce that new app on your blog. Post mock-up screenshots. When I buckle down to learn Cocoa programming, it's because I have an idea for a Mail plugin. When I'm serious about doing it, I will announce the plugin on my website, Twitter, Jaiku, and anywhere else I have people watching. I'll even announce a target completion date to put the pressure on. (A very real threat - particularly the threat of shame - is the single greatest motivator. See this story from Primetime.) For me, that threat would be looking like a hack to people I respect in the Mac OS X programming community.

Anyway, those are my thoughts. I could write a lot more about it, but I don't want to belabor the point here. Post back or PM me if you wanna talk more.

*This recommendation is based on the 80/20 rule. You will learn 80% of the material (maybe even 90%) in 20% of the time you spend on it and then the remaining 20% is likely to take a significantly longer time. Gruber and Dan Benjamin talked about this rule in relation to photography in Ep03 of The Talk Show.

In some ways, GTD is not a good match for what you want to do. GTD is very goal- and action-oriented, and you don't seem to be really goal-oriented in your reading.

But, then again, maybe you're not reading because you don't have a goal. Is it possible that you put off your reading because there's a voice in the back of your head saying "what's the point of all this?" That would be a typical cause of procrastination.

So, perhaps your best bet is to create a project that somehow matches with your self-improvement goals. I mean, nobody really learns programming by reading a book in abstract; you need to actually write a program! So, go and do it. Pick some goal like "I'm going to rewrite my foo program, but I'm going to write it without buffer overflows... and to do that I need to read these books!" or "I'm going to rewrite the baz Web site in Django... and to do that I need to start by reading these other books!"

If it's a project, then you can have goals, and you can be sure you've learned in the end.

Alternatively, I find a good way to ensure that I read books that are for my general education, but not immediately applicable, is to put them by the toilet.

I'll just add to the great thoughts from others.

Reading and GTD: It works fine. Treat each book as a project, with the next action being an arbitrary chunk. Read the next 20 pages, read the next section or chapter, etc. If you want to be moving ahead on different books simultaneously, make each one a separate project, with separate "state."

If you're not sure which books or which parts, spend some time getting clearer about your goals (as others have suggested). Having a programming project in mind (even a toy one) is a good way to frame and cement what you learn.

I have a very large stack of books I'm working through. I found Steve Leveen's ideas particularly helpful. More at:

A reading workflow based on Leveen's "Little Guide"
http://ideamatt.blogspot.com/2007/03/reading-workflow-based-on-leveens.html

How to read a lot of books in a short time
http://ideamatt.blogspot.com/2006/02/how-to-read-lot-of-books-in-short-time.html

Skip the book. Read this Getting Started ... post instead, do some googling and get started. Read the book later. If at all.

*Ducks*

Douggiefox,

Just wanted to post a quick note to tell you to not worry about screwing up with GTD. Get a system set up to try it. After a while (a couple weeks, maybe), reevaluate how it's working and how you might tweak it.

But allow me to share some advice, so that you can learn from my failure: make sure that a regular review of projects and next-actions is part of yoru process. During this review you can reorganize actions, and whatnot, but it's the GTD activity that keeps you moving forward and being productive.

My last thought on this is that as you work your way through your readying, you will want to revise your next-actions to reflect the new perspective you get on each of your projects through reading and reflecting on what you're learning. As I've thought about using GTD in academics, I think this means that you need to more frequently review your reading and learning projects than one might review a "cranking widgets" project.

This is my $0.02. In closing, you might find that skimming the "GTD for acacdemics" thread/sub-forum interesting.

Jason