I love being a programmer. I enjoy thinking about and developing complex systems, juggling the needs of the user, my employer, and my team. Working closely with my team, constantly communicating with stakeholders, and asking for input from (potential) users are essential and valuable parts of the software development process.
But some days or weeks leave me with a feeling of pure exhaustion. And it is a type of exhaustion that is more of the mind than of the body.
Let’s contrast this with the feeling of a tired body after hard exercise or labor. As a programmer, I only get to experience this in my free time, when I have spent the day digging a giant hole for a fish pond, laying tiles, or on a long hiking trip. In the evening, I would also feel exhausted, maybe sore or in pain, but at the same time strangely great. I know what I have done that day. There might be a visible testament to my efforts - a container full of sand, a room with an almost professionally tiled floor, a 14km trip tracked in Komoot. I feel exhausted, but it is mainly my body that is exhausted, while my brain is high on a cocktail of feelings like pride and relief that it is over.
This is different from the fatigue I will feel after a long day of work with lots of meetings, constant context switches, fires to fight, and problems to solve. In the evening, I will be exhausted, but it is a totally different feeling. These days don't leave me with the same satisfaction. Many topics with a tiny bit of progress on each do not feel like an accomplishment. To feel successful, I need focus: Enough time to reach a state of flow where everything feels almost effortless. I can suddenly model a complex problem in my mind, solve a technical challenge or just let the code flow into my IDE.
If I can reach a flow state, or what some people like to call “the zone,” I can get much more done in a workday and feel less tired afterwards. This is why I try to create the circumstances that support the flow state.
On the other hand, mental exhaustion and stress can lead to burnout in the long run. In the short term, they can reduce the value of my free time because I lack the energy to do the things I love after work.
Those are more than enough reasons for me to try and reduce the mental exhaustion caused by work.
But what can I do to look after my brain? It is pretty obvious how to reduce the strain on the body in most situations: There are many tools built to do exactly that, from power tools to heavy machines and cars. And there are also tools to alleviate the mental strain that I want to share with you, but let’s first understand what causes the fatigue.
I have observed several factors that cause me to feel mentally exhausted. Some factors are caused by the requirements of my job and the work environment:
Almost all of these problems are partially outside of my control and can only be improved over time with a lot of effort, e.g., by constantly bringing up the topics in retrospectives, convincing colleagues to communicate differently, and enhancing the stability of systems.
Luckily, one significant contributor to exhaustion is more under my control, and that is the cognitive load from coding itself.
I have found ways to reduce the cognitive load from programming and, consequently, mental fatigue after a workday. The following tips are based on my personal experience and work for my brain - but they might help you too!
I try to take some blocks of time, e.g., after a meeting when I am out of “the zone” anyway, to check emails, slack messages, and other notifications. I answer the quick ones immediately and put others as to-do items on my list if I consider them less of a priority. I can then return to my current coding task and ignore incoming messages for a while.
Suppose I can also try to work on one task at a time and not multiple in parallel. If I have finished a pull request and need to wait for a review, I might use that time to tackle some smaller tasks on my to-do list or do some code reviews myself. This way, I can hopefully fully finish one story before moving to the next with full focus.
When writing code, I also try to focus on one thing at a time. If I have an idea or an important thought that is not directly related to what I am doing at the time, I write it down as a TODO comment. That way, I don’t need to be afraid to forget it, but I can immediately return to what I was working on and then pick the next thing from my “queue” of TODOs.
Often context switching can not be avoided in today’s software development process. To reduce the negative effect on my productivity, I do what I can to make it easier to continue where I left off before an interruption.
While coding, that means taking as many “notes” as I can:
And to make it easier to get going in the morning, I always take a few minutes at the end of the day to make a small list of the things I need to do the next day. When I return in the morning, it is easy to get started again - even if I am still a little tired, because I don’t have to think about what I should do.
I like to use sketches and notes on paper to think about programming problems. I prefer non-digital options because I can focus entirely on the problem, with less distractions, and I can think more visually: Having an immediate, effortless connection between my thoughts and what I put on the page makes that so much easier for me than fighting with any digital tool for visualization to get arrows where I want them.
Digital tools are also handy, but for me, they work better as a second step. I prefer to use an analog medium for the first draft where I can just start modeling something before I have any idea what the best type of visualization might be - a sequence diagram? A flow chart? Simply a table?
Mental overload is not only a problem for you, but your co-workers likely face the same struggles as you! One way to support them is to make it as easy as possible to review your code (assuming you follow a process with pull requests & code reviews). The first step to create an easy-to-read pull request is to make it as small as possible. Try to focus on one issue per pull request and if that topic contains many changes, try splitting it into multiple steps. It also helps to give a good description to provide context and explain your reasoning. And I also like to add comments to point out particularly interesting changes or might cause questions. To help them understand better what I have done and why I also offer to walk them through my bigger pull request.
I try to remind myself regularly to follow my advice because I have observed that it helps me to reduce my cognitive load. There are still days when I never manage to experience a flow state because there is too much going on, too many interruptions, too many different topics, and not enough focus time.
Have you found any other strategies to reduce the cognitive load from coding and the whole software development process? I would love to hear what works for you!
Sarah Wachs is a software developer from Berlin with more than 4 years of professional experience. Currently she is a consultant at Netlight and supports companies to develop high quality software solutions and a healthy culture. In her free time she organises events with Women Who Code Berlin, an international network to support women to thrive in IT careers.
She believes that software development is a team sport and that more time spent with whiteboards and sticky notes leads to better solutions in the long run.
.png)
.png)
