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, being more critical of oneself.
I called it "the downbeat technique" to evoke the cycling analogy from the previous section, but all it involves is rising to meet your challenges (the obstacles which Agile calls 'blockers').
To do so, list all the working drawbacks, problems, criticisms and imperfections at the bottom of a whiteboard, flanked by down arrows. Likewise put potential solutions at the top, flanked by up arrows, and focus on whittling away the negatives so as to unblock yourself.
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 exacts a shift from merely recording a task (typically re-recording one that's already 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" thus turning your whiteboard into a TODO list (leaving no room for emotional evaluations, 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 algorithms textbooks: X, Y, Z"
- "Rewrite Perl algorithm in Python to 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":
Signal (New information to be assimilated)
- When I receive a new assigned goal or one that popped up in another task, I write it here in blue (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)
- The specific aspects of the task that are not readily 'mentally computable' I write here in
red. Those which I either need to think about more or calculate something to establish.
- May be a description of a specific part of a problem that is self-evidently awkward, e.g. "service orchestration"
- May be a name relevant to your work whose full relevance is unknown to you, or a specific technical requirement of a program, e.g. in/output spec
- Taking care to properly factor out individual aspects, not roll multiple aspects into one
⇑ Consistency (Coherence)
Written in green pen, typically only after verbalising the problems
- Ways to solve the problems (such as "Write a Python function to access X to get Y.")
Keep the complexity bar high
As far as possible, aim to record complete and precise statements or questions rather than isolated concepts or ambiguous phrases.
For example, at one point while getting my head around the brand new GPT-4 model, I wrote
"service orchestration (X/Y exclude)"
on my whiteboard, for some domain-specific components X and Y.
By this I meant I wanted to add control logic to exclude certain categories once I had completed the central logic of the service.
This vague note made it challenging to express my requirements explicitly. This illustrates the importance of avoiding cryptic notes and instead ensuring that all items are complete and self-explanatory.
After some reflection I improved this to:
Add control logic for foo/bar exclusion
This modification makes the intention straightforward and doesn't require additional interpretation to figure out the intended action (the "actionable" item).