Happy developers are better problem solvers

Ping pong tables, candy bars, nice views, chilling lounges… would you say developers get special treatment, or do you think there must be a solid reason behind this nice scenery at the workplace? Software development is both analytical and creative and companies around the world are willing to apply the findings of the latest studies in the developer’s psychology to provide an environment that could benefit both aspects. Understanding what motivates developers is the first step in making cost-effective decisions of enhancing working conditions, job performance, and limiting the occurrence of negative emotions in regards to work.

Happy developers, happy companies. Or this is what studies show, that positive affective states of software developers are indicators of higher analytical problem-solving skills (Graziotin, Fagerholm, Wang & Abrahamsson, 2018) which of course means innovative solutions, better products, more efficiency, and overall higher satisfaction for all parties. Happy and unhappy might be too broad of an approach, but consider them umbrella terms for the positive and negative emotions and behaviors you could experience at work - not all happy means jumping for joy, and not all unhappy means hating your job.

Although a nice work environment might help, this, of course, is not the only nor the most important factor in enhancing productivity and fostering intrinsic motivation - you know, the kind that keeps things going because you like and enjoy doing them and because you see a purpose for your effort. Fortunately, science already found the greatest three motivators for software developers and now all we have to do is pay close attention to meeting those needs as well as we can. Without further due, here they are, the big 3: autonomy, mastery, and purpose. But before digging deeper into understanding these 3 core pillars of intrinsic motivation, let me explain why traditional contingent rewards “if-then” do not work in creative, non-routine jobs like this. Being a software developer is all but simple and predictable and an “if-then” mentality is the killer of intrinsic motivation. It programs you to only work for rewards and get there, by all means, necessary, choosing shortcuts and short-term thinking, in detrimental of creativity, code clarity and quality, and the wellbeing of the team.

Ok, ok, I’ll get into it now.

Autonomy

First things that come to mind when we hear“autonomy” are maybe choosing your own tasks and having the decisional power over how to approach them in a way that works for us. But is complete freedom over action possible when being part of a team? Not really... If everybody would do things exactly how they want to, without considering the processes of others, you could easily say the end-project (or at least the way to the end) would be a big mess. That is why a solution to the aspect of autonomy is aiming for team rather than individual autonomy.

How can we encourage teams to be more autonomous and self-organized? Some ways would be letting the developers choose the tasks they want to work on, by coming to an understanding with their colleagues, providing flexibility to a certain degree in the technology they want to use, avoiding micromanaging, and trusting the specialists you have in your team. Flexible working hours play an important role too, but the great news is most companies already offer that and understand the difference it can make on the developer’s productivity. Whatever the chosen recipe for team autonomy might be, the lead should let the team know they bring value to the product and that he believes they can organize themselves in a way that increases their productivity, nurtures their creativity, and makes them satisfied with what they’re doing.

Mastery

Life itself is a continuous learning process. We all strive to become better in some aspects of our life that matter to us - it gives us purpose, meaning, and a sense of accomplishment. Doing so proves time and time again that we are able to evolve in ways we couldn’t even imagine. We spend a big part of our time working, and doing the same things over and over again as we run on autopilot is sooner or later going to demotivate us. This applies maybe to an even greater extent to developers since they have such a cognitive-centered job, where mastery is a central element to feeling fulfilled.

An easy way to fulfill this need is by offering access to training, webinars, conferences, or internships. But companies can even support mastery by organizing their activity in such a way that promotes learning and thinking out of the box. For example, task-shifting, which is not only great for the developer who becomes more confident in doing something different than what he usually does, but also for the team who now has people who are capable of taking over in case a member is missing, or in case the ones responsible of the task need an external point of view.

Another great idea is giving the developers a designated time for learning or innovation when they have complete freedom to explore new solutions and create with no restrictions. Big companies have implemented this strategy, and it seems to work wonders. At Google, for example, they call it “20% time” and we are all for it!

Purpose

Feeling like what you do matters and can have an impact on society on some level is extremely motivating. Sometimes working for too long on a project or investing too much energy into it can make developers lose track of their true purpose. To keep the determination high, highlighting the impact of their work is a useful tool and a great reminder of why they started in the first place.

Some ways in which this can be achieved is by illustrating the statistics of the progress and the success of the team. Presenting the work to other teams or to customers in order to get feedback is also a great way to raise the internal awareness of their accomplishments so far. Nonetheless, expressing appreciation in a manner that targets specific aspects of the developers’ or the team’s work, rather than the classic and empty of meaning “Great job!”, will enforce the idea that their work is seen and purposeful.

Going back to happiness, how happy would the developers in your team or company rate themselves? Researchers claim that making developers satisfied and happy will improve their productivity and software quality. If you don’t want to take their claim for good, we challenge you to try to implement, let’s say for the next 2 or 3 months, some of the strategies described in this article and report back to us on what you can notice first hand.

We are pretty confident in the statement that happy developers are better problem solvers and we hope we can all contribute to a happier community together.

Resources:

Graziotin D, Wang X, Abrahamsson P. 2014. Happy software developers solve problems better: psychological measurements in empirical software engineering. PeerJ 2:e289 https://doi.org/10.7717/peerj.289

D. Graziotin, F. Fagerholm, X. Wang and P. Abrahamsson, "Unhappy Developers: Bad for Themselves, Bad for Process, and Bad for Software Product," 2017 IEEE/ACM 39th International Conference on Software Engineering Companion (ICSE-C), 2017, pp. 362-364, doi: 10.1109/ICSE-C.2017.104.

Daniel Graziotin, Fabian Fagerholm, Xiaofeng Wang, Pekka Abrahamsson, What happens when software developers are (un)happy, The Journal of Systems & Software (2018), doi: 10.1016/j.jss.2018.02.041