A practical guide to progress

« Going hater mode » on your obstacles

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,

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

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:

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

Signal (New information to be assimilated)

Written in blue pen

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

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.