In this post, I describe an approach I’ve been following for the past
few months, and that I feel has been moderately helpful to me:
trigger-based rapid checklists. A trigger-based rapid checklist is a
memorized checklist that I execute rapidly in response to a specific
trigger. I’ll explain with examples, and then talk of some of the
general features.
Although this wasn’t directly inspired by any specific life hack that
others use, it has some overlap with trigger-action
planning as
well as with the ideas popularized by Getting Things
Done.
This post should not be taken as a documentation of the exact details
of what I do—I’ve left out some details and made some tweaks for
simplicity. The information here should be thought of as mostly
illustrative of how somebody might use trigger-based rapid checklists.
Examples of trigger-based rapid checklists
Some triggers
I currently have several trigger-based rapid checklists. Here is a
list (not necessarily comprehensive):
Morning checklist: I execute this after I start using my laptop in
the morning.
Night checklist: I execute this right before I plan to close my
laptop in the evening (this is not right before I go to sleep).
Pre-outside trip checklist: I execute this right before leaving my
home for an extended period of time (e.g., for shopping).
Post-outside trip checklist: I execute this right after returning
from an outside trip.
Context switch checklist: I execute this when I’m switching context
between different kinds of work.
Sample checklists
Here is a lightly-edited version of my morning checklist:
- [ ] (D) Daily update -- review yesterday's daily updates (both personal and work) for any omissions
- [ ] (W) Check the weather for the day
- [ ] (E) Catch up on email: personal and work
- Also check spam, trash, and all mail (I won't check these for each intermediate check during the day)
- [ ] (M) Catch up on Facebook messages
- [ ] (S) Catch up on Slack: personal and work
- [ ] (C) Check calendar to plan my day
- [ ] (A) Turn off alarm
- [ ] (L) Run the loose ends script
And here’s a lightly-edited version of my night checklist:
- [ ] (D) Daily update -- review today's daily updates (both personal and work) for any omissions
- [ ] (W) Check the weather for the next 1-2 days
- [ ] (E) Catch up on email: personal and work
- [ ] (M) Catch up on Facebook messages
- [ ] (S) Catch up on Slack: personal and work
- [ ] (C) Check calendar for the next 3 days:
- For next day, pay particular attention to implications regarding e.g., when to wake up; in particular, try to make it so that I go to sleep at least 9 hours before the time of the first appointment
- For the two days after that, make sure that the calendar makes sense, e.g., I didn't mark an incorrect event; if there are things that need to be in sync across multiple calendars (e.g., across two jobs while I'm juggling them), make sure they are in sync
- [ ] (A) Turn alarm on for tomorrow
- The default alarm setting is 8:30 AM; this is fine for most days (I am usually awake well before this time -- the alarm is a fallback measure)
- I should make sure that the alarm time is early enough to be at least 1 hour before any online meeting, and a larger amount of time for other kinds of events
- Also use this occasion to make sure that the phone is plugged in and (charging or charged)
- [ ] (W) Make sure bedroom window and hall terrace door are open
- [ ] (L) Run the loose ends script
- [ ] (C) Close lid and cover laptop
Important features of execution of the checklists
Trigger-based nature
These checklists are trigger-based rather than time-based. In
general, I’ve found time-based things hard to adhere to, since there
can be many sources of variation such as when I wake up or when I go
to sleep. Trigger-based actions are easier to remember, because I just
have to build in my mind the association from the trigger to the
action. The LessWrong trigger-action planning
tag has a
bunch of great content explaining why trigger-action planning works in
general.
Written down, but memorized so I usually don’t need to reference the written version
Although I have canonical written versions for each checklist, I
memorize all of them to the point that I don’t usually need to
reference the written checklist when executing it. I may sometimes run
a spot-check against the written version of the checklist, but most of
the times I don’t look at it.
The purpose of having a written version is for it to serve as a
canonical reference, and also for it to reflect updates to my
practice. When I decide I’ll start or stop doing something, I
respectively add it to, or remove it from, the written checklist.
On the other hand, needing to reference the written checklist gets in
the way of the “rapid” portion of things, so I try to memorize the
checklist.
So far I’ve found it useful to use mnemonics to memorize the
checklist. To do this, I pick a letter for each checklist item from
which I can expand out the full checklist item. Then I try to arrange
the checklist so that the letters come together nicely to form a good
mnemonic. In the sample checklists I pasted above, I’ve included the
selected letter for each checklist item in parentheses.
For the morning checklist, the selected letters form the work
DWEMSCAL, which doesn’t roll too freely off the tongue, but is not too
hard to remember. So every morning, when I open my laptop, I remember
“DWEMSCAL”, then start executing the expansions of each letter.
Time taken to achieve full memorization
It generally takes me about 5-20 iterations to fully internalize the
execution of a trigger-based checklist. If a checklist is executed
about once a week, this translates to about 5-20 days, or about 1-3
weeks.
The first part to internalize is the act of identifying the trigger
and thinking “oh, there’s a checklist associated with this trigger!”
Once that’s achieved, even if I don’t remember all the items in the
checklist, I know that there’s a checklist and can look it up.
For every incremental update to a checklist (e.g., the addition of a
new item to the checklist), it can take me between 5-20 iterations to
internalize the new item as part of the checklist. If the checklist is
executed about once a day, this translates to about 5-20 days, or
about 1-3 weeks.
Order-independence: for the most part, the order within a checklist doesn’t matter
When I’m executing a trigger-based rapid checklist, I might not do it
in the right order; for instance, I initially forget a step and then
remember it after executing later steps. Or there’s some reason I want
to defer executing a step till later.
Fortunately, for most of the rapid checklists, the order of the items
within the checklist doesn’t matter much, beyond some very obvious
dependencies (for instance, closing the laptop lid has to be after
various steps that depend on the laptop). This means that I can
execute the checklist much more rapidly, without worrying about
getting things in the wrong order. This is in contrast with checklists
related to complex technical things where there are dependencies
between the steps.
No physical (or digital) checking of boxes
Since I’m interested in rapid execution, I’m willing to trade off
recordkeeping to some extent. So I don’t actually check any boxes
anywhere (physically or digitally) as I execute checklist items.
Since many of the items are computer-based, I usually can look at
records of various sorts (browsing history, terminal history) if my
attention wavers and I want to double-check if I executed a step.
The fact that the order of items within the checklist doesn’t matter
too much is helpful here—it reduces the pressure to get through
each checklist item in sequence and to be sure that each item is
executed.
Checklist redundancy
Given the rapidity of execution, there’s some risk that I’ll (a)
forget to execute a checklist entirely, or (b) miss executing an item
from the checklist. I’ve built the checklists in a way that there’s
significant redundancy between checklists, so I’d need to miss
something many times before it actually becomes an issue.
For instance, every night I check the weather for the next day, and
then again in the morning I check the weather. Both checks are
valuable: the night-time check could inform my plans for the next day,
including when I wake up. The morning check is helpful for refining
plans, as the weather forecast made in the morning tends to be more
accurate than the weather forecast made overnight.
However, the redundancy between the two reduces the chance that I’ll
be completely unaware of any impending major weather development. (In
fact, I also have a weather check in my pre-outside trip checklist,
which offers a third layer of redundancy).
Detours during checklist execution
Sometimes when I’m executing the morning checklist or night checklist,
one of the checklist items leads to a detour. For instance, when I get
to (E) (email), I might end up replying to or processing some incoming
emails.
The key is to allow for such detours, but still mentally be in
“checklist mode” so that when the detour is finished, I return to
checklist execution.
For some checklists, such as the morning checklist, I have set time
limit guidelines (ranging from 45 minutes to 1 hour). For others, no
time limit is necessary, because the very nature of the checklist is
to gate specific other tasks. For instance, if I take a detour during
the night checklist, then I just end up going to sleep later, because
I’m not going to close my laptop until the rest of the night
checklist is done.
Dealing with forgetting
I have each checklist stored in a separate document. In the document,
below the checklist, I record various notes, including notes on
forgetting the checklist execution or forgetting specific
steps. Documenting this helps me observe what I’m missing and why, and
helps me focus on being more reliable on those fronts. In practice,
for me such notes are fairly rare—less than 2 per checklist per
month.
Purpose of checklist items
Enforcing some cadence on things I need to check on regularly
For some of the items, such as checking email, messages, and Slack, I
include them in my morning and night checklist (as well as other
checklists such as my pre-outside trip checklist and pre-meal
checklist). This enforces that I do them reasonably regularly, without
forcing specific times when I do the checks.
In the past, I did check various things like email, messages, and
Slack reasonably regularly, but there would often be large random
gaps; for instance, there was once a gap of about 1.5 days when I
didn’t check my personal email, and there were times when I didn’t
clear out some Slack messages.
For some checks, I don’t need to do them that regularly, so I enforce
a less frequent cadence. For instance, checking my spam, trash, and
all mail is something I have in my morning checklist but not in any of
my other checklists. Prior to explicitly adding them to my checklists,
I often didn’t check my spam, trash, and all mail for several
weeks. Spam and trash emails get deleted every 30 days, so enforcing
some cadence that’s more frequent than 30 days helps make sure that I
don’t miss such emails.
Reducing the risk of escalation, particularly at inconvenient times
Things like email, messages, and Slack often include early warnings of
things that could blow up into emergencies if not responded to in
time. It’s particularly inconvenient if these escalations happen at
bad times such as when I’m sleeping or when I’m not at home. I reduce
this risk by checking my email, messages, and Slack right before going
to sleep or going outside the home.
Getting timely and decision-relevant information
Checking the weather forecast regularly is valuable because
information about future weather can inform my plan and
schedule. Similarly, checking the calendar regularly gives me
information on how to schedule my time the next day.
Recording stuff before I forget
The checklist item (in both my morning checklist and my night
checklist) to review and update my daily update is an example. See my
post The why and how of daily
updates
for general background on my use of daily updates.
Setting relevant stuff up
For instance, opening the windows helps with ventilation; setting the
alarm clock creates a fallback way for me to make sure I wake up on
time.
Being prepared for failure or extended unavailablity
Every time I close for the day, I want to be in a “clean state” as
much as possible—everything I do has been committed and backed up,
so that if my laptop crashes and doesn’t recover the next day, I
haven’t lost any of my work. For instance:
The loose ends script that I run every night and every morning (as
well as before outside trips) is to make sure that various things on
my laptop have been backed up remotely and cleaned up (primarily, it
checks that all my git repositories are in clean state).
Every night, I close my laptop lid. This reduces the risk of dust on
the laptop, but the main reason is to reduce the risk of damage to
the laptop that might arise from any accident.
Annotating my night checklist with the purposes served by each checklist item
Here’s a revisit of my night checklist, with the inclusion of
purpose for each checklist item.
- [ ] (D) Daily update -- review today's daily updates (both personal and work) for any omissions
- Purpose: Recording stuff before I forget
- [ ] (W) Check the weather for the next 1-2 days
- Purpose: Getting timely and decision-relevant information
- [ ] (E) Catch up on email: personal and work
- Purpose: Enforcing some cadence on things I need to check on regularly
- Purpose: Reducing the risk of escalation, particularly at inconvenient times
- [ ] (M) Catch up on Facebook messages
- Purpose: Enforcing some cadence on things I need to check on regularly
- Purpose: Reducing the risk of escalation, particularly at inconvenient times
- [ ] (S) Catch up on Slack: personal and work
- Purpose: Enforcing some cadence on things I need to check on regularly
- Purpose: Reducing the risk of escalation, particularly at inconvenient times
- [ ] (C) Check calendar for the next 3 days
- Purpose: Getting timely and decision-relevant information
- [ ] (A) Turn alarm on for tomorrow
- Purpose: Setting relevant stuff up
- [ ] (W) Make sure bedroom window and hall terrace door are open
- Purpose: Setting relevant stuff up
- [ ] (L) Run the loose ends script
- Purpose: Being prepared for failure or extended unavailability
- [ ] (C) Close lid and cover laptop
- Purpose: Being prepared for failure or extended unavailability
Trigger-based rapid checklists
In this post, I describe an approach I’ve been following for the past few months, and that I feel has been moderately helpful to me: trigger-based rapid checklists. A trigger-based rapid checklist is a memorized checklist that I execute rapidly in response to a specific trigger. I’ll explain with examples, and then talk of some of the general features.
Although this wasn’t directly inspired by any specific life hack that others use, it has some overlap with trigger-action planning as well as with the ideas popularized by Getting Things Done.
This post should not be taken as a documentation of the exact details of what I do—I’ve left out some details and made some tweaks for simplicity. The information here should be thought of as mostly illustrative of how somebody might use trigger-based rapid checklists.
Examples of trigger-based rapid checklists
Some triggers
I currently have several trigger-based rapid checklists. Here is a list (not necessarily comprehensive):
Morning checklist: I execute this after I start using my laptop in the morning.
Night checklist: I execute this right before I plan to close my laptop in the evening (this is not right before I go to sleep).
Pre-outside trip checklist: I execute this right before leaving my home for an extended period of time (e.g., for shopping).
Post-outside trip checklist: I execute this right after returning from an outside trip.
Context switch checklist: I execute this when I’m switching context between different kinds of work.
Sample checklists
Here is a lightly-edited version of my morning checklist:
And here’s a lightly-edited version of my night checklist:
Important features of execution of the checklists
Trigger-based nature
These checklists are trigger-based rather than time-based. In general, I’ve found time-based things hard to adhere to, since there can be many sources of variation such as when I wake up or when I go to sleep. Trigger-based actions are easier to remember, because I just have to build in my mind the association from the trigger to the action. The LessWrong trigger-action planning tag has a bunch of great content explaining why trigger-action planning works in general.
Written down, but memorized so I usually don’t need to reference the written version
Although I have canonical written versions for each checklist, I memorize all of them to the point that I don’t usually need to reference the written checklist when executing it. I may sometimes run a spot-check against the written version of the checklist, but most of the times I don’t look at it.
The purpose of having a written version is for it to serve as a canonical reference, and also for it to reflect updates to my practice. When I decide I’ll start or stop doing something, I respectively add it to, or remove it from, the written checklist.
On the other hand, needing to reference the written checklist gets in the way of the “rapid” portion of things, so I try to memorize the checklist.
So far I’ve found it useful to use mnemonics to memorize the checklist. To do this, I pick a letter for each checklist item from which I can expand out the full checklist item. Then I try to arrange the checklist so that the letters come together nicely to form a good mnemonic. In the sample checklists I pasted above, I’ve included the selected letter for each checklist item in parentheses.
For the morning checklist, the selected letters form the work DWEMSCAL, which doesn’t roll too freely off the tongue, but is not too hard to remember. So every morning, when I open my laptop, I remember “DWEMSCAL”, then start executing the expansions of each letter.
Time taken to achieve full memorization
It generally takes me about 5-20 iterations to fully internalize the execution of a trigger-based checklist. If a checklist is executed about once a week, this translates to about 5-20 days, or about 1-3 weeks.
The first part to internalize is the act of identifying the trigger and thinking “oh, there’s a checklist associated with this trigger!” Once that’s achieved, even if I don’t remember all the items in the checklist, I know that there’s a checklist and can look it up.
For every incremental update to a checklist (e.g., the addition of a new item to the checklist), it can take me between 5-20 iterations to internalize the new item as part of the checklist. If the checklist is executed about once a day, this translates to about 5-20 days, or about 1-3 weeks.
Order-independence: for the most part, the order within a checklist doesn’t matter
When I’m executing a trigger-based rapid checklist, I might not do it in the right order; for instance, I initially forget a step and then remember it after executing later steps. Or there’s some reason I want to defer executing a step till later.
Fortunately, for most of the rapid checklists, the order of the items within the checklist doesn’t matter much, beyond some very obvious dependencies (for instance, closing the laptop lid has to be after various steps that depend on the laptop). This means that I can execute the checklist much more rapidly, without worrying about getting things in the wrong order. This is in contrast with checklists related to complex technical things where there are dependencies between the steps.
No physical (or digital) checking of boxes
Since I’m interested in rapid execution, I’m willing to trade off recordkeeping to some extent. So I don’t actually check any boxes anywhere (physically or digitally) as I execute checklist items.
Since many of the items are computer-based, I usually can look at records of various sorts (browsing history, terminal history) if my attention wavers and I want to double-check if I executed a step.
The fact that the order of items within the checklist doesn’t matter too much is helpful here—it reduces the pressure to get through each checklist item in sequence and to be sure that each item is executed.
Checklist redundancy
Given the rapidity of execution, there’s some risk that I’ll (a) forget to execute a checklist entirely, or (b) miss executing an item from the checklist. I’ve built the checklists in a way that there’s significant redundancy between checklists, so I’d need to miss something many times before it actually becomes an issue.
For instance, every night I check the weather for the next day, and then again in the morning I check the weather. Both checks are valuable: the night-time check could inform my plans for the next day, including when I wake up. The morning check is helpful for refining plans, as the weather forecast made in the morning tends to be more accurate than the weather forecast made overnight.
However, the redundancy between the two reduces the chance that I’ll be completely unaware of any impending major weather development. (In fact, I also have a weather check in my pre-outside trip checklist, which offers a third layer of redundancy).
Detours during checklist execution
Sometimes when I’m executing the morning checklist or night checklist, one of the checklist items leads to a detour. For instance, when I get to (E) (email), I might end up replying to or processing some incoming emails.
The key is to allow for such detours, but still mentally be in “checklist mode” so that when the detour is finished, I return to checklist execution.
For some checklists, such as the morning checklist, I have set time limit guidelines (ranging from 45 minutes to 1 hour). For others, no time limit is necessary, because the very nature of the checklist is to gate specific other tasks. For instance, if I take a detour during the night checklist, then I just end up going to sleep later, because I’m not going to close my laptop until the rest of the night checklist is done.
Dealing with forgetting
I have each checklist stored in a separate document. In the document, below the checklist, I record various notes, including notes on forgetting the checklist execution or forgetting specific steps. Documenting this helps me observe what I’m missing and why, and helps me focus on being more reliable on those fronts. In practice, for me such notes are fairly rare—less than 2 per checklist per month.
Purpose of checklist items
Enforcing some cadence on things I need to check on regularly
For some of the items, such as checking email, messages, and Slack, I include them in my morning and night checklist (as well as other checklists such as my pre-outside trip checklist and pre-meal checklist). This enforces that I do them reasonably regularly, without forcing specific times when I do the checks.
In the past, I did check various things like email, messages, and Slack reasonably regularly, but there would often be large random gaps; for instance, there was once a gap of about 1.5 days when I didn’t check my personal email, and there were times when I didn’t clear out some Slack messages.
For some checks, I don’t need to do them that regularly, so I enforce a less frequent cadence. For instance, checking my spam, trash, and all mail is something I have in my morning checklist but not in any of my other checklists. Prior to explicitly adding them to my checklists, I often didn’t check my spam, trash, and all mail for several weeks. Spam and trash emails get deleted every 30 days, so enforcing some cadence that’s more frequent than 30 days helps make sure that I don’t miss such emails.
Reducing the risk of escalation, particularly at inconvenient times
Things like email, messages, and Slack often include early warnings of things that could blow up into emergencies if not responded to in time. It’s particularly inconvenient if these escalations happen at bad times such as when I’m sleeping or when I’m not at home. I reduce this risk by checking my email, messages, and Slack right before going to sleep or going outside the home.
Getting timely and decision-relevant information
Checking the weather forecast regularly is valuable because information about future weather can inform my plan and schedule. Similarly, checking the calendar regularly gives me information on how to schedule my time the next day.
Recording stuff before I forget
The checklist item (in both my morning checklist and my night checklist) to review and update my daily update is an example. See my post The why and how of daily updates for general background on my use of daily updates.
Setting relevant stuff up
For instance, opening the windows helps with ventilation; setting the alarm clock creates a fallback way for me to make sure I wake up on time.
Being prepared for failure or extended unavailablity
Every time I close for the day, I want to be in a “clean state” as much as possible—everything I do has been committed and backed up, so that if my laptop crashes and doesn’t recover the next day, I haven’t lost any of my work. For instance:
The loose ends script that I run every night and every morning (as well as before outside trips) is to make sure that various things on my laptop have been backed up remotely and cleaned up (primarily, it checks that all my git repositories are in clean state).
Every night, I close my laptop lid. This reduces the risk of dust on the laptop, but the main reason is to reduce the risk of damage to the laptop that might arise from any accident.
Annotating my night checklist with the purposes served by each checklist item
Here’s a revisit of my night checklist, with the inclusion of purpose for each checklist item.