Q&A: How cognitive fatigue affects developer productivity

Writing code is mentally demanding work, and just like when someone did physically demanding work and then felt exhausted, mental work can be mentally exhausting. Many knowledge workers report feeling “cognitive fatigue” after a few hours, after which their ability to complete tasks decreases significantly.

Although most employees work 40 hours a week, experts say that most workers cannot do eight straight hours of deeply focused work every day because they would be mentally exhausted by the time they get to that point.

Recently on the SD Times podcast titled What Dev?we interviewed Hans Dockter, the company’s CEO Gradle,on the impact of cognitive fatigue on software productivity. Here’s a condensed version of that conversation:

David Rubinstein, SD Times editor-in-chief: Let’s start with what exactly does the term cognitive fatigue mean?

Hans Dockter: Cognitive science has discovered that there are two types of cognitive work. So the first one is learned, effortless procedures where you have inputs and outputs and there is fixed programming instead of how to go from input to output. You walk through the forest and don’t bump into trees, but you don’t study there, right? Another example is professional chess players opening a game. You can wake them up at 3 a.m. and they won’t make a mistake opening the door.

Then there is the second type of cognitive work, i.e. tasks requiring the so-called cognitive control. So you have input, you have a goal and you don’t know how to achieve it. Coming back to the professional chess player, at some point the space of possibilities grows exponentially and that is the beauty of the game. So it is no longer a routine that requires effort. Now you have to work really hard to win this match and then most often you win or lose. And when it comes to writing software, you need cognitive control.

Interestingly, a learned, effortless routine does not lead to cognitive fatigue. You can probably do openings all day long, you can walk in the woods all day long and you don’t feel like, oh, I don’t know how not to hit trees anymore; Your muscles get tired, not your brain. However, activities that require cognitive control lead to cognitive fatigue. And I think this is really noteworthy.

I think we are at the same stage in software development as we were in sports 50 years ago, i.e. no pain, no gain, the more it hurts, the better, right? Look at Lebron James and his afternoon nap. This is not because he is lazy, but because he wants to achieve the best results. And I think we still have an archaic way of looking at how the brain works when it comes to software, but it’s the same thing, right? You have to understand your body to be the best athlete you can be, and all of sports science has advanced so much that it has completely changed the game. That’s why LeBron is still one of the best players in the world at 39 years old.

DR: Interestingly, as we know, we work in industries where you have to think a lot about what you do. When I’m creating a story, I’m doing interviews, I’m asking questions, I’m thinking about things and learning, and at the end of the day I’m exhausted. And my wife says, what do you mean, you just sat and looked at the computer all day, how can you be tired? It’s cognitive fatigue! And you just want to rest for an hour and try to recover.

HD: What’s fascinating is that we have this experience and we have the conditions for it. “I’m fried,” “I’m mentally exhausted.” This is interesting because at the moment we only have hypotheses about a biological explanation for cognitive fatigue. So they did new research that showed that certain chemicals, like glutamate, accumulate, and when it reaches a certain concentration, the brain just doesn’t work well anymore.

DR: How to solve the problem of developer cognitive fatigue?

HD: First of all I would like to say when does the problem arise? And when is this not a problem? So if I work eight hours and after eight hours I’m completely cognitively fatigued, but it resulted in a lot of great code, then mission accomplished, rinse and repeat the next day. The problem is that many things that happen during the workday accelerate cognitive fatigue without leading to greater productivity. This is a problem and we have to solve it.

Some people talk a lot about the flow aspect. Context switching accelerates cognitive fatigue, right? There are a lot of experiments in psychology where you have to constantly change contexts, which is exhausting. And if you do it in order, you know, 10 exercises of this type, 10 of that type, you will be much more effective than doing one at a time. There is actually a lot of evidence behind this.

As software developers, we deal with a lot of unnecessary context changes. I’ll give you an example. Faulty tests. I think it’s very important to reflect on a fundamental truth about writing software: every line of code is a hypothesis. You can’t mathematically prove that this line does what it’s supposed to do. And that’s not how artificial intelligence will work. Let me repeat: AI also makes hypotheses, right? Physicists who have a theory about nature, what do they do? They conduct a dialogue with nature through experiments. A software engineer is in dialogue with a toolkit. Hey compiler, what do you think? Hey, unit tests, functional tests, security checks, etc. That’s why we write tests, right? Otherwise, the customer will have to express an opinion, which will often be negative.

Feedback can take five minutes, 20 minutes, an hour, or even many hours to provide, so the feedback cycle is long. And then you have to start working on something else, or you have to wait for feedback. Google has done some research that shows that developers wait for feedback cycles that last less than 10 minutes. Now think about it, right? People might say, “Oh you lazy people, wait,” but it’s actually a proactive strategy to avoid context switching and optimize productivity. Basically, they are saying that it is not worth paying for context switching, the mental cost of context switching, which requires changing neural patterns in the brain when you think about something else.

So the productivity strategy is to say, hey, the trade-off isn’t worth it. So if something takes nine minutes, you wait nine minutes, if something takes four minutes, you only wait four minutes. And if you can get it down to 40 seconds, you only wait 40 seconds.

If you ask most companies, say a Fortune 500, how many feedback cycles do your developers do per day? What is the average feedback cycle time? And how often do they fail? And what is the reason for failure? These are very simple questions and I guarantee that almost none of these organizations would be able to answer any of these questions. So they have no idea even the most basic things about what’s going on. From my perspective, when it comes to the entire complex development toolchain, we are where we were with web applications 20 years ago, before application performance management was introduced. You had no idea how often the shopping cart didn’t work, how long it took to complete the order, nothing. It would almost be a crime not to know this these days, but that’s basically where we are when it comes to the machines that software developers use.