in the last episode of developer t we talked about protecting flow we also established the definition of flow we're not going to go over all of that again in this episode i'll reference that one if you want to go and learn a little bit more about flow and why it's important the summary is flow is necessary for peak experiences this means that your best work or your best performance your best moment playing a particular sport or an instrument or whatever it is that you feel most connected to your talent your skills your best expression of those things is almost certainly going to happen in a moment of flow so we're talking about protecting your state of flow in the in a couple of these episodes the last one and this one we'll probably talk in another one about this because it is so critically important and in today's episode i want to talk about protecting that flow through preparation protecting the flow through preparation last time planning and pausing planning to make a decision by using heuristics whenever you come up against a hard decision that requires you to think longer than necessary it's going to take you out of flow most likely so have some kind of heuristic tools for the decisions you think could be a part of that experience the pause is to defer those decisions in this episode we're talking about prepping for your work and the first thing we're going to talk about is the process of planning and pausing planning to make a decision by using heuristics whenever you come up against a work session whatever your work session is or whatever your practice session is your performance whatever those things are i want you to think about this episode as a precursor to those things and you can probably look at your schedule today and figure out what thing am i doing today that most fits this model what thing am i doing where i could possibly given the right circumstance given the right very variables i could possibly get into a flow state now especially the ones that you want to get into a flow state with right now here's the important part these things don't just come together on their own you can design this situation and that is what we're talking about doing in this episode we're going to design our environment we're going to design the situation so that we have the best opportunity the best chance of finding a flow state and in today's episode i'm going to give you an extremely simple uh kind of technique and this technique is is so simple that it almost won't feel like advice it'll feel obvious when you hear it but when it comes to flow a little goes a long way right this is very important to understand so i'm going to give you two things that you need to plan out right uh two things that you need to plan out before any session where you expect or want to get into a flow state and i'm going to give you two things that you need to plan out before any session where you expect or want to get into a flow state and this is remember we said all the variables have to be right well you're trying to control for some of the variables that you can control for you're setting yourself up for that flow state so this is very simple we're going to go over both of these the first is to decide what your goal is now understand that in this case normally we are talking about zooming out and looking at the big goal and trying to use motivation and motivation and motivation and motivation and motivation and motivation and motivation and motivation and motivation and motivation and motivation and motivation and motivation for the long run to inform what you're doing today to in this case i don't want you to do that in this case i want you to identify a very short-term tactical goal this is the thing that you want to be true today when you're done with this session what is it specifically and this has to be very very specific otherwise it doesn't work and this could be as simple as by the end of the session i'm going to be able to do this and i'm going to be able to do this i want this test that is currently failing to succeed and that's it that's your whole goal i want this test when i run it right now it fails i want it to succeed and i'm going to put all of my mental effort my all of my focus all of my energy all of my thinking and feeling everything that i'm doing i'm going to put all of that into making this goal happen now it's very very important that this is a goal that is achievable it's a goal that is difficult enough that it's not going to happen in the first moment or two moments of of your session your work session so difficult enough to be challenging for you to take some time to actually achieve it but not so difficult that your goal stretches across many sessions remember your singular session needs a goal this needs to be accomplishable within whatever session you are currently working through whatever that is practice session work session this goal needs to be complete by the end of the session the goal can't be open-ended right the goal can't be uh you know do this as fast as possible then you don't really know if you're meeting the goal this breaks uh the entire concept of flow because your accomplishment becomes uh something that you begin thinking about rather than knowing right understanding the difference here is really critical if you set a goal that is open-ended it's not really a goal then your goal needs to be something that you can measure and easily say yes i met it or no i didn't meet it now again this may sound obvious but very rarely do we think about these things when we sit down for a work session what is my specific goal in this session how do i know if i've exceeded in this session so that is the first variable that you can control we're going to take a quick sponsor break and i'll come back and talk about the second variable this episode is sponsored by split the feature management experimentation platform what if a release was exactly that a moment of relief an escape from slow painful deployments that hold back product engineers think about it if you had a work session where that was your goal to release the thing and you could do it in one work session well with split you can free your teams and your features by attaching insightful data to feature flags split helps you quickly deploy measure and learn the impact of every feature you release which means you can turn up what works turn off what doesn't and give software innovation the room to run work session and you can do it in one work session with split you can free your teams and you can do it in one work session with split you can free your teams now you can safely deliver features up to 50 times faster and finally exhale split feature management and experimentation what a release reimagine software delivery and start your free trial and create your first feature flag at split.io developer team that's split.io developer team thanks again to split for sponsoring today's episode the first variable you control is setting a goal if you have a work session if you have a practice or performance and you don't have a goal you don't know what you're aiming for or maybe you have a general idea of what you want but you haven't made it explicit enough to know whether or not you've succeeded this breaks us out of flow even if you're productive your brain will be evaluating rather than focusing your brain will be evaluating how successful am i rather than focusing on the finish line out in front of you and that brings us to our second variable how will you know if you're going in the right direction or not to meet your goal the second thing to control for is to decide what is your feedback channel and i literally think you should do this before each session explicitly write it down on a piece of paper put it on a sticky on your computer screen whatever have your goal explicitly stated and the feedback channel you're going to listen to to know what to do to know what to change in order to meet your goal your feedback channel might be your tests maybe automatically running in the background and letting you know what's failing and what's succeeding now remember if you're going in the right direction you're going to have to set a goal and you may have to write yourijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijij hard to quantify. This is especially true, for example, for athletes. Some athletes can feel when they're in the zone, when they're kind of performing at their best versus when they're performing at a substandard of their best. One form of this feedback for athletes specifically comes by the way of imagination. Before performing a particular, let's say, high dive, an Olympic athlete thinks about and imagines how the high dive should go. They think about all of the individual movements, both from the outside looking in and from the inside looking out. What is it going to feel like to perform this particular move to a perfect degree? And what is it going to look like from the outside looking in? By creating this picture, the athlete can then in that moment of execution compare against what they're doing versus the picture. This is representative of a kind of feedback that is difficult to quantify by nature of the activity that you are getting feedback from. In other words, let's think about another sport, downhill skiing. Imagine that a world-class downhill skier is trying to beat their last run, and they know that they can only beat it by maybe tenths of a second. What kind of feedback is relevant in this case? Perhaps if they were not a world-class skier, maybe they are a beginner skier, then feedback like some sort of indication of time on the run would be helpful. But because the margins are so slim, the feedback of that time, the current time on the run, that kind of feedback probably wouldn't be very helpful. In fact, the feedback is not always the most obvious thing to help you achieve a goal. The feedback doesn't necessarily have to be a measurement directly against the goal itself. The world-class athlete, their goal is related to the amount of time that it takes to get down the hill. But the feedback they receive doesn't have much to do with the time at all. Overall, the basic idea here for both of these, to establish your goal and to establish what channel of feedback are you going to listen to, will work together to set up the right variables to give you the best chance of getting into a flow state. Imagining that the work is just the work, imagining that somehow you're going to find that goal as you go, or that you'll be able to pick up on all of the feedback signals, that's going to be a very important thing to do. All of these things are what lead to suboptimal experiences, suboptimal performance, situations where you're not in a flow state at all. The great thing is you can try this out, and it takes almost no time. It takes about one minute or so before your work session to set your intention. You may hear that phrase, set your intention. All this is really saying is set your goal, and then layer on that one other piece, layer on the feedback. This is going to help you get into that flow state more often. Try it out. Let me know how it goes. Thanks so much for listening to today's episode of Developer Tea. If you enjoyed this episode, please join our Discord community at developertea.com slash discord, and subscribe to whatever podcasting app you're currently using. Thanks again to today's sponsor, Split. Head over to split.io slash developertea to get started with your free account and set up your first feature flags today. That's split.io slash developertea. Thanks so much for listening, and until next time, enjoy your tea.