...uplinks, including horizontal links to competitors or antipatterns
Problems look differently, and have different dynamics, at different levels of zoom.
Often, we have general stories for why things happened as they did, and use those general stories to guide behavior. The pattern of frame-by-frame debugging involves zooming in to the specific way in which things went wrong (as an analogy to finding the 'frame of the movie' when things went off the rails), applying a fix to that specific instant, and then confirming that in fact that would have caused the movie to go differently.
This helps avoid wishful thinking situations where non-solutions are accepted as solutions, instead focusing on reductionistic detailed solutions.
The steps for using this technique:
- Pick a problem from your current bugs list. It can be large and sticky or small and straightforward.
- Describe a recent, concrete example of it. Tell the story of a time the bug occurred, hitting as much relevant, causal detail as you can. If you can’t remember clearly, try describing the parable of the bug—a made-up example intended to be characteristic. Often, it’s helpful in particular to inquire into the difference between what happened, and what you wish had happened (whether this is concrete or general).
- Where did it go wrong? Try to pinpoint the exact moment at which you left the path to your preferred outcome, and instead ended up on the path toward the actual, dispreferred outcome. This may be obvious, or it may require tracing things back through several causal steps, especially if the preferred outcome is somewhat vague—instead of looking at the moment when you began to notice problems, look for the moment that led to those problems.
- Zero in on the exact moment. Think of the bug as a movie, and look for the exact frame where you ought to have intervened, or want to intervene in the future. At this level of behavior, most things should look like trigger-action patterns—this happening causes that, which leads directly to that, which set that into motion. Look for thoughts, emotions, words, specific actions, or things you failed to think of (or the absence or negation of any of these).
- Check for awareness. In the moment it went wrong, did it even occur to you to take alternative actions? Were you conscious and paying attention, in the relevant sense? If not, what cues or clues might you try to trigger off of, in the future?
- Reality check. Is this really the right plan? Regardless of which type of bug it is, you should always try to design solutions that are generally applicable (i.e. if you imagine your TAP firing all throughout your day or week, is it going to cause you to take incorrect action sometimes?). Use Murphyjitsu on your “final” plan, to confirm that you really do expect success, or go into the first round knowing that your plan is experimental, and that its likely failure will provide you with useful data for your second iteration.
In broad strokes, there are two kinds of problems that tend to benefit from frame-by-frame debugging: forgetting-type problems, and motivation-type problems. These two categories aren’t exact or mutually exclusive, but they can help you zero in on whether your intervention is more about focusing on triggers or improving intended actions.
If alternate action did NOT occur to you, the goal is to improve the chances that you’ll notice/be aware next time. Useful tools include TAPs, systemization (creating environmental cues so you don’t have to rely on memory), comfort zone expansion (to make this kind of awareness more possible for you generally), and general inner sim techniques like mindful walkthroughs and Murphyjitsu. Note that sometimes you’ll solve the forgetting-type problem and discover that there’s also a motivation-type problem underneath.
If alternate action DID occur to you, the goal is to make the preferred response more desirable and less effortful, which also includes confirming that it really is the preferred response. Useful tools include goal factoring, aversion factoring, inner dashboard calibration/internal double crux, and any personal sanity-inducing rituals you’ve developed. Note that sometimes you’ll solve the problem of motivation, and still need to get more concrete (e.g. with TAPs or systemization) before you’re actually lined up for success.
Therefore:
Zoom in to the level at which the fault is occurring and see how your solution would have caused a different outcome to happen before calling it a solution.
downlinks
