notes on prioritizing tasks & cognition-threads

post by Emrik (Emrik North) · 2024-11-26T00:28:03.400Z · LW · GW · 1 comments

Contents

  incomplete list of especially branch-cutty checks in my prioritization-checklist[2]
    do limiting-case analysis (LCA):  assume the best-case scenario for the task-result, then compare its expected Δutility coto the task's counterfactual.
    IF:  the task is an information-gathering or thinking-task,THEN:  heurestimate VoI bon Δbehavior.
    visualize the counterfactual branch-coverage of the task-product across all plausible future branches of u's own path, and whatever causal targets u aim u's task-product at
  as an example, consider the branch of keyboard-optimizations
  ⚠ prioritization & planning is unnatural & unfun, and will inevitably be dominated by myopic habits-of-thought by default
None
1 comment

...tfw^[1] a top promising-looking plan wic wud hv been post-empted by future events if we had pursued it, is pre-empted ind, bc we carefwly plan it out in advance and find the inevitable crux bfr we even begin.

phew!  dodged a bullet I might've otherwise had to bite. 😌

the frequency of events like this is one of the main ways we intuitively track & sanity-check our progress wrt our prioritization-framework.  it's rly hard to verify if our chosen course is any *good*, but it's much easier to verify that the plan we wud hv prioritized (if not for framework) is any *terrible*.

if we increasingly cut branches we were otherwise tempted to pursue,  and that isn't explained by just having sampled more plans or from a different distribution, then it has to be the result of us getting better at finding their flaws (or better alternatives).  either way, even if it's just the sampling-more one, it's a fairly reliable metric for concentrating possible selves into better strategic branches.

succinctly:

track u's speed to victory bon the rate of branches u cut (feasible-to-verify via inside-model consistency), not bon the weight of considerations ifo the one u climb (infeasible-to-verify bc outside-model uncertainty).

---

if I compare myself_now vs myself_4-months-ago, I subjectively notice finding solid reasons to cut tasks (or cognition-threads) fm my tasklist (or cognition-stack) much faster per cut, and w greater frequency of cuts.  I now sorta know the questions to ask, and the intangible haze of "uhh mby it seems good to do? who knows, I shud keep it in there jic" is more quickly dispelled.

incomplete list of especially branch-cutty checks in my prioritization-checklist^[2]

• stack-trace the causality that led u to consider the task itfp
  • especially check the motivations that led u to want consider it;  j bc those is especially fast to check.
  • but also check the events that caused u's info abt the task itfp.
  • why is this important?  smth smth the bottom-line [? · GW].  u's decisions is only ever as wise as the processes that aly caused u to decide those things as opposed to all other possible things u cud decide.  most of u's options is pre-filtered bfr u can filter it ato u's own criteria.

• do limiting-case analysis (LCA):  assume the best-case scenario for the task-result, then compare its expected Δutility coto the task's counterfactual.

  • obviously also aly consider the counterfactual, otherwise u j isn't doing prioritization... (tip: u is doing smth else ind—find out what brain is implicitly doing and mby do it deliberately ind.)
  • preferentially select a concrete task as u's counterfactual, so u not j compare ast u's vague default prior all the time.  u prune & learn more effectively w concrete comparisons.  iow, ind "shud I do A or not-A?", ask "shud I do A or B?" 

• IF:  the task is an information-gathering or thinking-task,
  THEN:  heurestimate VoI bon Δbehavior.

  • bc Δbehavior is mby the most [general * quick-to-estimate * reliable] proxy for VoI, imex.  if information is usefwl, it necessarily implies Δbehavior, but not vice versa.  (u can only change the world "with these two hands...")

