Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The problem I experienced with "measuring 'look into'" is that you're not in a position to do so at that moment. "Google 'mend chair leg'" may be a proper task, but it does not capture what to do with it. "Write down best 3 posts" is not something you should commit yourself to before Googling; it's the vague act of "looking into" that generates such actions. You can't tell in advance if you'll need to read blogposts, watch videos, browse a subreddit, etc.

In the end I created my own terms like RESEARCH and BRAINSTORM with well-defined actions attached. RESEARCH means "spend a block of time BFSing on Google until you feel satisfied", while BRAINSTORM means "spend time in front of a whiteboard/piece of paper and dump your problem until you're able to identify specific courses of actions, which then will become your actionable items".

But in the end, I still feel that some problems are not well-suited for GTD - mostly those requiring to improvise as you go along.



Ah, absolutely. I think what's important is recognizing when a task is vague (intentionally or otherwise). It could be "Google 'mend chair leg' for 25 mins and list out next actions', and then those actions become new tasks. I think we're definitely in agreement here.

If there's a misfit between a problem and GTD, the challenge is to figure out how to frame the problem properly.

To zoom out a little- GTD won't create an inspiring work of art, but GTD will manage the artist's schedule, and free her up to read more, meet other artists more, get inspired more, etc.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: