""...you spend like 2 hours investigating on Google for a
similar issue and how it was resolved, you find
nothing, desperation kicks in." ~
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.
Below we list them and highlight how organizations inadvertently disrupt them:
Not Knowing What to Do → A lack of leadership vision and inadequate context provision hinder developers.
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.
Not Knowing How Well One Is Doing → Slow or insufficient feedback loops obscure developers' understanding of their performance and the impact of their work.
Not Knowing What to Work on Next → The absence of clear daily or weekly plans and roadmaps leads to ambiguity.
No Freedom from Distractions → Excessive meetings, constant notifications, noisy work environments, and frequent context switches hamper productivity.
For instance, consider the most frequent causes for developers to be unhappy:
Stuck in problem-solving
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?
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.
Developers suffer when they encounter bad code that could have been avoided in the first place.
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:
Low code quality
Throwing away code
Low cognitive performance i.e. inefficient processing of information in the brain.
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.
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.
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
1. Graziotin D., Fagerholm F. (2019). Happiness and the Productivity of Software Engineers In Sadowski C., Zimmermann T. (Eds.), Rethinking productivity in software engineering (pp. 251–259). A Press. https://doi.org/10.1007/978-1-4842-4221-6
2. Graziotin, Daniel; Fagerholm, Fabian; Wang, Xiaofeng; Abrahamsson, Pekka (2017): Slides for the consequences of unhappiness while developing software. figshare. Journal contribution. https://doi.org/10.6084/m9.figshare.4869038.v3