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.
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.)
What a nice comment! The next time I feel tempted to describe how GTD solves some problem or other, I’ll wait until the urge passes and message you instead; clearly my one read through Getting Things Done has taught me just enough to be dangerous.
What a nice comment! The next time I feel tempted to describe how GTD solves some problem or other, I’ll wait until the urge passes and message you instead; clearly my one read through Getting Things Done has taught me just enough to be dangerous.
Er, I’m not able to tell if you’re being serious or sarcastic here. But do note that I was just pointing out a systemic problem with talking about cognitive algorithms, not criticizing you OR jimrandomh for attempting to do so. In particular, I didn’t say your statement was false or incorrect, just that it was imprecise enough for somebody else to project a different meaning onto it.
My own experience trying to teach things is that in any one-way communication about cognitive techniques, it is virtually impossible to prevent this kind of projection, because you not only have to state all the distinctions, you also have to explicitly contrast them with whatever people think is the “default”.… and people have different defaults!
The only reliable way to get somebody to really understand something in the domain of experiential behavior, is to get them to actually do that something… which is why I’m so vocal about telling people to try things before they evaluate them, not after.
Anyway, the point was not to be critical of you, since the thing I would be critiquing is literally unavoidable. No matter what you write or say, people can project on it, and a feedback loop in the communication (plus willingness to listen on both sides) is the only way to guarantee a fix for the misunderstandings that result.
I was actually being sincere. I respect the GTD methods (even if I think they’re probably on the complex side), so finding out that my understanding of a fundamental point was wrong was a valuable service.
I did briefly reflect ‘hm, I wonder if this sounds sarcastic?‘, but I passed over it. I wonder what made it sarcastic for you? If I hadn’t used the ‘until the urge passes’ expression? Was it the semicolon and single-paragraph?
I found it difficult to determine whether you were being sarcastic. I think the most reads-as-sarcastic part is the structure of “[In the future,] I’ll [subordinate myself to you]; clearly [I am incompetent].”—and the overall tone is rather gushingly-positive-about-criticism which is a common mode of sarcasm, i.e. “Oh, now that I’ve been told I’m wrong I will, of course, immediately switch over to your view of things.”
A lot of Internet conversations have this problem with detecting sarcasm (or lack of it). Maybe we should start marking sarcastic statements, i.e. with the Lojban discursive je’unai (“commentary on this sentence: it’s false”), pronounced jeh-who-nye.
For example:
Those root canals I had the other day were so much fun! je’unai
The standard GTD advice is that trivial things need to be done and bills need to be paid or you’ll end up without electricity at home, so GTD doesn’t see this as a big problem.
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.
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.
gwern:
jimrandomh:
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.)
What a nice comment! The next time I feel tempted to describe how GTD solves some problem or other, I’ll wait until the urge passes and message you instead; clearly my one read through Getting Things Done has taught me just enough to be dangerous.
Er, I’m not able to tell if you’re being serious or sarcastic here. But do note that I was just pointing out a systemic problem with talking about cognitive algorithms, not criticizing you OR jimrandomh for attempting to do so. In particular, I didn’t say your statement was false or incorrect, just that it was imprecise enough for somebody else to project a different meaning onto it.
My own experience trying to teach things is that in any one-way communication about cognitive techniques, it is virtually impossible to prevent this kind of projection, because you not only have to state all the distinctions, you also have to explicitly contrast them with whatever people think is the “default”.… and people have different defaults!
The only reliable way to get somebody to really understand something in the domain of experiential behavior, is to get them to actually do that something… which is why I’m so vocal about telling people to try things before they evaluate them, not after.
Anyway, the point was not to be critical of you, since the thing I would be critiquing is literally unavoidable. No matter what you write or say, people can project on it, and a feedback loop in the communication (plus willingness to listen on both sides) is the only way to guarantee a fix for the misunderstandings that result.
I’m pretty sure gwern was being sincere.
Interesting, I read his comment as sarcastic.
I was actually being sincere. I respect the GTD methods (even if I think they’re probably on the complex side), so finding out that my understanding of a fundamental point was wrong was a valuable service.
I did briefly reflect ‘hm, I wonder if this sounds sarcastic?‘, but I passed over it. I wonder what made it sarcastic for you? If I hadn’t used the ‘until the urge passes’ expression? Was it the semicolon and single-paragraph?
I found it difficult to determine whether you were being sarcastic. I think the most reads-as-sarcastic part is the structure of “[In the future,] I’ll [subordinate myself to you]; clearly [I am incompetent].”—and the overall tone is rather gushingly-positive-about-criticism which is a common mode of sarcasm, i.e. “Oh, now that I’ve been told I’m wrong I will, of course, immediately switch over to your view of things.”
A lot of Internet conversations have this problem with detecting sarcasm (or lack of it). Maybe we should start marking sarcastic statements, i.e. with the Lojban discursive je’unai (“commentary on this sentence: it’s false”), pronounced jeh-who-nye.
For example:
Those root canals I had the other day were so much fun! je’unai
The standard GTD advice is that trivial things need to be done and bills need to be paid or you’ll end up without electricity at home, so GTD doesn’t see this as a big problem.
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.
I’m not saying it’s a non-problem by any external standard, it’s just that GTD assumes it’s pretty much a non-problem.