Flow Podcast
Transcription
Intro
Hello, my name is Alan Barr, and this is the Alan Barr Show. I’m passionate about software, software testing, and writing. The intersection of metacognition, organization, and technology. Today’s episode is about flow. We’re going to talk about a lot of the ideas from the book Flow by Mihaly Csikszentmihalyi, and an article on developer productivity for humans, and hopefully adopting a holistic developer experience. The reason this is important is because many of us work on software every day, or other businesses, and we don’t really understand when and how we achieve flow consistently. The book covers a lot of types of activities that can help flow. Mihaly calls this the optimal experience. So in today’s episode, I’m going to focus on a short summary of the book, condensing the details that impact people in our day-to-day work-life needs. From there, I will talk about the blog article, Developer Productivity for Humans, Part Six, Measuring Flow, Focus, and Friction for Developers, and how it could be applicable or not to your situation.
Flow by Mihaly Csikszentmihalyi
All right, let’s talk about the book, Flow. So what is flow? It is the optimal experience. We want mastery of our life. To be in flow, do these four things. Set goals, be immersed in the activity, pay attention, enjoy the experience. In the book, Mihaly explains that flow is autotelic, being it is an end to itself. These are two Greek words combined, auto meaning the self, and telos, goal. When you achieve the autotelic self, a threat is replaced with a constant surprising challenge that keeps growing and maintains peace. Some people may not be able to achieve flow, or at least find it difficult. You do not want to be and stay in flow constantly either. There are positive and negative effects of flow. A musical performance can be a great positive example, whereas gambling may be creating a negative flow experience. Flow should keep flowing. The optimal experience is when you are doing a task, and it is effortless. In some cases, hours pass in minutes, and the reverse can also happen. A ballet dancer may take a turn that feels like minutes, and in real time is seconds. The best moments in life occur when you are stretched to the limit. We know that a task could be too mundane or too complicated. What stops us from going into flow is the processes that interrupt or distract from moving forward. Attention shapes our work, and by shaping the work, our attention is formed. Then it is not one task that instead is taking control. Learning how you learn, they describe it as ecstasy. After a flow episode, you feel more differentiated, yet also you can be closer to other people. We want everyone to enjoy life and flow without impacting others. What is interesting is that everyone can search for opportunities to take the day-to-day tasks as a way to build a skill. Take for example pouring coffee into your cup. How much coffee should you pour? Should it overflow or should it be a trickle? What if someone else is pouring for you? How do you hold your cup and respond when it is time to stop pouring? You can find purpose and enjoyment from tedious work routines. After flow, the quality of an experience is better. You might think about symbolic ideas like wealth, status, or power. Instead it might be better to make everyday life more harmonious and satisfying. We can find an opportunity in the most arid situation. If it seems boring, raise the stakes. Harness the task and cultivate your skills so that you can strengthen your base.
The Autotelic Personality
Let’s talk about this idea of the autotelic personality. When people are in an extreme situation, they seem to overcome. In the book, there are a few examples of prisoners who are just extremely bored while in jail. In several examples, people would play chess in their mind, memorizing poems, translating and transcribing poems to recite for a contest. Joe Kramer is a welder that lives near a South Chicago plant where railroad cars are assembled. He’s been working at this company for 30 years. He moved to the U.S. when he was 5 years old and left school after 4th grade. Joe mastered every phase of the operations and massive usage of machinery between cranes to tiny monitors. He’s famous. What is shocking is that he takes a mindless activity to the next level and generates flow constantly. How do you achieve this? Change your perspective. Look for opportunities constantly. Make it a game. Alright, you’re wondering, how would this work for knowledge workers or educated people? Let’s talk about surgery and surgeons. In the book, a surgeon says that an operation is addictive, like taking heroin. On the other hand, surgeons could find it boring. There is an extreme balance between routine boring work and exotic, rare procedures that you may not be able to replicate. The outcome of the procedure is clear. The surgeon receives the feedback continuously. There are constant challenges. When the team are well-trained, everything flows like a ballet. Mihaly suggests that you design your work to achieve flow activities. You should help other people encourage the autotelic personality by training people to notice opportunities, sharpening your skills, and break down the smaller goals. Alright, that was the condensed version of the book Flow by Mihaly Csikszentmihalyi.
Developer Productivity for Humans Part 6, Measuring Flow, Focus, and Friction
For the next section, I’m going to talk about a blog article I found. There is a newsletter by a company. They’re called DX, but the website is getdx.com. The name of the article is Developer Productivity for Humans Part 6, Measuring Flow, Focus, and Friction for Developers. The article shares research on how to emphasize the human experience in measuring developer productivity. At the beginning, the authors pivoted from only flow and instead combined flow and focus. In this article, the reason this is important is because in the past, lines of code, code reviews, and tool usages like IDEs, they don’t really paint a whole holistic picture of the experience of coding, of putting our code into production. This article is really about trying to find out how do people actually do their work in a really big company with a lot of software engineers and doing their work. We’ll talk about a little bit of the summary of what they learned, and then I’ll talk about some of the things I thought were kind of interesting. For one, you should use surveys to understand the experience of software engineers. You should use logs-based signals that connect to the survey results, and then validate the metrics from that self-reported data. So the article is quite a large article, but I think there’s a lot of really interesting ideas in it. In the article, they used interviews, surveys, and diaries to express what flow, focus, and friction means to them, as well as how it experienced their daily work. When it was positive and toward completing their goals, developers felt flow. Flow could happen through writing code, responding to emails, crafting design plans, and reading documentation. While in flow, small distractions were not really that bad. There were a few interesting quotes I want to take away from here. In one quote, I have, humans achieve flow states if and only if they are doing focused work, but that they do focused work without achieving flow. So that was kind of interesting, this idea that you can be really focused on your task, but you may not be in flow, but you might be in the flow and be really focused. So I thought it was a really interesting idea, and I think at the beginning they pivoted because I don’t know that they could really focus on just the one idea of flow. So they really combined focus and flow. Another quote I liked was, there is more to flow for developers than staying immersed writing code in a single tool for long periods of time. And I think that’s kind of the whole point of this article, is that flow and focus are tasks that can happen throughout the whole process of building software. So it’s not just coding, it’s not just reading the code, but it could also be like interviewing people or it could be doing other tasks that are also related as the job requires. So what’s pretty interesting from this article is how they really tried to validate the data with the self-reported data and then also the signal-based metrics. So in one tool, they used Word2Vec in order to use natural language processing to group the time developers spent into the period of focus and unfocused work. Through this study, they performed a number of related actions at a given window of time, indicating flow or focus, whereas performing a number of unrelated actions indicated a lack of flow or focus. So I thought it was a really interesting way to do that. I think there’s a lot of interesting ideas you could take from this article and you could apply in your own day-to-day work. As they continue to validate this work, they use the diary data, they use quarterly survey data. The way that they used a diary was by noting down the tasks that they were going to complete and whether they were in flow or focus or not. And by validating this data, they were able to capture the focus and flow through the moment diary data and the across longer periods of time. So I think that’s a really good example of some great research. Another great quote I got was, we found friction was quite common in our sample of developers during the survey period. Developers reported friction on 77% of their days. That seems like a lot of friction, but maybe that’s pretty normal. At the end of this article, I don’t know that I really took away how friction is really understood by software engineers. I think it’s probably, this is really just the beginning of more research. But it was a really interesting article and I think there were a lot of great questions that came up at the end of this article about how can you measure the impact of calendar management and company-wide interventions? And then some other interesting other questions that came up. If a company decides they’re not going to have no meeting weeks, will that enable them flow or focus? Condensing meetings and focusing time blocks, is that going to cause better developer productivity? What workflows contribute to the most friction? What toolings improvements have reduced the friction? So there are a lot of really good ideas that we can take away from the research so far. We’re nowhere close to being done with learning how flow and friction impacts people, whether they’re software engineers or other roles. So in summary, set goals, be immersed, pay attention, and enjoy the experience of flow. And then consider using a diary to develop your metric on flow, focus, and friction in your day-to-day work. You can validate your metrics and self-reported data to double check. All right. Well, thank you everybody. I really appreciate you taking the time to listen to this podcast, reading the book, the book Flow, and then this blog article on developer productivity. Please let me know if you like this, if you want to give me feedback, please message me on X, Twitter, or email me on my blog. We’ll see you next time.