gwern:

I think the standard GTD advice is that you're supposed to be breaking the important tasks down into a lot of little trivial tasks.

jimrandomh:

I have tried that strategy before, and I found it disastrously bad. First, breaking large tasks into small ones, and tweaking the breakdown, is a task itself, which can be used to procrastinate from things that actually need doing. And second, it makes todo lists appear very large, which gave me decision paralysis when it came time to pick something from the list.

Here's a terrific example of how people end up saying they tried things that didn't work, when they aren't actually talking about the same thing that's being suggested.

In this particular case, the way in which tasks are broken down is important. GTD does not say to break a task down into its component parts and add them all to your lists. In fact, ISTR it advising against this, for the very reasons jimrandomh describes.

What GTD advises you is to look at a large task on your "projects" list, and simply write down the NEXT trivial task that needs to be done on it. The breakdown is parallel/incremental, occurring each time you review your projects list or finish a task related to the project, and think of something else to do.

Human beings are rather bad at discussing cognitive algorithms in general - we tend to dramatically simplify our descriptions in ways that make algorithms with significant differences in steps and impact sound "the same".

And I'm quoting both gwern and jimrandomh here because it's not that either of them made a mistake, per se: gwern described the GTD strategy in a way that is incomplete but not false, and neither did jimrandomh make a false statement about GTD; he made a true statement about something that is not GTD.

However, a third party reading this exchange could easily come to the conclusion that they had just read a report of GTD sucking -- and choose not to investigate or evaluate GTD!

This happens with the discussion of almost any method of thinking or organizing: simplified not-false descriptions of technique X are then linked to procedure Y which fits the same description but doesn't work as well, leading to an eventual widespread conclusion among non-insiders of X that X "doesn't work".

When teaching cognitive algorithms, it is important to be precise, since parallel, serial, incremental, etc. algorithms have very different performance characteristics, memory and "hardware" requirements, etc., even when they're run on the human platform.

(Edit to add: Note that this is not a fully general argument for dismissing criticisms of X; it is an argument for making damn sure you reduce X and Y to concretely-defined steps that include all of X's claimed distinctions, before you apply criticism of Y to criticism of X. And the more "popular" X is, the more important it is to do this, because the more popular it is, the more likely you are to have heard only a watered-down version of it.)

Certainly, it's true that a stitch in time saves nine - but knb's problem is not usefully resolved by saying it's a nonproblem.

If he can't get anything important done for the sake of the trivial, that is a very big problem.