4 Comments

Excited to try this. Have one question:

> dot next to item = task done but item stuck in the past (can be collected immediately if rescued)

What does it mean for it to be 'done, but stuck in the past'? (Assuming task is the same thing as item). What's the point of rescuing it if it is done?

Expand full comment

If you did the task, but after it was already in the past, then you don't get to collect it under the straightforward rules. Rescuing it is a way to get to collect it. Make sense? (Sorry for delay)

Expand full comment

This is really cool and I want to try it!

But, confusion/question: when I'm doing work, usually there's a lot of dependencies between past tasks and future tasks such that I can't really skip tasks if I don't get to them in a given hour, I still have to do them in order to move forward. Is your work less full of dependencies like this, or do you use this structure only on days when you want to focus on getting a lot of independent bits of work done, or do you have a way to make this work well even when there are dependencies?

(I guess looking back at your example gameboards it looks like part of the answer is "define the tasks broadly enough to make some of them interchangeable", which I guess I could also do. Curious if you have any other ways of dealing with this.)

Expand full comment

1. If I have n steps in a larger task, I often say 'do a step', so it doesn't matter if they get out of order.

2. Often I'll say something like, 'work on [project] for 10m' or even 'work for 10m'

(Sorry for delay)

Expand full comment