Very few programmers have never muttered some well-chosen words to themselves (or shouted them out loud, for that matter) about parts of their codebase. On the contrary, most of us probably recognize ourselves in the illustration and the metric WTFs/minute in the beginning of Clean Code. However, behind the humour of it all hides an issue we should all probably take a minute to consider. How much frustration are we subjected to when we code, and what are the consequences?
Far too few organisations – and far too few developers – ask themselves how code and emotions are connected. In spite of an array of colourful terms like big balls of mud, dependency hell and software rot, it's something that is rarely discussed. It seems we have accepted frustration and anger as a part of a programmer's day, and we appear to have resigned to this as a kind of status quo. At the same time, many of us have experienced how such feelings can be devastating for the operation, even from a technical perspective. My aim with this post is to inspire afterthought and reflection. It is time we started discussing the role of affective states (emotions, feelings and moods) in software development and begin making informed choices about how we want to handle them.
What does the latest research say?
The fact that frustration has an immediate and negative impact on developers is evident, according to dr. Daniel Graziotin among others, whose team is researching the connection between affective states and software development in the industry. Their studies contain statements that feel strikingly familiar; e.g., how the feeling of exhaustion can suddenly wash all over you. How frustration leads to mistakes or even short circuits your thought process and abilities. In some cases, the developers even state that they could not possibly continue, but had to shut down and try to pick it up again the next day. The frustration simply grew too large and spiralled out of control.
“If I feel particularly lost on a certain task, I may sometimes begin to question my overall ability to be a good programmer.”
Unfortunately, the situation is more serious than that. The same studies show that developers' discontent can take quite extreme forms: Some of them admit to having vented their anger by straight up deleting the code. Sometimes entire modules. Some say that they even left the company they worked for. To clarify, we are not talking about dissuasive examples or made up scenarios here; these feelings are a part of many programmers' everyday lives. Our everyday lives. And still we don’t pay attention to affective states.
We don't have time to wait
The situations above are not in any way hard to imagine. The question is not whether developers' mental state is affected by the codebase or not, we see far too many examples of that already. Neither is it a question about whether the product will be affected by negative feelings or not, that is also very clear. The question is instead why the situations arise in our organisations and how we want to handle them. How can we make a change?
These issues are complex and it saddens me that I don't have an easy answer. Complex issues rarely come with silver bullets, and the research area has not got the attention it deserves thus far. Another obstacle is the great variation between organisations, teams and individuals. At the same time, we cannot just put our heads in the sand. The effects are real. The costs do exist. Ignoring them makes everything worse. Instead, it's time that we developers take the lead and start addressing the problems. And the first step is to start discussing the issue. If not, it is just a matter of time before more modules reach the stage where developers won't even touch them with a ten foot pole.
Further reading
The question if or how our mental state affects our behaviour is a broad subject, and I cannot in any way cover it all in a single blog post. The subject has been researched for a long time in psychology as well as organisational theory and leadership. If you want to read more and get an introduction to some of the thoughts on the subject, I have provided links to a couple of works that I have found inspiring.
By Jesper Olsson