Achieving flow state while coding
Have you ever looked up from a project after what felt like five minutes and seen that an hour had passed? If so, you've experienced the phenomenon known as flow firsthand. Flow is a state of complete involvement in the task at hand, and we often do our best work while deep into this flow state. For developers, this can be especially true. Due to the need to build and maintain context in our heads while programming, any small distraction can cost us an outsized amount of time. However, it's not always easy to avoid distractions in our always-connected workplaces. So how can we get into flow, and how can we keep ourselves there? Here's some tips to help out.
Getting into flow
Certain conditions need to be met to get into a flow state:
- Our task must have a clear set of goals and progress. We need to know what we're working toward and that we're making progress as we go.
- Clear and immediate feedback. When we get feedback, we can adjust to keep ourselves focused and on track.
- A good match between the perceived challenge of the task and our skills, so we can be confident in our ability to complete the task.
Given these requirements, we can adjust our work routine to give us the best possible conditions for getting into flow. Here are a few of these possible adjustments.
- Plan your day - At the beginning of each day, take a few minutes to plan out what you'd like to accomplish that day. It may help to write this down in a notebook or to-do app so you can check back in to see what's next when you finish something up. That's one less thing to worry about during the day!
- Collect required information before coding - As developers, we want to be working on fully fleshed-out tickets and not go requirements gathering in the middle of coding. Make sure that all unknowns are dealt with before coding, where possible, so that there's no need to interrupt your focus to go requirements gathering.
- Avoid distractions - When you're ready to code, do what you can to create a distraction-free environment. This can include putting your phone away, silencing unnecessary notifications, cleaning up unrelated tabs or windows, and setting your status on Slack or other apps to indicate that you're heads-down on work at the moment. This should cut down on unexpected distractions that could pull you out of the zone.
- Take breaks - Taking a quick break every now and then lets you reset and come back refreshed. Get up, walk around, get some water. You can try the Pomodoro method, a 5 minute break after each 25 minutes of focused work, or experiment and see how long between breaks is right for you.
- Focus on the process, not the end result - Understand your final goal, but also focus on each step on the way to achieving it. By breaking the goal into smaller steps, we get feedback when we finish each of these steps, which motivates us and tells us we're getting closer to achieving our goal, which inspires us to stay in flow. For one example of how to break a big coding task into smaller steps, check out this blog post!
Creating an environment conducive to flow
Our tasks and our habits aren't the only thing that matter when we want to focus on coding. External factors have a significant influence on our ability to focus, so it's important to consider those as well. We can't always change our working environment at the individual level, so some of these points could be good to bring up to your manager or to the organization if they need addressing.
- Create a safe and protected working environment - If we're distracted by workplace politics or drama, we're not focused on coding. We should feel comfortable and secure in our working environment.
- Avoid non-contiguous meetings less than 2 hours apart, where possible - Getting into flow takes time, and having only half an hour or even an hour and a half of coding time sandwiched between two meetings makes it difficult or impossible to get into flow. Context switching is a real issue which can have a huge effect on your ability to focus.
- Establish guidelines to avoid interruptions - We should have methods to signal that we're heads-down coding, in order to avoid being disturbed. One example of implementing this policy is updating your Slack or other messenger status while you're coding, to let teammates know that you may be slow to respond. For in-person teams, the 'headphones rule' suggests that developers should not be interrupted while wearing their headphones.
Our development practices also serve a role in helping us stay focused. I've found the following practices especially helpful.
- Pair programming reduces cognitive load for each developer.
- When one developer is distracted by something small (slack message, important email, etc) the other can mentally maintain the current programming context to avoid it being lost due to the distraction.
- In a physical setting, it may be more clear to outside parties that the developers are deep in code and not to be distracted with any non-urgent concerns.
- In TDD, the tests function as an outline of what you'd like to achieve with the feature you're working on. If they are written first, it can be easier to come back after a distraction, run the tests, and get an idea of what remains to be done.
- This only helps with the more macro-level tasks, any context around how you were working toward getting a test passing may still be lost.
No Meeting Days
- Designating a day a week where meetings should be avoided gives everyone guaranteed uninterrupted time to focus. This certainty is helpful in both planning out our work and accomplishing it.
- Meetings can still be scheduled if absolutely necessary, but the no meeting day must be taken seriously or else it will not work.
Testing it out in the real world
In an ideal world, we're easily able to focus on our work, never being distracted during time we'd rather be focusing. But we don't live in an ideal world. These tips should help you find time to concentrate on your work. Try picking just one or two that you find interesting, and implement them during your next work week. Keep what works, throw out what doesn't. Everyone will have their own process that works best for them, and now you have the tools to find what that process is for you!