Unhappy developers

What makes developers unhappy?

""...you spend like 2 hours investigating on Google for a similar issue and how it was resolved, you find nothing, desperation kicks in." ~[2]

At most modern software companies building positive developer experiences is imperative to their success. How developers spend their time at work has a big impact on their happiness.

Dr. Schaffer pinpointed five essential "Flow" conditions for work satisfaction[4]. Below we list them and highlight how organizations inadvertently disrupt them:

1. Not Knowing What to Do → A lack of leadership vision and inadequate context provision hinder developers.
2. Not Knowing How to Do It → Developers struggle due to absent or disorganized documentation, ill-fitting tools, or misaligned team dynamics. The lack of centralized resources like developer portals can also amplify their cognitive load.
3. Not Knowing How Well One Is Doing → Slow or insufficient feedback loops obscure developers' understanding of their performance and the impact of their work.
4. Not Knowing What to Work on Next → The absence of clear daily or weekly plans and roadmaps leads to ambiguity.
5. No Freedom from Distractions → Excessive meetings, constant notifications, noisy work environments, and frequent context switches hamper productivity.

Ultimately, these factors transition a software developer from a state of perplexity., to worry and finally to anxiety. Fortunately, we can measure the level of happiness and quantify the cognitive load, enabling interventions to enhance their work experience.

For instance, consider the most frequent causes for developers to be unhappy[1]:

1. Stuck in problem-solving
2. Time pressure
3. Work with bad code

Given that problem-solving under tight deadlines is intrinsic to software development, why are being stuck in problem-solving and time pressure the most prevalent causes of unhappiness[1]?

Imagine a developer discovers a production crash due to a defect, requiring an immediate fix. They are acquainted with that segment of the system and commit to resolving it within a couple of hours. However, they soon realize that the defective code, written by another developer, is challenging to understand. This scenario exemplifies the "Not Knowing How to Do It" condition, where the developer, amidst the innate pressures of the job, may lack essential documentation or tools, thus intensifying their cognitive load.

While the repair was initially projected to take two hours, it now seems more like two weeks. This misestimation not only frustrates the developer but also subjects them to intense time pressures given their initial two-hour commitment. This is exacerbated as the entire organization feels the pressure, especially since the defect caused a production crash.

That leads to the third most frequent cause of unhappiness, which is to work with bad code[1]. Developers suffer when they encounter bad code that could have been avoided in the first place[1]. Such situations primarily arise from the "Not Knowing What to Do" condition. Often, when management, perhaps due to vision deficiencies, opts for short-term gains, it results in technical debt, or "bad code." This technical debt represents the "cost" a developer pays in terms of rework and frustration due to initial decisions made from a position of lack of knowledge or deliberate strategy.

Consequences for productivity

Researches found the following consequences of unhappiness while developing software[1]:

• Delays
• Low code quality
• Throwing away code
• Low motivation
• Low cognitive performance i.e. inefficient processing of information in the brain.
• Mental unease
• Work withdrawal i.e. a family of behaviors that is defined as employees’ attempts to remove themselves, either temporarily or permanently, from daily work tasks.

The external consequences, such as delays and throwing away code, have direct impacts on productivity. Internal consequences, such as low motivation and reduced cognitive performance, indirectly affect productivity as well.

If developers are unhappy then their human potential is underutilized which leads to low productivity.

How to make developers happy?

The key to developer happiness is enjoyment of everyday work. That is achieved by making sure the developers are in the state of Flow as much time as possible.

We can achieve that if we keep the challenges always a bit ahead of individual capability. Below is a diagram showing how to improve developer capability and keeping the developer in the state of flow all the time.

Let's assume the diagram represents the career of a junior developer through an expert. At the beginning there is no capability. We give the developer a simple task that is yet more challenging than their capability. After the task is completed the developer has acquired knowledge and improved capability abit. We give another task that is simple yet more challenging than the capability. After finishing it the developer is a bit more capable. We continue this way through time and eventually the developer is very much an expert. The most important thing is that this improvement journey was strictly inside the flow zone.

Nex it to manage the nature of the tasks a developer works on. Even though a developer's primary tasks *should* be coding and software design, many still feel they aren't getting enough time for deep work:. Developers spend most of their time designing, coding, and debugging, and would like to spend even more of their time on these tasks, instead of in meetings and on administrative tasks[3]. Thaus, we need to make sure developers don't spend time in meetings and on administrative tasks.

Making developers happy takes the discipline to let them focus on coding and software design.

Software developers start each task with a particular perplexity i.e. amount of missing information. Perplexity decreases in a disjoint fashion — with each learning episode, until at the end it is at another, lower level. In reality much of this learning is a function of the organization, and largely not managed and out of control.

To make developers happy and improve productivity an organization needs to reduce the level of perplexity software developers gace.

It is management's job to reduce their perplexity and the detrimental effects of time pressure and getting stuck. to a task that matches their level of knowledge. How to deliberately reduce the degree of perplexity is presented in Managed knowledge discovery