Writing code is mentally intensive work, and just like if someone were working a physically demanding job and their body felt exhausted afterwards, mental work can be exhausting mentally. Many knowledge workers report experiencing “cognitive fatigue” after a number of hours, after which point their ability to do tasks significantly drops. 

While most workers work 40 hour work weeks, experts say that most workers cannot do eight straight hours of deeply focused work everyday as they’d mentally exhaust themselves before getting to that point. 

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

David Rubinstein, editor-in-chief of SD Times: To start us off, what exactly is meant by the term cognitive fatigue?

Hans Dockter:  What cognitive science has discovered is that there are two types of cognitive work. So the first is learned, effortless routines where you have an input and an output, and there is established programming in place of how to get from the input to the output. You’re walking through a forest and you’re not running into trees, but there’s no learning happening, right? Another example is professional chess players opening the game. You can wake them up at 3am in the morning and they will not make a mistake with the opening. 

And then there is a second type of cognitive work, which is tasks that require so called cognitive control. So you have an input, you have a goal, and you don’t know how to get to that goal. Going back to the professional chess player, at one point, the space of possibilities grows exponentially, that’s the beauty of the game. So it’s no longer an effortless routine, now you have to really work hard to win that game, and that’s where you win or lose the game most of the time. And when it comes to writing software, you need cognitive control.

The interesting thing is that the learned effortless routine is not leading to cognitive fatigue. You can do openings probably all day, you can walk through the forest all day and you’re not like, oh, I can no longer figure out how not to hit the trees; your muscles get fatigued, not your brain. But activities that require cognitive control, they lead to cognitive fatigue. And I think this is really really noteworthy. 

I think we are with software development where we might have been with 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’s lazy, it’s because he wants to be at peak performance. And I think we’re still in an archaic way of looking at brain work when it comes to software, but it’s the same thing, right? You need to understand your body to be the best athlete you can be, and all the sports science has evolved so much and it has completely changed the game. That’s why LeBron is still one of the best players in the world at age 39.

DR: Interestingly, so you know, we work in industries where a lot of thought has to go into what you’re doing. When I’m crafting a story, I’m doing interviews, coming up with questions, thinking about things and learning, and at the end of the day, I’m exhausted. And my wife is like, what do you mean, you just sat around all day looking at your computer, how can you be tired? It’s that cognitive fatigue! And you just want to zone out for like an hour and try to recover.

HD: The fascinating thing is we have that experience, we have terms for that. “I’m fried,” “I’m mentally exhausted.” And it’s interesting because at the moment, we only have hypotheses for the biological explanation for cognitive fatigue. So they did some new research that showed there are certain chemicals that are accumulating, i.e. glutamate, and when this has reached a certain concentration, your brain just doesn’t work well anymore. 

DR: How do we solve the problem of cognitive fatigue for developers?

HD: So first of all, I would say, when is it a problem? And when is it not a problem? So if I work eight hours, and I’m completely cognitively fatigued after eight hours, but that resulted in a lot of great code, then mission accomplished, rinse and repeat the next day. The problem is that a lot of stuff that happens during the work day accelerates cognitive fatigue without leading to more output. That’s the problem, and that’s what we have to solve. 

Some people talk a lot about the flow aspect. Context switching accelerates cognitive fatigue, right? There’s so many experiments in psychology where you continuously have to switch contexts, and it’s exhausting. And if you will do this sequentially, you know, 10 exercises of this type, 10 of the other, you are much more effective than doing one at a time. There’s really a lot of evidence behind that. 

As software developers, there is a lot of unnecessary context switching, and I’ll give you an example. Flaky tests. I think it’s very important to reflect on a fundamental truth about writing software: every line of code is a hypothesis. You cannot mathematically prove that this line is doing what it’s supposed to do. And that’s also not how AI is going to work. Again, AI also makes hypotheses, right? A physicist that that has a theory about nature, what do they do? They have a dialogue with nature via experiments. And the software engineer has a dialogue with the toolchain. Hey, compiler, what do you think? Hey, unit tests, functional tests, security checks, etc. That’s why we write tests, right? Otherwise, the customer has to give feedback, and it would very often be negative.

The feedback might take five minutes, 20 minutes, an hour, many hours, so you have a long feedback cycle. And then you have to start working on something else, or you have to wait for the feedback. Google did some research that developers for feedback cycles that take less than 10 minutes, they wait. Now reflect upon that, right? People could say, oh, lazy guys wait, but this is actually an active strategy to avoid context switching and to optimize productivity. They’re basically saying, it’s not worth paying the context switching, the mental cost of context switching, which requires you to change the neural patterns in your brain when you think about something else. 

So it’s a productivity strategy to say, hey, the trade off is not worth it. So when something takes nine minutes, you wait nine minutes, when 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, let’s say Fortune 500 companies, how many feedback cycles are your developers running per day? What is the average time of a feedback cycle? And how often do they fail? And what is the reason for the failure? Those are very simple questions, and I guarantee you, hardly any of those organizations could give you an answer to any of those questions. So they don’t even know the most basic stuff of what’s going on. The way I look at it is where we are with the whole complex developer tool chain is that we are at a point where we were with web applications 20 years ago, before we had application performance management. You had no idea how often the shopping cart is not working, how long the checkout takes, nothing. Nowadays, it would almost be like a crime not knowing that, but that’s where we are basically when it comes to the machinery the software developers are using.