A few months ago, I finished reading Flow: The Psychology of Optimal Experience by Mihaly Csikszentmihalyi. Wow, what an fantastic book!
Have you ever did something that made you focus on the subject so much that you forgot about your surroundings, forgot about time and just enjoyed doing what you were doing? This is known as Flow.
Flow is a state of optimal experience; a state of joy, creativity and total involvement in which problems seem to disappear, and there is an exhilarating feeling of self-transcendence and control. The book also explains how it can be used as the key to happiness, which is actually the end goal in this process.
This state is something that can be achieved by following five simple principles:
- Choosing and clearly defining goals – from the smallest task to finding life’s authentic purpose.
- Finding ways to measure progress – with clear feedback against an objective or visualized outcome.
- Learning to concentrate fully on the task at hand – focus attention on what you want, for as long as needed but no longer.
- Developing the skills needed to make progress – connecting and interacting ever more deeply with the world around you.
- Raising the stakes – ensure that your goals always stretch and inspire you.
Mihaly Csikszentmihalyi proved that they could be achieved by anyone - tennis players, factory workers, surgeons, etc.
Now, I’ve recently seen this comics again, and I started thinking about what I read in Flow:
Programmers keep talking about the Flow state, but at least to me, it always sounded very vague. It was possible to feel it, but it was hard to describe how to achieve it, “concentration” was the only word that came to mind.
And concentration is a big part of it, but it’s not the only one. Let’s try to apply those five principles above to programming:
- Choosing and clearly defining goals – easy to do from the high-level perspective with endless ticketing systems, priorities coming from project and engineering managers, etc. A bit harder when actually sitting in front of the screen writing code, but we’ve been trained to split complex systems into multiple manageable components, build modular software, use SOLID and DRY principles, apply top-down and bottom-up design, etc. In the end, this is somewhat simple if you have a mentor or just enough experience.
- Finding ways to measure progress – this one is not as straightforward, but we naturally found solutions. Running tests is the simplest and the most effective way to quickly get feedback on the piece of code you’ve just written. That’s why TDD can be so productive sometimes. Code and design reviews, successful deployments, “green” monitors and met SLAs are also ways to get feedback.
- Learning to concentrate fully on the task at hand – this is something we have to do all the time. Sometimes it’s not as easy as we want it to be, so we use Pomodoro Technique, enable “Do not disturb” modes, etc. And this is why open office plans have been attacked so much.
- Developing the skills needed to make progress – continuous education through conferences and training, mentorship (both ways!), and exploring new tech and practices are the key ingredients to successful skill development.
- Raising the stakes – taking more ownership and working on progressively more complex tasks and projects feel like the right ways to be challenged and stay in the Flow.
Some of these are somewhat straightforward, but I decided it’s a good idea to share them in a more structured way anyway. I hope they can help you stay more productive!