This post is part 2 of The downbeat technique, a series looking at a physical analogy to exit writer's block, fatalism, and burnout at a core psychic level. In part 1, I discussed the motivation behind it and here I want to cover how to use it effectively as a software engineer.
Whiteboard the win
To reverse this instinct I propose, counterintuitively, "going hater mode" on oneself (call it "the downbeat technique" if you prefer), a psychological hack involving listing all the working drawbacks, problems, criticisms and imperfections at the bottom of a whiteboard, flanked by down arrows. The solutions go at the top, flanked by up arrows, and the focus becomes on whittling away the negatives by essentially 'swarming the blocker' for oneself.
There's something very revolutionary, much like 'steelmanning', from flipping the default psychologically avoidant stance to one which proactively asks,
- What about this work makes it flawed?
- What about the flaws is ambiguous or yet unconceptualised?
- What makes the concept disfluent? (i.e. difficult to think about)
In practical terms, this enacts a shift from merely jotting down a task (typically one already recorded in an issue tracker, so imparting no new information) to a more deliberate, step-by-step process that targets the specific issue impeding your workflow, and one which explicitly acknowledges that it's probably your own view of the problem that's in the way rather than any skill issue.
Let's say you're stuck on optimising the search algorithm you came up with. Instead of simply writing "optimise search algorithm" and turning your whiteboard into a TODO list (which, you might notice, leaves no room for emotional attachments, positive or negative), you could write down a more specific sub-task that focuses your attention on the difficulty you're facing, which tend to present as questions, like
- "Where is the bottleneck in the search algorithm?"
- "Are there better algorithms for optimization techniques?"
- "Unclear how optimal algorithm works from example in Perl"
Which you would then solve (and if it helps, writing these solutions at the top of the board), which again can be questions but might well be statements of knowledge or actions to be taken:
- "Run profiler to gauge runtime complexity of each step of the algorithm"
- "Look in index of X, Y and Z algorithms textbooks"
- "Ask ChatGPT to rewrite algorithm from Perl to Python so I can understand it"
By naming the challenge or uncertainty, you're better able to direct your focus and attention towards finding a solution, rather than just being reminded of the task at hand. I also personally find that it cuts any negative attachment away because the style of presentation (big down arrows) already established that it's a puzzle, and you can sound out solutions above it.
What's the bug, or mistaken assumption, or the thing that you can't quite put your finger on that's preventing you from just writing the answers out? Name that. Name the obstacle in your path. Don't name the road you're on (or at least, do so elsewhere).
Often this is exactly the place that you should start, because once you set that as your sub-task, or address it head on directly first, you are then left with a much clearer view of the work to be done, and sometimes you effectively end up biting the bullet, leaving everything after that becomes a breeze and a pleasure to work on.
Cognitive dissonance-specific variation
After reviewing some work on cognitive dissonance, I came up with a new variation which is more precise.
In this version, the arrows are labelled, as is the middle zone. You do not need to use these, but it may be instructive to consider them as being "under the hood":
⇑ Consonance (Coherence)
Written in green pen
- When using ChatGPT, I write prompts I am developing here (such as "Write a
Python function to access X to get Y [precise detail here]. [Specific conditions of success here]")
- Meta tip: use ChatGPT to simplify the prompt if it itself is unclear!
Signal (New information to be assimilated)
Written in blue pen
- When I receive a new directive, I write it here (such as "use X to get Y")
The key word here is new: it is a transient staging area not a holding area.
It must not store anything for longer than necessary.
Something left here for multiple days is likely no longer a new aspect (and ought be erased).
⇓ Dissonance (Inconsistencies)
Written in red pen
- The specific aspects of the task that are not readily 'mentally computable':
those which I either need to think about more or calculate something to establish.
- Can also be a description of a specific part of a problem, e.g. "service orchestration" or a specific technical requirement of a program, e.g. in/output spec
- Taking care not to roll multiple aspects into one (properly factor out individual aspects)
Keep the complexity bar high
As far as possible, try to use statements and questions on the board rather than free-floating concepts.
For example, at one point while a bit overwhelmed by the new GPT-4 model I put "service orchestration (foo/bar exclude)" on my whiteboard, for some domain-specific components foo and bar. By this what I really meant was that I wanted to add control logic to exclude certain categories once I had completed the central logic of the service. When I didn't state it clearly like this though I made it more difficult to verbalise that need. This illustrates why it's crucial to avoid having these 'free-floating' parts as elements on the board, and instead use fully self-cohesive statements.
With a little deliberate effort I improved this to:
Add control logic for foo/bar exclusion
It's not over yet: this series on The downbeat technique continues in part 3, where I look at why this technique works from a cognitive science perspective.