2 ms·

I agree with much of this, but after my own experience of GTD and watching some friends try it, I think it's poorly suited for intellectual work. Even though it

by KingMob 10y ago

I agree with much of this, but after my own experience of GTD and watching some friends try it, I think it's poorly suited for intellectual work. Even though it talks about the 10,000 ft/20,000 ft/etc view, I think it just pays lip service to higher-level planning. What I noticed were lots of people chasing microscopic tasks and checking off to-do lists instead of taking care of the big things that make a difference. But maybe it's just me. Another poster mentioned Cal Newport's "deep work", which seems a more natural fit for coding to me. I'm not saying GTD can't work for you, YMMV, but I think it's a better fit for more traditional office work.

Jtsummers 10y ago
I can see that. GTD works for me, but I also don't try to use it to drill down deep into every project. I have used it to, say, map out learning a language using specific resources a couple times. Like, with Rust, I put in that I wanted to go through The Rust Book. I created a project with the book's title and a link to it in an org file. I created subheadings and turned them into TODOs for each chapter. Since I use org for literate programming, I included every example in this file along with my own exploration and toying with the language. But an actual programming project won't be done that way. At most, from a GTD perspective, I note that I want to create a CLI TOTP implementation in Rust (as an exercise project). I'll capture it at a high level so I don't create too many projects (an unfortunate habit) and not finish it. So in my GTD list of projects I'll see that I'm working on "CLI TOTP in Rust", but no more details. The details for that go into a literate programming org-mode file that drills into the details of what needs to be done. Somewhat GTD-style, but the tasks here never make it into my overall GTD action queue or schedule. Basically, my system is an amalgam of what works for me at different levels. Dogma is rarely useful, in my experience. Flexibility and appropriation of tools from everyone else. Experiment, recognize failed experiments, latch onto personal successes, and explain what worked or didn't for me to others to help them do the same.

by KingMob 10y ago

Jtsummers 10y ago

I can see that. GTD works for me, but I also don't try to use it to drill down deep into every project. I have used it to, say, map out learning a language using specific resources a couple times. Like, with Rust, I put in that I wanted to go through The Rust Book. I created a project with the book's title and a link to it in an org file. I created subheadings and turned them into TODOs for each chapter. Since I use org for literate programming, I included every example in this file along with my own exploration and toying with the language. But an actual programming project won't be done that way. At most, from a GTD perspective, I note that I want to create a CLI TOTP implementation in Rust (as an exercise project). I'll capture it at a high level so I don't create too many projects (an unfortunate habit) and not finish it. So in my GTD list of projects I'll see that I'm working on "CLI TOTP in Rust", but no more details. The details for that go into a literate programming org-mode file that drills into the details of what needs to be done. Somewhat GTD-style, but the tasks here never make it into my overall GTD action queue or schedule. Basically, my system is an amalgam of what works for me at different levels. Dogma is rarely useful, in my experience. Flexibility and appropriation of tools from everyone else. Experiment, recognize failed experiments, latch onto personal successes, and explain what worked or didn't for me to others to help them do the same.