“Software Developer Happiness” is a concept that has gained popularity among engineering leaders. In a software-is-eating-the-world era, the creators of that asset need to be productive. And there’s strong evidence that happy software developers are indeed more productive.
So, how do we measure and increase software developer happiness?
Some studies, such as this one by Honeypot, take a very broad perspective on developer happiness including criteria such as career, quality of life, and even social freedom.
Broad criteria are not helpful for engineering leaders looking to take immediate steps to improve developer happiness. In this blog, we highlight factors that:
- Engineering leaders can directly and immediately impact to improve developer happiness
- Are measurable in some form to bring objectivity and can also be tracked over time.
Modern engineering leaders must add the ability to measure and track developer happiness to their talent stack. They can proactively recognize situations that may lead to developer unhappiness and take appropriate steps. These factors can be segmented into two buckets – ones that impact productivity and the softer human factors that also indirectly impact output.
Let’s walk through these.
Productivity Factors
These are factors that directly impact the work output, which in turn impacts a developer’s happiness.
1. Sustained Maker Time
This is a key factor that contributes to software developer happiness. Maker time refers to the time the developer is able to spend coding and creating software. Increasing maker time is a straight path to increasing developer happiness.
The longer and sustained periods they are able to spend coding, the happier they are. Organizations naturally focus on an easy-to-use IDE (Integrated Development Environment) coupled with a strong and automated CI-CD (Continuous Integration-Continuous Delivery) pipeline. These tools support the developers’ primary activity. And many organizations have already established a well-developed version control and CI-CD framework.
However, there are many more factors that are either ignored or unseen. Engineering leaders looking to put distance between their organization and the competition pay close attention to these additional factors.
A fragmented coding time interrupted by non-coding tasks has the opposite effect. It causes aggravation and frustration leading to unhappiness. Engineering leadership must create conditions that reduce interruption from non-coding tasks, context switching, and back and forth across multiple tools to complete their work.
2. Reduce Communication Overload
Developers communicate with other organizations to ensure that code delivers to requirements. Specifically, these communications will involve Product Management, Quality Assurance, and Security teams. Excessive or avoidable communication with these teams creates interruptions to work and impacts developer happiness.
Typical reasons for excessive back and forth on these interactions are:
- Imprecise or confusing product requirements
- Lack of quick responses leading to additional reminders
- Scope creep due to late-stage product requirements
- Lack of agreement/consensus on security risks
Forward-leaning engineering leaders pay particular attention to these factors and put in place the right process checkpoints and expectations to minimize avoidable communication overload.
3. Minimize Process Overhead
It is rare to meet a developer that loves processes. However, the smooth flow of the software development lifecycle involves the execution of several mundane yet crucial tasks. Missing any of the steps stalls the SDLC process and results in inefficiencies.
For example, an organization's SDLC process triggers post-commit downstream tasks through a Jira status change. I.e. a simple process step triggers multiple activities such as CI-CD build, quality tests, and security tests. On the contrary, not making this simple change in Jira status introduces avoidable wait times in several downstream processes. Developers may occasionally miss such steps and cause delays. When pointed out, developers react negatively to this because in their mind it was a small error.
Such process missteps can lead to reduced software developer happiness and also have other downstream impacts. How do we ensure the process is followed without overburdening developers? How do we ensure that these conditions or misses are caught early?
An approach is well-designed automation to detect missed steps and remind the developer to perform the associated tasks through gentle ‘nudges’. These messages are inherently negative in that they indicate a problem. But if they are system-generated, the developer doesn’t feel judged and just follows through with the required action.
There is a scientific basis for this. Nudge theory is a concept in behavioral sciences that shows that positive reinforcement and indirect suggestions are good ways to influence the behavior and decision-making of groups or individuals.
Human Factors
Human factors also have an impact on developer happiness. Some of these softer levers are rejuvenating developers’ stamina for work with the right task diversity, acknowledging their value through appropriate recognition, and providing gratification of work done through end-user feedback. These software factors also prove to be vital to the happiness and effectiveness of software developers.
1. Recognition
Though software developers are some of the most highly compensated individuals in an organization that alone is insufficient. They have a strong emotional need to be recognized for their accomplishments. With an exacting nature of work solving challenging technical problems, developers expect recognition to match the impact or output. Moreover, developers innately expect recognition to be genuine and based on objective factors. However, creating an objective basis for recognition and applying it consistently is easier said than done. Here are some suggestions on quantifying accomplishments.
The easy-to-obtain metrics to measure contribution are a number of story points delivered in a time period, bug reports closed, etc. But the other contributions such as code reviews completed, and quality of work delivered is harder to measure but must also be considered. How do you appropriately recognize differences between a single bug fix that plugs a gaping security hole and several other bug fixes of less import? We will discuss some approaches in a future blog.
Remote work has created a new urgency to develop objective criteria that measure developers’ contributions. “Out of sight, out of mind” is a real problem in remote or hybrid work situations hence a proactive, deliberate approach is urgently needed.
Kudos for accomplishments should be public and equitable.
A private message from a manager to a developer recognizing work done is nice, but it goes only so far. The larger organization should be made aware of the contributions of the developer. Public recognition backed by objective factors also reduces the squeaky wheel syndrome. Developers aware of others’ contributions can quickly rationalize the reasons for kudos to someone and it also removes cognitive dissonance.
The key is to measure and recognize developers’ accomplishments with as little subjective bias as possible and ensure kudos are public.
2. Task Diversity
Lack of variety is a reason for dissatisfaction at any intellectually challenging job. Software Developers are no exception. Repeating the same type of work leads to fatigue and unhappiness. Balancing different types of tasks rejuvenates the developers’ interest and stems unhappiness.
Engineering leaders can directly take steps to provide task variety by balancing among the following tasks: new feature development, bug fixing, peer-reviewing code, and handling escalations.
A challenge in implementing this is to allow for the differences between individuals. Specific assignments of these task types to individual developers depend on several factors: Relative interest in the task Skill level for each task/project Equitable distribution that is also visible
3. Feedback
Related to recognition is the notion of feedback. Feedback deals with developers quickly understanding the impact of their work and using that as self-motivation for the next task/project. Feedback can be either positive or negative.
- Customer Satisfaction or Customer Benefits: This feedback is usually positive in nature and is deeply satisfying to developers. Product Management is ideally suited to provide feedback and kudos on how developers' work has benefited customers. PM feedback is shown to be especially effective for late-breaking changes that were added to the scope. These changes are a particular source of negative sentiment among developers hence PM providing positive feedback in those situations is very important.
- Customer Issues and Escalations: This is a form of negative feedback. Nothing irritates a developer more than being tasked with looking at escalations that are not really code-related but related to documentation, configuration, and the like. Engineering leaders must pay close attention to these negative feedback episodes and ensure they are minimized. One approach would be to study which issues require a change in code or bug fix, which are support-related, documentation related, and so on. Leaders who put a premium on understanding this split clearly demonstrate to developers that they take avoidable negative feedback very seriously. Thus quickly endear themselves to their teams.
Measuring the Software Developer Happiness Index
It may come as a surprise to some that all these factors listed here are directly controllable by leaders of their engineering teams. Moreover, they can also be quantified to derive a Developer Happiness Index. If you would like additional details on how to use these factors to measure and track the developer happiness index in your organization, contact us today!
.svg)
.png)
.svg){kind=small}
