Improve estimate subplan weight#

TODO-ngl: Is there a better way to avoid neglect than reminders?#

Is the solution something like “Love” for all the states that you are currently managing? It’s hard to say that anyone really loves their lawn. Or do they? I think it’s harder in a business setting to justify “Love” as being enough. Lawyers run into the same problem trying to make sure developers think about the implications of their products before they release them. What makes this so hard is you have to think about all the things you could possibly care about out in the world (lots of state to consider). Who wants to think about whether the coffee they are making might be too hot for some people who don’t think about that kind of thing? Perhaps we’re simply not caring enough to accept that we should love these people who we think only want money.

The language of “love” is used on this page; you must “love” everyone who “reasonably” could be affected by your actions or omissions:

See also:

This problem is particularly tough because it requires so much common sense. The article on negligence goes into great detail on cause; you have to be able to think about all the effects that will arise out of an action, not just your intend to causes. Said another way, you have to think about side effects. We use functional programming to avoid side effects. See:

In fact, risk mitigation is a major issue involved in releasing major models like GPT-3; it’s hard to anticipate what might happen with its release.

TODO-c: Why convert completed TODo to retrospective TODo (in Training Data)?#

Before removing any TODo, review what the actual weight should have been. Only you understand your own values and can confirm that an action was actually high weight. Are you working with others who have the same values as you or in general getting ideas from the right sources?

To retrospect is an action in itself; you should convert TODo that you’ve completed to retrospective items (or training data) rather than delete them. This is especially important for high-cost actions and actions that you know you’ll do something similar to in the future. Reference class forecasting is about updating your potentially stale priors (if you forget the past) based on data.

Perhaps every time you finish a TODo you should also retro on the time it took you to discover that TODo (the planning overhead associated with it). Otherwise, you’ll never retro on how long it took to plan. Did you spend 10 hours planning to read 2 hours of external material, that completely changed your thinking?

Don’t forget overly ambitious projects (audit, OFDM). For example, is NLP or RL too ambitious?

What if you only write down a plan but then never pursue it? For example, you don’t learn about RNNs because better methods become available. I’d say to convert these to reminder TODo as well; they’ll help you see what kind of learning tasks didn’t end up being valuable as well. Did you learn much from VGT you use now?

Is to retrospect on some TODo (TODo are clearly actions, but of varying size) to generalize it from a single training example into the generalized process you have that is associated with it? It seems like it. All TODo should have similar lifetimes, going from a future/question TODo to a WIP TODo to a retro TODo. Perhaps retro TODo are simply reminder TODo (what you think of as plain old notes, eligible for publication); they’re what you don’t want to forget.

If you are phrasing all TODo as questions, though, you are going to have trouble when you feel you come to answers and begin to talk in statements (will need to convert the question). This is similar to how a hypothesis starts as a question, and ends up as a theory. Even as a theory it is always a “question” in some sense; but we begin to talk in statements as if it’s surely true. When you do this, you lose the connection between the original question (TODO-x) and the “answer” to the question (typically a .md file).

Measuring unimportance#

How do you identify tasks that are actually not important, but still on your list of things to do? For example, tasks that were important because they were focal. You could force yourself to limit your TODo list (the focal git graph) to a certain size. This has the advantage of requiring you to look at a shorter list when you’re deciding what to do next. The primary purpose of this approach is that you’ll be forced to remove items from your list when you aren’t doing them because they are really only important when you are in focused work (in a certain context). This doesn’t mean you won’t do them, only that they aren’t important enough to be your focus. It seems like this is similar to live.md but now your TODo list is dynamically changing as how you live (what is important to you) changes and how your model of how to do it changes. What you already know how to do, for example, is not important to you to relearn.

Use jb labels for TODO#

You often want to use markdown headers with a TODO-xxx so that you can jump to them quickly (with ctags generation). That’s fine to continue to do, but whenever you need a jb-style link between article sections you should also use the todo-xxx for it. This label will persist before and after completion of the task.