We feel our best and do our best work when we can completely focus on what we’re doing and apply our full abilities to a task. That feeling is called the flow state, and it requires both a task worthy of your skills and the focus to apply them well. For software developers, accessing the flow state can be the difference between quality software and buggy code. On this sponsored episode of the podcast, we chat with Marcel Twohig, Head of Design for the MX Series at Logitech, and Thomas Fritz, Associate Professor of Human Aspects of Software Engineering at the University of Zurich. This episode is the second in our four- part series presented by Logitech. We cover the research that Professor Fritz has done on flow states, the design work that Marcel and team have done to incorporate that research, and the tools that you can use to maximize your daily flow.
If you’re interested in diving deeper into Professor Fritz’s research on developer flow states, check out his list of publications.
Flow states can be affected by things as simple as the right lighting, so Logitech created keyboards that automatically adjust their keyboard backlighting.
Lights can be used to indicate your interruptibility.; Prof. Fritz did some research on FlowLight, which indicates your willingness to be interrupted with a simple red light/green light protocol. These days, you can use your Slack status to the same effect.
If you’re looking for apps to improve your daily flow, Cassidy recommends Centered.
[intro music plays]
Ben Popper Hello, everybody. Welcome back to the Stack Overflow Podcast, a place to talk all things software and technology. I'm your host, Ben Popper, Director of Content here at Stack Overflow, joined as I often am by my wonderful colleagues and collaborators, Cassidy Williams and Ryan Donovan.
Cassidy Williams Hello!
Ryan Donovan Hey!
BP Hello! We have a very special sponsored episode today from Logitech, part of the series we're running this month. It's going to focus on three topics that have come up on this show several times organically– flow state, developer productivity, and Cassidy, mechanical keyboards. So we're very excited for today's episode, and I guess the intersection of those three things. So without further ado, I'd like to welcome Thomas and Marcel from Logitech to the podcast. Hello to you both.
Thomas Fritz Hi guys.
Marcel Twohig Hi there.
BP So Marcel, let's start with you. Can you just tell the audience quickly sort of who you are and what it is that brought you to the role you're at now?
MT Yeah. My name is Marcel Twohig. I'm an industrial designer originally. Currently I'm the Head of Design for the MX Group at Logitech. I've kind of been around the block as an industrial designer. I had my own consultancy for a good number of years through which I ended up consulting with Logitech and eventually they kind of got me on the end of a line and reeled me in and I'm internal now, and it's kind of a really exciting place to be doing the MX products because they’re Logitech’s flagship mice and keyboards and we get to introduce a lot of the new technologies.
BP Yeah, that makes a lot of sense. Cassidy, we've talked about this before, but in speaking with developers here at Stack Overflow and with folks on the show, people will often express the idea that if they can get to flow state and spend a good two or three hours in one day, that's way more impactful than an eight hour jag where they're not feeling focused. I don't know, do you have personal experience with this?
CW Yes, 100%. To the point where I will schedule time to try to get into flow state just so that way I can do it. Because when I am in that period, and I don't even say, “It's time for me to flow,” but when I want to get down and focus it works so effectively that it is worth it for me to schedule that time because I can get more done in that chunk of time than I can multitasking at some point.
BP Right, right.
MT I guess as I understand it, it's one of these things that you can't decide. And correct me if I'm wrong Thomas, I guess you're the expert on it, but in what I've read it’s one of these things that you can schedule time for but whether or not it's effective is kind of determined by a few things that are out of your control or are loosely in your control.
CW Right. And I guess we should introduce Thomas then.
BP Yeah, Thomas, tell us who you are and why Marcel thinks you're some kind of expert on this.
TF Thank you for that. So I’m Thomas. I'm an Associate Professor at the University of Zurich and I actually work on human aspects of software engineering and software development. So we look at software developers and how we can actually foster productivity at work. So mostly for software developers, but also in a broader sense, for knowledge workers or information workers. In particular, we look at how we perceive our own productivity as software developers and how we can possibly measure some aspects of that in terms of the cognitive states, in terms of the emotional states, and then how we can build support tools to really foster that productivity at work. And so maybe now coming back I'm not sure if I should right away chip into it, but talking about the flow, I do believe that you can’t necessarily plan for it. It's good to have certain habits and certain rituals to sort of try and get into a focus state, but that flow state that we sometimes talk about, that sort of occurs to us. So obviously it's good to put the work in there. If you don't sit in front of the computer– Marcel made a really nice quote before and then I forgot the quote, but just talking about obviously you have to sit at the computer so that you actually get into the flow at your work. Without being there it doesn't happen. If you're just always off the computer it's not going to happen.
CW There's this app that I use called Centered that is designed to help you get into flow state, and I'm sure that there's plenty of those apps out there. But you put in your tasks for the day and you can say how much time you want to allocate for those tasks, and when you hit start it plays that binaural music and there's a little voice saying, “Okay, let's flow,” and then whenever you are about to lose focus, like if I were to go on Reddit or something, it'll say, “Hey, make sure you stay on your task,” and so that little verbal thing keeps you focused. And even though at first I admit I kind of resist it, it works for me. And that might be one of those things where not everybody can schedule flow state, kind of like what you said. But if you have something that helps you get there, that is in particular a tool that helps me.
BP For sure.
RD I mean, I feel like I'm always chasing flow state as well. But Thomas, you do the research on this sort of thing. I'm curious what the actual data that you've gathered says about getting into flow states.
TF So we didn't look specifically at the state of flow. We mostly look at how do developers themselves perceive their own productivity and when do they perceive themselves as productive. And trying to understand that one because then we can actually help them to also be more productive. But what we look at in terms of productivity is trying to understand when are developers most productive? What are activities that make them feel productive? And what are the times as well, because we see that different developers have different sort of curves of productivity. So we did a study where we looked at developers rating their own productivity every hour or every half hour and we just looked at it and there’s some people that are more productive in the morning, and then some people that are more productive in the evening, and then some people that sort of had this really low lunch phase. And based on that understanding of your own productivity you can then obviously also go ahead and, as Cassidy mentioned, schedule those two to three hours, but try to hit one of those spots where you know that you're more productive generally.
MT So a summary that we did before on it, because again, we studied this as a way of developing products for our users. We had kind of three things. So as Thomas was just talking about, there is this idea of task modulation as to get the right balance between challenge and effort. Because if it's not challenging enough you get bored, and if it's too challenging, well then you get disillusioned. But there's two other elements as well. There's something that we are calling ‘intrinsic reward’ whereby the people who are conscientious about the work they do tend to get into flow state more. And this is why we see software developers and creatives talking about flow a lot as part of the way they work, because you kind of really want to do a good job. There's something about software developers and about getting to the best code you can. It's not about just doing the job. So that idea of intrinsic reward and being conscientious and knowing that fulfillment of when the job is done. And then the third one, and I guess the third one is the one that Logitech will focus on most is about eliminating distractions. You're never going to get into flow state unless you can eliminate distractions. And what we try to do is to look at the tools that you're using, and this flow state exists for sports people and musicians, et cetera, and all of them are reliant on tools. And just like that for software developers– the tools that you use, your keyboard and your mouse, your computer and the software, the various apps, if you can design those tools so they minimize or eliminate distractions then you're less likely to get broken out of the flow state.
BP Right. Yeah, I've heard people talking about flow state recently in the context of sports as well. Somebody is in the zone, they're in the flow, and this can come and go. And you kind of hear the opposite, that somebody has a mental block, they were a great baseball player but now they can't make the throw from third to first. They call it the ‘yips’ or whatever. They're in their own head. So to me it sounds like sort of an ineffable thing– you can't say I'm going to have it, but you can put in place the structures and you can do the practices and you can have the tools to sort of maximize your chances. So let's take this back for a second. When you look at developers and the tools that they're working with, most principally the keyboard, were there specific things you found that took them out of flow state or made it less likely? And then, what were you able to do through design or through research to create something that would help them ideally achieve that outcome more often?
MT Yeah, I think again, it's very small things. We found, especially with software developers, that they tend to have more than one device in their workflow. So in the past we would've designed for just using your desktop computer, but now we find you have a desktop computer, and a laptop, and an iPad, et cetera. So from that research, we found that people switching between them is painful and we developed this software called Flow where you can drag and drop across different devices as if they were connected, just using the mouse and keyboard. They’re very little things, and even something as simple as backlighting. So we have light sensors in our keyboards so they automatically detect the ambient light and they adjust the backlighting accordingly so if you're in a flow state, again, Thomas this is your area, but I believe your prefrontal cortex shuts down so you stop noticing things around you. Well, it doesn't shut down completely I guess, but it recedes and you stop noticing things like that actually it's gotten dark out. So we have things like automatic backlighting so your keyboard will adjust so you don't have to think about it. And I'm sure we've all experienced that where you get into a flow state and you're really excited and then you look around and it's gotten dark or whatever and everybody's left the building.
BP Right, right.
TF And maybe I can follow up because you also asked about the research that we do. So when we talked to software developers we ran surveys, we did observations, and we actually also had them install applications on their computers to track everything that they did. And one of the first things that came out is that developers feel super productive when they make progress on task, which is not very surprising, but it also said when there are very few context switches. And now the question is, what is a context switch? So we observed them and we looked there and we actually looked at the numbers, and really what happens is they switch every four minutes to a different task, they switch every few seconds or every 60 seconds to a different activity, to a different application. And so sometimes these context switches can be very productive. So for example, as a developer when I'm starting up a test server and it takes a while to start up, I can just fire it off and then wait and then do something else while it's getting ready and therefore be more productive by switching back the context. But sometimes when I'm super focused, let's say I'm debugging something in my code trying to understand what's going on, and a coworker comes in and asks me a question about the weekend, how was the soccer game or something. That really pulls me out of that context that I was in and that really takes me away and that costs a lot of time to get back in. Actually there's research that shows that it causes more bugs in the end, costs a lot more time, not just time to get back in but to complete that task. And so I've been looking into how we can actually measure that cost of a context switch? Is it possible to measure that, how difficult, how expensive is it at any given point in time to switch and how is that? And one of the things that we have to think about at that point is obviously there's interruptions that we usually think of as external interruptions, but interruptions can be both. There can be internal interruptions– I can interrupt myself. So like as Cassidy mentioned, going over to Reddit and reading something, distract myself. Or I have the external interruption by somebody else. And both of these distractions are things that impede my productivity in general, so how can I help developers in the end? So one of the things is we use some biometric sensing to try and understand how interruptible, is what we call the baseline, how interruptible a developer is at any given point in time. And then we also used a less invasive sensor such as the keyboard or the mouse and trying to understand which applications people use. Because you can imagine for developers working and debugging and stepping through all the things and trying to execute a program and stepping through the break points, at that point you know that developer is really focused on it, and it might not be a good point in time to interrupt that person. So you can tell from these things. And then we developed an algorithm underneath that tries to capture that as much as possible, just based on keyboard and mouse. We developed a lamp that changes color. It's like a traffic light and we deployed it with 400 people. So the traffic light or the little lamp, the USB plug-in LED lamp that we put next to computer desks changed the color when we detected that they were now more focused based on the keyboard and mouse interaction. When we had that with ABP at the time with 400 people, we noticed that the numbers of interruptions actually went down and people thought that they were more productive, for two reasons. One of them is because people are a lot more aware of the cost of interrupting somebody. So thinking beforehand about if I should interrupt that person or not, and if I see a red light is it really necessary at this point or not? And that's one of the things. The other thing that we also noticed is what people did is they pulled it from the side right in front of them and thought, “Okay, it's really cool to see sometimes. I want to be in the red state today. I want to be productive.” Or if they were in the red state, “I want it to stay in the red state and I want to be in there.” So it also helped with that one. So it's sort of like this promotion of getting something done and feeling good about it at the same time. So that's just some of the research that we did, from trying to understand what it means to be reproductive, measuring it a little bit or aspects of that, and then trying to support developers in their work and improving that.
MT I love about the flow state, if you read the original books and things, it goes beyond productivity and I think it kind of mirrors maybe some of our approach in Logitech as well, in that we started out very much with productivity, but the more we spoke to users and the more we understood how they work, you actually get a kind of high out of getting into the flow state and it actually makes you feel really good. And in actual fact, the original research by, I'm not sure about the pronunciation, but he didn't start out looking into productivity. He started out looking into happiness and his research was around happiness first. And it turns out that when you're completely focused and immersed in a task that you deem to be a worthy task then this puts you in the happiest state that you'll be in. And I think there's something really nice about that in terms of feeling good about the work you do, in that we're not just creating productivity tools to make companies more money and make people work harder, we're trying to actually make people enjoy the work they're doing.
BP Yeah.
CW It reminds me of an article I saw about the science of fun, and they looked at video games and stuff and they were saying some of the most addicting video games are the ones where it kind of feels like a little bit of work, but you still get enough achievements and satisfaction that you get fully immersed in it, and afterwards you're just like, “Man, that was a great time.” And it's a very funky balance where you’re working, but you're working in a game and it's fun and addictive.
RD The best games are a really good job.
CW Yeah.
BP There's a great quote from Mike Tyson and he was talking about his career and why he was successful when he was young and what happened to him as he got older, and he said something along those lines. It was like, the most dangerous fighter is a really happy fighter. Somebody who goes in with no distractions, who wants to be there, who gets lost in the moment, just is completely present. So it’s interesting to think about that applied to all these different things. So I guess one of the things that I wanted to touch on here was the idea of creativity, sports, art, programming. And there was a note in here, Marcel. “The world has changed from the Victorian idea of head down to more open-minded.” So it's interesting because we're talking about how we want you to be happy at the computer. You'll be at the computer for three hours and won't realize it's gotten dark. How does that square with the more open-minded and creative notion? Put those two things together for me.
MT Well, we have this what we call innovation framework which is just some principles around when we're innovating on any product what we're trying to do. And the first one is to keep our users in the flow. The second one is something we just call ‘speed of thought’, and again, it comes from research and talking to these users, that they want to express their ideas on screen as quickly as possible. They almost want to think it and it happens. And so that's another way that we try to design our products. And then the third part of it is just environmental. I think more recently people are much more interested in their workspaces feeling creative. And Cassidy, you're doing a better job of that. But I think these three things come together really to enable people to be more creative, not just productive. And again, we all know that the less time you spend on the dog work of churning and processing the more time you can spend on the creative work and the interesting things and where ultimately you're adding more value. I guess that's the thing. Again, we want to move everybody from doing a job to creating the future. But I think on that specific thing around this idea of being happy in work and fulfilled in work, and wellness, I believe Thomas you had some interesting ways that you've repositioned it when we were speaking last.
TF Yeah, so basically, most software developers or companies ask us how we measure productivity, and mostly it's this idea of output oriented something, but that just doesn't work today anymore. As you mentioned, developers are super creative, the tasks are cognitively demanding, developers have a lot of autonomy to work on their things, and it's a question of how do you measure that and do you want to measure that? So what we've noticed is that, if you think about output, there's no one best metric for any developer. Everybody has different ideas of what would be a good metric, what would be good for them to measure, and it's mostly never for a manager to measure developers. It's mostly for the developer themselves to understand themselves for where we can put together metrics. But what we thought about was going a little bit further. We call it ‘time well spent’. So we have a measure where we ask people every day or every hour to also reflect on time well spent, and what we noticed is that this slight shift of thinking about your work also creates a shift in their mind. So it basically brings them a way of just thinking, “I have to be there. I have to always be on my computer. I have to answer my email super quickly,” to thinking about, “When do I spend my time well?” So it might actually be a lot more productive to take a power nap in the afternoon, and once I take that power nap, afterwards I might be way better off and way more productive. So I think a little bit outside the box and think a little bit more holistic about productivity, but it also brought this emotional component into it that I thought about as like, what makes fun, what is good, when do I have fun at work, and when do I feel the best at work? And that really helps them to in the end be more productive, but overall to really spend their time better at work.
RD That's interesting. That's definitely something I've read a bunch about and we’ve published about developer productivity and it seems like any time you pick a metric for individual productivity that metric gets gained. That becomes a thing people shoot for. And I think the thing that I've seen people go for is sort of team metrics, team productivity. Have you seen anything around that or done any research around that?
TF Yeah, so we just recently completed a second study with a big bank but also before with other companies where we gave them Apple Watches or Samsung Watches and had them rate every hour their own productivity, but also think about their team and how productive their team is. It’s really difficult to measure teams. So it's tricky because everybody says, “Oh, let's use User Stories or Jira Task,” and measure the run down and so on. But then when you talk to the teams, everybody says, “Yeah, this is not really a good indicator. We use it for our meetings in the morning but we don't use it to really keep track of the productivity.” And so it becomes a lot more tricky to measure that. Obviously what we noticed in these studies is, the first thing is teams are very volatile and fluid, so they change a lot. So even though the team said, “Hey, we signed up together. This is the team of nine people.” Afterwards we had them get the watch and they rated it and they were asked how productive is your team, and they were like, “Which team do you mean?” It's like, “Well, we had a meeting with your whole team, you mentioned that this is your team, I'm assuming that's your team.” But so even this one is difficult. And the other thing that we also explored with one of the psychologists at our university together is trying to think about how does it make us feel thinking about the team? So quite often we saw that when we asked them about productivity they thought, “Oh, today I wasn't as productive because I had all of these interruptions by my teammates and I had to help them.” And funny enough, that also obviously increases the team productivity if I help somebody. And it’s sometimes this framing in my head, so we try and see if we can change that framing a little bit and ask about how your team has helped you instead of asking how do you help your team, to really think about if that can improve my assessment of the team. But in general, coming back to you, team productivity is really difficult to measure and there’s not one single thing to measure it. But what companies sometimes now go for and I think is promising is to look at what is the value that we put out to the customer and then track it back to the steps that the developers do, but that's not quite as easy for every software development team. For some it's a lot easier to track that back, for some it's really, really difficult.
RD Yeah. In an interview I just had, somebody said these individual metrics are sort of like tracking GDP for the economy. It's going to give you a very specific view and not give you a view of the overall health.
TF Yeah.
BP Yeah, I think this is really interesting. We were talking recently with a company that focuses on matching engineers from a very global perspective outside the US with big companies, the Pepsi Co’s and Disney’s of the world who are looking for engineers. And that sort of IT outsourcing is not new but what they said has changed a lot is that it's no longer like fitting cogs in, like we have this massive digital transformation project and we're going to give each of you one sort of assignment to crank on. They're looking for people who have a track record of successfully completing projects and then the results of those projects. So as you pointed out, how do you measure developer productivity? It can be difficult, but you could say in hindsight at least, we were able to find solutions here and those solutions were able to deliver impact, so maybe that's something we can bring to the next company. That might be writing more code, it might be writing less code. Do you know what I mean? It's hard to quantify in a certain way, but it’s interesting to think that companies are also moving to view developer hiring in that way.
TF It is really interesting, and it comes back to what Ryan said. In the end, whatever you put on the dashboard or whatever you put in that CV or whatever to hire, that will be gained. So if I say, “How many projects,” and people will go on GitHub and do 20,000 different open source projects and say, “I completed them all or I contributed to all of them,” but it doesn't mean that the quality is high. So then it becomes difficult to measure again. In the end I think obviously you have to have your own metrics. So what we also looked at, maybe one thing that I missed before, one of the starting ideas with the productivity is trying to think about how can we bring the Fitbit or the step counter into the workplace, into development work. Because if I see that step count that I have 10,000 steps, I feel super good and I really want to always achieve those 10,000 steps. Is there something in the development domain? And what we noticed is, as I mentioned it’s very, very individual, but what really helps is that developers have these things where they monitor themselves, they reflect on that, and then they set themselves goals. So one of the biggest contributions we always make with our research when we go into companies is they say in the end, “Oh, it's so nice that he forced us to participate in the study because it forced me to reflect for two weeks on the work that I did and it really helped me to understand what it is.” And these goal settings, like having, as you mentioned, possibly project completed, success, value to customers or something, tracking that and helping to understand your own work is really a thing that also motivates them to then work even more and be more productive.
BP Cool.
[music plays]
BP All right, everyone. Thank you so much for listening. As we always do, I will shout out the winner of a lifeboat badge: someone who came on Stack Overflow and helped rescue a question and shared some knowledge and spread that in our community. So thank you to Stijn de Witt. Awarded two days ago, “How can I predict Math.random results?” No, that's the point. You can't– they’re random. I'm not sure. Maybe he has a good answer for it. I am Ben Popper. I am the Director of Content here at Stack Overflow. You can always find me on Twitter @BenPopper. You can always email us with questions or suggestions, podcast@stackoverflow.com. And if you like the show, leave us a rating and a review. It really helps.
RD I'm Ryan Donovan. I edit the blog here at Stack Overflow. You can find me on Twitter at @RThorDonovan. And if you have a great idea for a blog post, please email me at pitches@stackoverflow.com.
CW I'm Cassidy Williams. I do developer experience at Remote and OSS Capital. You can find me @Cassidoo on most things.
MT I'm Marcel Twohig. I'm Head of Design for MX at Logitech. You can find me on LinkedIn, I guess. And if you want to know more about MX and Logitech, just visit Logitech.com.
TF I'm Thomas Fritz. I'm an Associate Professor at the University of Zurich, and I lead the Human Aspects of Software Engineering Lab. And a big part of the work that I talked today about is done by my students, in particular by André Meyer, Anastasia Ruvimova and Alexander Lill, and also in collaboration with Gail Murphy from UBC and Tom Zimmermann from Microsoft Research. And if you’re ever interested in any of our research or even want to participate in any of our studies, you can find us at hasel.dev. Thank you so much.
BP Terrific. All right, everybody. Hope you find your flow state this week, and thanks for listening. Bye!
CW Bye!
[outro music plays]