« All Episodes

Protecting Flow State - Plan Now, Pause Later

Published 2/10/2023

Protecting your flow state may help you have more "peak experiences" - whether in your career or in your personal life. This is your opportunity to make the biggest strides and highest achievements.

In this episode we start a conversation about what it takes to protect your flow state.

📮 Ask a Question

If you enjoyed this episode and would like me to discuss a question that you have on the show, drop it over at: developertea.com.

📮 Join the Discord

If you want to be a part of a supportive community of engineers (non-engineers welcome!) working to improve their lives and careers, join us on the Developer Tea Discord community by visiting https://developertea.com/discord today!

🧡 Leave a Review

If you're enjoying the show and want to support the content head over to iTunes and leave a review! It helps other developers discover the show and keep us focused on what matters to you.

Transcript (Generated by OpenAI Whisper)

For the next few episodes, we're going to talk about a concept that's so powerful for software engineers that it deserves a few episodes to learn ways that we might protect it, and that is flow. You probably have heard this term with relation to work. That's because the body of work related to flow was started in the mid-20th century by a Hungarian-American psychologist named Mihaly Csikszentmihalyi. And even if you haven't necessarily seen the research on this, you probably know the feeling of being in the flow. You may have even said it without knowing that. Indeed, there is quite a bit of formal research on the subject. The flow state, as clarified by the original research, and as Mihaly Csikszentmihalyi explained, it is the state of doing something where you're so involved in that activity that nothing else seems to matter. You kind of forget time. The experience is so enjoyable. This is a direct quote from him. The experience is so enjoyable that people will continue to do it, even at great cost, for the sheer sake of doing it. You've probably had this experience. You may have had it while programming, though not necessarily. But it has specific characteristics. Specific characteristics. You kind of already understand it, most likely, intuitively. But let's go through these characteristics. These are factors, and I'm reading directly from Wikipedia. This is not some secret. You can go and find this very easily. But the factors identified in the research. One was intense and focused concentration on the present moment. Two is the merging of action and awareness. Three is a loss of reflective self-consciousness. Four is a sense of personal control or agency over the situation or activity. Five is a distortion of temporal experience as one's subjective experience of time is altered. And six is the experience of the activity as intrinsically rewarding. Now, if this sounds a little cerebral, I want you to stick with me here. We can kind of break this down into what it really looks like. If you're doing something that you have sufficient challenge in, in other words, it's not boring. It's difficult enough to keep your attention. You're good enough at it that it's not overly challenging. You're not being beaten by the thing. It's somewhere in between boring and too challenging. Where you're actually able to succeed but with significant effort. With a clear reward, a clear goal in mind and a clear reward in mind. And that constant sense of feedback that you get during your whatever that activity is. These are the elements that are necessary for inducing that flow state. Of course, it needs to be uninterrupted as well. Which goes back to the very beginning of those factors that we listed off. Your total focus and attention has to be on this particular thing. Now, those factors represented also talk about kind of the resulting feeling or your perception in a flow state. You may feel the sense of that temporal distortion. In other words, time seems to fly by without you realizing that it's flying by. So, why are we talking so much about flow? Well, this is possible to achieve in your personal life, of course, and in your professional life. If you really enjoy, for example, software engineering, coding, you can get into a flow state when you're coding. Now, regardless of what induces flow state, what activity induces flow state for you, intrinsic in the definition of flow state is that these are peak experiences. In other words, they are some of the most rewarding experiences of our life. Whether it's during work or not. And because of this reason, I want to share some strategies for protecting that flow state. Dealing with things that might intrude on the flow state. In today's episode, we're going to talk about a spike in difficulty. Spike in difficulty. This can interrupt the flow state because, remember, one of the factors that defines the flow state is that you are capable of solving the problem. It's not a boring problem. It's not something that you can do with your eyes closed. But it's also not so difficult that you're stalled out. The moment you stall out, you'll exit that flow state. So here's one strategy to help protect your flow state. And this strategy is dependent on you planning to enter the flow state. In other words, for some people, the flow state might happen to them. But this is if you are intentionally kind of creating a work session, for example, and you want to enter into that work session and to be able to enter the flow state. And avoid that interruption. So here's the strategy. Plan now. Pause later. Plan now. And pause later. What this means is before you enter your work session, try to imagine some of the kinds of problems that you wouldn't be able to solve ahead of time. Try to create, and this is the planning portion, by the way, try to create rules that make, make the decision fast. You don't have to make good decisions necessarily. They just need to be good enough. And so if you go with, let's say, a low-risk decision, or if you go with the cheapest decision, whatever the thing is that makes the decision a simple rule. So really what you're doing is you're converting these future possible situations. You're saying, I'm going to use a heuristic. I'm going to use a heuristic immediately when I encounter a decision that I don't already have kind of the muscle memory for. And what this does is it allows you to stay in the moment of the work. Instead of saying, oh, well, I'm going to have to pause. I'm going to have to go and do some research. I'm going to have to ask somebody about that. Well, no. You have a heuristic that you can apply, and hopefully you have one or two heuristics that you can apply that will make that decision easier. In the moment, if you encounter a decision, where you need to take time to evaluate, if you don't have those heuristics, or if the heuristics are proving to be not as helpful as you had hoped, try pausing on the decision. What this means is work your way around it. Imagine the decision is a boulder and you're the stream. Your goal is not to move the boulder. It's just to keep the stream flowing. So whatever you've got to do, go around it, go over it, but don't stop moving. This means that you're pausing on solving the actual decision problem. All you really need to solve is the momentum problem. A good example of this is, let's imagine that you run across an issue where you need access to an API, and the access requires you to file a ticket with your IT department, or maybe access is, is limited, or you have to apply for approval for the API key. Who knows, right? There's plenty of reasons why you may not get access. Well, it's likely that you can fake access. You could stub out the response. It's helpful to have tools in mind that can keep your flow engaged. For example, in that last situation, I might open ChatGPT and ask it for a sample payload from, whatever service. Now, this doesn't necessarily mean that your code is going to be correct. That payload may be totally wrong, and no tool is perfect. Using something like ChatGPT comes with its own considerations and problems. But if your goal is to keep moving, well, you solved that issue. Instead of hitting an API endpoint because you don't have access to it, instead of stopping for the day and waiting for that to come, you can continue your flow state by just faking it. Pause. Pause on the decision. You don't need to make every decision right now. You just need to keep flowing. Take these ideas into your next work session. Create heuristics ahead of time. Plan to make your decisions simple rather than full of friction. If your planning doesn't cover everything, when you encounter something, try to pause. Now, this isn't going to solve every single problem. You will get taken out of flow state sometimes. That's just the nature of our work. But every time you do get taken out of flow state, make it a point to learn about it. What happened there? How can I prevent that from happening in the future? Or looking back on it, was there another way I could have approached it? Did I make that decision harder than it needed to be? Did I try to make the decision sooner than I needed to? These are all ways of learning. Learning how to improve your protection of your flow state. Thanks so much for listening to today's episode of Developer Tea. I hope you enjoyed this episode. If you'd like to discuss the way that you protect your flow state, maybe it's totally different from this episode. We're going to continue talking about this in upcoming episodes. I'd love to hear from you. Join the Developer Tea Discord community by going to developertea.com slash discord. That's totally free. Thanks so much for listening. And until next time, enjoy your tea. Bye.