An On-Ramp to Flow
One Weird Trick: Leave Your Work Broken
Millions of words have been written on the value of âflowâ to engineers and other knowledge workers - a kind of work where you are able to hold multiple complex and abstract concepts in your head simultaneously and quickly make progress towards a goal. Over the course of a work week, itâs not surprising to find that a huge amount of the âwork that gets doneâ happens within a few short bursts of time, a couple of hours at most, when builders are able to reach and stay in flow.
Staying in flow is important, and itâs why good engineering teams will swat away distractions (Slack, emails, meetings, etc) to maximize the length of these flow states. But what about getting in to these states in the first place? I (and I suspect many others) have struggled with overcoming the writers block that one feels when starting to engage with a big, hairy engineering problem - everything feels overwhelming, where do I even start?
As I see it, there are two hard things about getting into flow: loading the state of the system / problem / abstractions into your head (i.e. filling your L1 and L2 cache with everything you need to know to work on the problem) and building momentum and confidence for yourself. While this doesnât always work, I do have One Weird Trick that I have found incredibly useful to re-enter flow and continue working on large problems: Before stepping away, leave the code in a state where it is Obviously Broken, but Easy to Fix.
Obviously Broken - when you return to your coding session, the next thing to work on should be screaming out at you. Ideally you leave your working state in a place where a compiler or unit test is loudly failing, so your tooling can act as external memory to remind you of where you were when you previously stepped away from the problem.
TODO
comments can also work here, but when you sit back down at your workstation to start coding again, you should immediately know what needs to be worked on next.Easy to Fix - the problem that you have left for your future self should be one that you can fix in just a few minutes, without needing the benefit of deep system knowledge at ready access. Thereâs an art in deciding âhow easyâ the issue should be - leaving something trivial (like implementing
hashCode()
) might be too simple - the idea is to give yourself a first task that will let you start writing code with a high probability of short-term success while you âmarinateâ in the larger problems.
Applying this technique means thinking about how to exit flow in a way that makes it easy to re-enter. And there are two ways that exiting flow / ending a coding session can go wrong:
Exiting after hitting a âneatâ stopping point - unless the task is done, leaving the system / code too clean makes it hard to know what to work on next. While itâs really tempting to try to stick the landing on an internal milestone, it can often be more productive on net to stop just short of a neat milestone as an onramp to your next coding session.
Exiting when hitting a wall or roadblock - this is also a tempting time to move on to another task, for obvious reasons, and while walking away from a problem and letting it sit in the back of your mind can often be a useful tool, itâs really hard to get back into flow when the âfirst task upâ is a really hard one. If you do hit a wall, mounting a âstrategic retreatâ and undoing or commenting out a little bit of the work that led to that roadblock can help with momentum creation in your next attempt.
This advice isnât universal, and itâs primarily focused on solo coding tasks - if youâre working in close collaboration with others, you might pick different stopping points (or you might find that leaving things just a little bit broken is a Good First Issue for a teammate coming on to a project). What tricks do you use to create, maintain, and re-enter flow? Let use know at @CensusDev and weâll share some of the best answers!