GTD is a great systematic approach for getting on top of your world. Being a systematic approach also means it is general enough to cause confusion (i.e: not be clear) and to be applied to virtually any aspect of life, and that includes any particular needs you might have.
GTD works on top of 3 models. The first one, called the Mastering Workflow is the best known, and the essence of David Allen’s first book. You’ll surely remember the Collect, Process, Organize, Review, Do steps.
The second model is the Natural Planning model – it’s basically used to clarify amorphous data into clear next actions (as wel as finding out why you are doing it at the first place).
The third model is what David calls “Horizons of Focus”, and defines the different levels — or horizons — on which we need to focus in order to get a good perspective about our world.
Anyway, the point of this article is not to teach you GTD. It is deep enough to require a book of its own 
(Check out the Getting Things Done and or Making It All Work books).
When developing software, we are bombarded by a constant flow data, this comes from different sources:
* Our our mind triggers it;
* Someone else asks us to do it;
Most of the time, this data is amorphous, sometimes it doesn’t even have clear goals. Not a good day to be a software developer uh?
Well, whenever you have to deal with that, you need to quickly capture. Try not to get out of the context you are. Capture it and trust that you will deal with that later. If you judge the task will only a quick while and that it is clear enough and you are not doing something already, do it. Any other notes you might have during the time you are doing the task, just take note (capture it) and forget about it for the time being.
David talks about cranking widgets. He says that there is always a set of very clear and “physical” actions that you can break down from any unclear task.
The thing is: Defining the “widgets” is very subjective. But the good news is that you just have to break it down until it has enough information in it and makes sense to you.
For example:
* System should deal with ARB requests
Is definetly too high-level. You will break your head a little bit and it will cause you anxiety if you just keep it like that. It doesn’t matter if tell me Cucumber will save your life. You will eventually finish the task, but it will take much more mental energy. So, start breaking it down:
* System should deal with ARB requests
** Create the system_should_deal_with_arb_request.feature feature file on feature/
** Write the story on the feature, check with Tommy
** Brainstorm about the scenarios, 25 minutes timebox.
Now, this is the part I told is subjective (and this is the main poin tof this post), and depends on the person. Know what ? Just put whatever you feel you need to remember. These are reminders, after all. Just try to be clear enough for your own understanding.
(You can see that most of the time, not everything will be clear, and a reminder to process something even more will be very helpful, such as brainstorm about scenarios. The point is to extend your mind and let you know what you need to do, you don’t have to clarify everything upfront, that would be crazy, and you would probably be following something akin to the watefal development methodology).
Then, to decide what’s is the next action, you can judge by time, priority, energy, and context. You can start the day looking your GTD next-actions list and decide, depending on your current circunstances, what is the best next choice. You might decide you don’t have enough information, and that’s ok, just plan on it, but be sure to set up any needed reminders for next-actions or new projects/sub-projects that might appear.
You might even modify the /delete the todo-list, or change the order, you are the judge. Be flexible, be pragmatic, GTD is a systematic approach and not a defined system. You have the whole inventory in front of you, and if you trust it (which takes some time) you will free up much more energy to actually execute.