• visualize the counterfactual branch-coverage of the task-product across all plausible future branches of u's own path, and whatever causal targets u aim u's task-product at

  • 🛈 I used to call this the "Ahmdal ratio", bon:
    • > "the overall performance improvement gained by optimizing a single part of a system is limited by the fraction of time that the improved part is actually used."
  • itco a learning-task, I call this the LuBraCov ("learning--branch-coverage").
    • if I'm considering learning smth that I wud be learning anyway in future (eg via parallel exposure), then that task has short-lived counterfactual LuBraCov (ie, effort spent learning it will be post-empted / redundant'ifyd by future events).
  • itco a production-like task, I call it the TaProdBraCov ("task-product--branch-coverage").
    • one feature I find helpfwl to check wrt TaProdBraCov is to ask how "twiggy" it is.  ico evobio, a "twiggy" evolutionary tree is one w many short-lived heritage-branches / extinction-events,  st depth-first search reqs many false-starts to find the surviving lineage.  this is supposed to be a consideration ifo doing breadth-first-like search ind (ie ensure u carefwly track priority-inheritance (back-propagating) wrt higher-level strategic proxys), but also j ifo cutting it itfp.
    • I notice this especially when I feel tempted to tweak various scripts related to my routines.  I tend to vastly overestimate how much I'll carry those tweaks w me in future, and often later find them redundant.  iow, the scripting-branch is twiggy.
      • we often ask:  "is this something we'll carry with us across higher ascension-levels?"
        • (and then do an iconic little gesture of slinging a backpack over our shoulders, for dramatic effect & post-cue-strengthening. ^^)
      • iow... we only bother w potential self-improvements w expected utilization-density over branches that assume we will succeed, bc there's ~zero utility to TaProds exclusively utilized in branches that were too unambitious to possibly succeed anyway.
  • 🛈 tip: when projecting outward the expected utilization-density of u's potential task-product, is an especially convenient time to be checking for alloconvergent subpaths (overlaps btn independentish subpaths) btn dify plausible rollouts of u's higher-level strategy(s).  those subpaths get extra priority-weight ato the assumption-independence of the rollouts.

as an example, consider the branch of keyboard-optimizations

• hmm, it's got universal TaProdBraCov, bc all the branches where I save the world are guaranteed to be ones where I depend on my keyboard for it.
• it's even got decent Δbehavior across that BraCov—several times per waking minute even!
• ...yet it is w great sadness in my heart to report that tasks in this branch still utterly fail to produce Δutility worth mentioning, bc the counterfactual margin of utility across all the branches covered is still negligible.
  
  zooming in on the TaProdBraCov, I can see the seconds saved and the trivial-annoyances dodged don't sum up to sufficient Δ time-saved or motivation-preserved.
  
  (I've still got a Glove80 split-keyboard dusting away in storage,  and a great many excited plans for what to do w it, all consigned to 'Task-Archive Level 3' where youth-addled dreams go to die.  Thank goodness!)

⚠ prioritization & planning is unnatural & unfun, and will inevitably be dominated by myopic habits-of-thought by default

so most of the checks in my prioritization-checklist are about preserving/cultivating motivation for excitedly adhering to the framework itfp.

eg, consider the Tarski-frameshift ioto de-prejudice uself bfr doing a prioritization wic feels forced (so u brain not lurn to associate checklist as a chore):

"if reasons favor doing A, I want to do A; if they favor B, I want to do B.  let me not presume either temptation unfounded."

I don't recommend forcing uself to spend big effort prioritizing/planning, unless u hv way of counterbalancing the inevitable aversion-buildup due to subgoal-hastening--bias [LW(p) · GW(p)].^[3]

ind, mby practice prioritization in the rarer opportunitys u get where u can feel excited abt it, so the ratio of excitement/aversion generated by all context-instances stays above the heritage-threshold^[4] for growing over time.  my self-word for this is "peak-selection".

1. ^{^}

   tip:  see the glossary of acronyms & abbreviations in the side-comment.  can press  Opt/Alt + Shift + J  to sticky.

2. ^{^}

   when optimizing a checklist purely bon usefwlness for uself, it v dify coto how impressive it looks to others.  often the most pivotal checks can be embarrassingly mundane, like a simple "did you check your assumptions?" asked in the right context.  obviously no reader will be unfamiliar w the idea that u shud cek u's assumptions, so u wudn't think to put it in there if u j focused on producing smth-for-others-to-consume.

   or, "how could I have thought that faster?" and "which thoughts was that faster than?"

   also note:  our main purpose of this framework is for learning to prioritize parts-of-cognition itself.  eg when we're considering whether to go meta or mesa wrt sm abstract question we're pondering;  or when we're evaluating whether to do cost-benefit analysis on spending marginal time thinking abt smth.  ...this quickly escalates to infinite time spent on metacognition, obviously, but only during the learning-period until metacognitive checks are intuitive enuf that the cost in metacognitive overhead is manageable.

3. ^{^}

   eg, how if I'm tryna change out a finicky lightbulb in the ceiling just within my reach, I might spend a solid minute balancing uncomfortably on my tippy-toes ind spend the 7 secs it takes to fetch a chair—even if fetching the chair wud reduce total time spent as well.

   intuitive-brain is j massively biased ast introducing extra steps btn steps in an already-calculated path, and later-calculated opportunitys to reduce projected ∑costs rarely budge it.

4. ^{^}

   "heritage-threshold" is a better frame for the inverse of the mutational error-threshold and all its innumerable equivalents.

1 comments

Comments sorted by top scores.