Engineering the Flow State
I recently finished reading Flow by Mihaly Csikszentmihalyi. It’s an amazing book that touches on years of research on what makes humans happy and productive. Mihaly posits that humans are happiest when we are working on something in a state of total concentration and immersion with the task at hand, which puts us in a state that he calls ‘Flow’. I’d highly recommend the book, and he’s also given a number of great lectures on the subject:
While I, along with many other people (I’d imagine), sometimes reach this state by accident, after finishing Flow I’ve been looking for some sort of quantifiable way to apply its techniques in my day-to-day programming work. Mihaly offers a number of pre-conditions to get into the Flow state (which you can see here), but those are more concerned with circumstantial requisites, and I was interested in figuring out if there were more actionable steps I could take, specifically in regards to coding. After a couple of weeks of experimentation, I seem to have found a straightforward way to potentially increase my chances of getting in Flow. It’s pretty simple: I’ve found that if I consciously ignore 3 distractions in the first twenty or so minutes of my programming session, I’ll be primed and ready to get into a flow state if I keep working for another ten or fifteen minutes.
A common trend I’ve seen, particularly in the fast-moving day-to-day world of modern technology, is there’s endless opportunities for distraction, both internal and external. Getting an email notification, a Slack message, wondering if a new JS library has been released in the last ten minutes and checking Hacker News, the list goes on endlessly. Anecdotally, I probably get one of these every five minute or so. While useful in their own regard, if you’re looking to get into a state of flow with coding these distractions are definitely counterproductive.
By consciously ignoring (emphasis on consciously) three of these distractions in a row, you’re priming your mind to see these as obstacles to be ignored rather than a part of your workflow at that time. In a holistic sense they are far from meaningless, but in the context of wanting to get into a flow state to solve a challenging problem or implement a complex feature, they are better acknowledged and mentally internalized as distractions for a few hours. I’ve found that with three of these distractions consciously ignored, my brain stops trying to drag my attention to them and lets me focus on the work at hand. Ten or fifteen more minutes of that tends to give me a higher change of going into flow state.
It’s a simple process, but I’ve found that in terms of improving time management and productivity, those are always the best types of processes. With all this information floating around about how to improve oneself and one’s work/productivity, I think it’s important to be able to take these somewhat abstract theories and experiment with concrete procedures that you can use to to create predictable outcomes. This differs on a person to person basis, but if you try out other peoples’ processes and experiment on yourself with them, you can see what works and what needs modification. From that point, it’s just a matter of continuing to modify the process until you can reliably reproduce your desired result.
