Are happy developers more productive?

About Michaela Greiler
Dr. Michaela Greiler makes code reviews a team's superpower through her code review workshops. She has worked with teams from Microsoft, National Instruments, Metro Systems, Flutter, Wix and many more.

Read the whole episode "Are happy developers more productive?" (Transcript)

[If you want, you can help make the transcript better, and improve the podcast’s accessibility via Github. I’m happy to lend a hand to help you get started with pull requests, and open source work.]

[00:00:00] Hello and welcome to the software engineering unlocked podcast. I'm your host, Dr. McKayla, and today I want to talk about whether happy developers are more productive. That would be awesome, right?

But before we start, let me tell you about an amazing startup that is sponsoring this episode. Codiga. Codiga is a code analysis platform that automates the boring part of code reviews and lets you merge with confidence on GitHub, GitLab and Bitbucket.

I've worked with Codiga for around one year now and I love how it guides me in discovering and improving, the, well, the not so nice parts of my codebase. But there's more, Codiga also has a coding assistant that helps you write better code faster. Find and share safe and reusable blocks of code within your favorite IDE on demand while you're coding.

Codiga also offers a great free plan, So there is nothing that stops you from giving it a try. Learn more at Codiga.io. That is Codiga.io.

But now back to exploring the relationship between productivity and happiness. Yeah. It's not a, it's not a new topic. Uh, there has been, have been several studies around productivity satisfaction and software engineering outcomes.

I'm not going to be too scientific or. Very nitpicking around the terminology of saying, well, satisfaction is not exactly the same as happiness. I want to talk about this a little bit more on a practical level with you, but I will look at some of the studies around that in one of the first studies I came with.

Was, or it's not really a study. It's a, it's a, it's an essay about a bunch of studies, a really, really body of work around happiness and productivity and satisfaction and so on. And, and this is in one of my favorite books. It's called rethinking productivity in software [00:02:00] engineering. I mentioned it before.

Already in other episodes, it's edited by Tom seaman and Kaitlin Sadowski and it's backed really with a lot of essays. And I think that's really nice because. More accessible there. It's not so much about the methodology behind the software engineering research studies. It's really about the results and their, their perception of the different topics based on what they have done.

So I think it's very accessible. It's nice to read it's flows very easily. So, and there are plenty of different chapters and each chapter somehow is an essay. As I said, from different researchers on. Main research topics on their outcomes that they have seen. And one chapter is chapter 10 is called happiness.

And the productivity of software engineers. I have it right here with me. And it's from two, from two people, Daniel and Fabion, fogger home are writing about that. And actually I've been reading a lot of the work of Fabion fogger home, and I used also his definition for software developer experience for my newest research that I have done this.

So, yeah, I'm quite familiar with his work and I really like it. And so in, in this, in this paper that I'm now having here right here with me, he asks the question are happy, software engineers, more productive engineers. And as I said, this is an se, but there's a lot of. That he's actually done around that.

And in this paper, in this chapter, he goes into that and explains why it's really difficult to measure happiness, right? Because actually what we would have to do is experiments, right? The experiments would be really nice that we have two groups and that we can actually really control one group, like make one group happy and the other unhappy, but it's obviously not really ethical.

It's not something that we can do. And so we have to wake with what. We have at hand, so we can have quasi experiments where we simulate something like that. But anyway, um, so yeah, he's investigating that. And, uh, one of [00:04:00] the studies that he did is they, they measured for example, how happy the people are.

And then they gave them a programming task in the well, measuring is by self-assessment. So people have to tell them how happy they are, right. The survey. And then to give them a programming task and they look where they are not more happy. Developers are actually outperforming the less happy developers and yeah, this is actually exactly what they found.

They found that people that said that they are happy who are really outperforming that, and that's really a cool result. And what do you also did is they measured in general, the distribution of happiness of software developers, right? And then they compare that with other professions and what this. So for developers a little bit more happy than other professions or professions that they compared it to.

And I think, yeah, we have many reasons to be actually very happy. I think it's, if you like software development, it can be really challenging, very exciting, very stimulating work. And all of those things like stimulation and being excited, being motivated about your work are great factors that you like your work, that you're happy that you are satisfied.

Right. And on the other hand, software engineers are all. Getting a good salary normally or higher average salary. And I think that's also contributing to your happiness. If you think about the pyramid of needs from Maslow, right. Having enough money is definitely on there. Right. So, and I think there are other studies around that as well that, you know, you don't need all the money in the world, but there needs to be a certain amount that makes you happy.

Right. So everything that's below that. It makes you unhappy because you have to worry about how do I get food? How do I afford actually my, my housing and so on. But if you're in this comfortable situation that you don't have to worry about that, right? Your satisfaction, your happiness really goes up. And then he showed that actually the more money you have, it doesn't really make you significantly more happy.

I cannot imagine why, like, I'm [00:06:00] obviously matching, like if I would be super rich, I would be super happy, but apparently it's not so good that I'm not super rich and. Not good. And I'm not super rich, but maybe not. I'm not the reason to become super rich, to be super happy. Anyway, I'm going to look a little bit into this study as well, because what they also looked at is not only are we happy and are we more productive, but also what makes us happy and unhappy and perhaps.

Somehow has a little bit fussy and it's also very personality. I think it's also something that you can feel in, in situation, right? So I'm, I'm happy now and hopefully a little bit later, it also, it doesn't really only look at work related events. Right. So it could be that you're unhappy because you know, something sad happens in your life or because you're, you're having a fight.

With your spouse or with a friend or with your children or whatnot. Right. So, which is a little bit different than another study that I will talk about is the study and the wig from Margaret and story, and many more, which looks at satisfaction and work satisfaction. So here it's really more about Edward, am I happy?

It's not about, did I have like a, a fight with, with my spouse or with mine? And obviously it's also a little bit faster because it could be that I'm not satisfied with my work today because I had to fight with somebody anyway. So coming back to that, all of those studies and also the study that I did is not only.

Trying to establish some relationships here or see, is that actually related? Is there a relationship that's one caused the other or not, but we also want to find factors that can boost our happiness. Right? What makes us happy? What makes us unhappy so that we can inform our. Activities like, um, our actions, right?

That the, we can create a workplace where we are more happy and more satisfied where we have a better experience. Right. So in, in my wig, I'm, I'm particularly, uh, trying not to say, well, this is happy. This is [00:08:00] satisfied, and this is productive, but I'm really talking about your experience as a developer. And how can we boost that right in the experience.

In includes being productive because we have seen that very often, if people are productive, they're also more satisfied. They are more happy, right. If, if I feel like I'm making progress, that I'm not stuck, this is my experience that I'm living. And, uh, and so this is, this is a little bit the angle that I'm coming from.

But today, as I said, I want to look a little bit really at happiness and happiness. Uh, and so let's go back to, to this paper on what makes developers happy and unhappy. So they look at the different factors that might. Developers happy and unhappy. And when they looked at a defectors, they were looking into what kind of categories do we have here and decided the main causes of unhappiness are either controllable by managers and team leaders.

And they are four times more often mentioned, right. As though that our personnel and, you know, I think. If it's personnel, it's probably less of a challenge because you have the ability, you are more ability to actually change it, right. If I'm unhappy and then know that I can change it, I can control it. I will do something about it.

I will do something that I'm feeling better, but if it's controlled by a manager or a team, Yeah, my, my, my action radius is a little bit more limited. And so, yeah, I totally see why, like, this is mentioned more often why this is a bigger problem, right? If somebody else is in control of your happiness, if they can, if they can influence it.

And so what are some of the things, for example, being stuck in problem solving and time pressure. And I saw that also in our, in our work. I see that this being stuck in problem solving. When I did the research, my impression was that. It's more about the social aspect, right? It's about reaching out to people.

Let's at least for the participants of our study told us. So it was not only [00:10:00] I'm stacking problem-solving, but there is nobody I can ask to help me. So it's a very social construct as well as well of the team to have a team that's right behind me that if I feel that I'm stuck, I can reach out that I call somebody, walk over to somebody.

And I think this is also a really interesting area now with our remote work. Because there, there are many, many good things. I'm a big remote work advocate, but I also see that people are more and more isolated that they feel a little bit lonely just yesterday. I had the code review workshop with, with a big team and they were talking about the challenges that they feel now during code reviews because of the remote work.

Because before, like if we had like a lot of ping pong in our code reviews, I would just walk over to the person and. Talk with them or if I don't understand something, I go there and yeah. And I just, yeah. Talk to them. And I think now we can still do that. Right. I asked them, but why are not picking up the phone?

Well, phone is not really what we are doing. Right. We are calling somebody. We are chatting. Maybe if it's somebody and saying, oh, let's, let's hop on. But there is a bigger burden, right? There's a higher stake to it to actually do this. If I see the colleague, I said, oh, sorry, can we quickly go? And I also feel like if this now is the right time, if they are happy to help me, I get much more feedback from the whole interaction.

So I think, yeah, there is a bigger barrier to actually reach out to people to ask them to be on a call and there's. Organizational details to it. Right? You have to arrange, you don't know what the other person is doing over there. Are you free? Do they feel like having a COVID you anyway, many things. So problem solving is definitely one of the reasons for being unhappy and yeah, in my experience, in my research, it has a lot to do with.

Am I alone with this problem that I can't solve. Right. Problem solving in general came up also in, in my, in my research as something that people are happy about. They love problem solving, love, being challenged, being [00:12:00] stimulated, but until a certain level, right. We don't want. Overwhelmed. And if we are stuck, we obviously want that somebody helps us out here.

Right. That I have a team. I know that I can actually trust that there will be some somebody. So what are other things? Time, pressure. Yeah. Time pressure came up as well. For my study time pressure. It was more deadlines, right? Really deadlines that are unreasonable. That make no sense. When you say we already knew that we not going to do that.

And it's very, very de-motivating and not really a nice experience for. Then they also say the third, most frequent cause for unhappiness is working with bad code and especially with bad coding practices. Yeah. Technical debt came up, but also in my study, but technical debt I think is something that we can maybe handle it a little bit better than bad coding practices.

Right? Bad coding practices is again, something that influences how you work with others, how you have to deal with, if I know that I cannot change the technical debt, then that. More unhappy that knowing that it's there. Right? So, or if, if I'm, if I'm in a situation where I know that I'm going to create bad code, I think that's really something that makes sense on happy.

Right? We want to be proud of our work. This came up also a lot in, in my research. People want to be proud of their work and I think proudness and happiness somehow related. Right. So what else do they say? They say red bad code can be a reset of management decision. Aiming to save time and effort in short time.

I think we have all seen that. That's very true. So the question is what can we do about. And I think studies like this are an important part of raising awareness. If we can show a link and if we can trust our engineering, um, engineers to know what they're saying and that they have experience, and this will bite us.

Long-term if you are now sacrificing code quality, it will help us a little bit short term, but long-term, it will be a problem. I think this is, this is [00:14:00] very simple. So what are things, information needs, information needs, right? So if I don't have the information to do my job, which I think is a little bit related to being stuck in problem solving.

So what are the consequences of being unhappy? I think this is also really interesting, right? And there are a lot of consequences and those two authors separate them in two categories. One is internally what happens to me when I'm a developer in that one. And what happens to also the outside world and, um, what happens to me if I'm unhappy?

Well, I have a low cognitive performance. With the study also, where do you show that happy people outperform, unhappy people. I have a low cognitive performance, so I'm not so good with problem solving with it, doing challenging tasks, mental unease, or even disease. That's very scary, but I think also very real low motivation.

Jeff procrastination. I added that. They haven't said it, but I think this is going hand in hand yesterday. We've been talking about code reviews again in viewer talking about the large PRS complex PRS and procrastination is definitely something that happens, right. You don't even want to start doing it.

And if you don't start and you procrastinate, you're getting unhappy because you're not doing your work and then work withdrawal. Yeah. And what happens outside? Well, delay. Well procrastination. I said that, right? I think this is first we procrastinate internally, and then we have the delay of the project, right?

So turn around times in code reviews are going up and our other people are stuck. And so on. These are low productivity process deviations. Yeah. Obviously can't do that. Now. Haven't finished it. And low code quality and, um, even discharging code, right. People are remove code again and a broken. Yeah. So this is what they are telling us here.

They're going a little bit more into all the details. I'm not going to go into [00:16:00] that here, but I encourage you to read it, to read that thing. Right. So, yeah. And he had to talk about the two studies that they did right there. The cross experiment that I said in. Yeah, and they did another one as well. So they did more than those two, but those two were what I wanted to, to tell you.

So an interesting thing is that they not only look at productivity, but then in the last part of this, of this chapter, they are also talking on other factors that are influenced or other, other consequences of impact on happiness. Right? What happens if you're an happy or what happens if. Happy. And I think let's look at the, what happens if I'm happy.

Well, what they say is that if, if people are happy, they like to share no. Great. Right. So they do want to show others. They want to work together with others. They want to reach out in a joint effort to solve a problem. Right. And this reminds me of the participants in my, in my study that I was talking to, and this person just started somewhere new.

And in this remote, Setting, right. It was a little bit lonely time and it was very isolated to start. And unhappiness definitely came from that, that he didn't know exactly what to do. The onboarding experience. Wasn't so good. And the moment that he started working with others, he became much more happy.

And when he was involved and could see how he could actually contribute. Right. I think we also have internally. This need, and this wish that we can actually make a positive impact, not only on the world, but on our small world, not talking about like taking over or taking over the world or solving climate crisis, which would be great.

But I think also smaller impacts that if you know that a critique likes to spend time with you or that you have them solve it. Yeah, there's another thing that they also showed that there's a connection between happiness and code quality, and they have a statement of one of their participants [00:18:00] and this person says, but I'm in good mood.

And I feel some how positive the coat I write seems to be very neat and clean. I mean, I can write code and analyze problems quickly and with lesser or no unnecessary. Problems or errors. And this is really nice. Yeah. Cool. We are writing better code when we are happy. Tell, tell your, your boss, dad. And then they also said while unhappiness actually causes anxiety, stress, self-doubt saddened feeling and depression, right.

Now I want to look at the different work, really excellent work. It's called towards a theory of developer job satisfaction, perceived productivity by Margaret and story, and many others at Microsoft. And a lot of my ex colleagues actually. Yeah. I really love what they're doing. And so what they were looking at is, as I said, Happiness per se now, but really job satisfaction, they call it job satisfaction and perceived productivity.

Right? Again, productivity to measure productivity is, is not that easy. One of the studies that we just talked before was really measuring with points that you're getting, but here it's perceived productivity. So how productive do you feel? And they created also a framework around that, a theory around that where we can say, well, Let's assume based on, you know, some research that has been done, that there is a link between job satisfaction and performance, right.

And there was, for example, the week by judge at all the day, he presented the unified theory of the relationship between job satisfaction performance in 2000. And. And this is considered seminary work, right? So one of the first really important works in this, in this area that shows that there is a B directional link, right between those two.

And this is what Margaret and story and others are, are advancing here. And you're looking at a dare things. And [00:20:00] this was done at Microsoft, the large scale study at Microsoft, where he really asked a lot of people. About those different aspects of their development or job environment, their circumstances.

And they try to see which factors are actually very influential for satisfaction, which factors are important, which factors are correlating. Yeah. And the manager seems to be extremely important. The manager seems to be very, very important for your happiness. And I think this is also a little bit, if you think about what I said for the.

For the other work. Um, well you cannot really control your manager that much. And I think this pops up as a problem. If it's it's, if it's not good, right. Or you're very grateful if it's good, because you had your, you don't have all the, all the ability to control that and to change that. And when I think about our study or around developer experience, and then something that strikes me while.

I also wanted to know what's the most important thing I ask people. What's the most important thing. And they're really interesting was that a lot of needs, a lot of factors that are hygiene factors, hygiene factors means that they have to be present that I have a good experience, but if one of them is not there, I really have a bad experience.

Right. So just that they're here doesn't mean that I have a great experience. It's the basis level of having a good experience, but if some something is. That's where the real that's where the real changes come comes from. And this means that we have to look at really where our problems in our workflows, where our problems in our work environments to to see that.

Right. And so I'm going to look at the takeaways from this work from Margaret and story and takeaway one is that she says, or they say having a good manager being productive, fair reward. Collaborative team culture using one skill [00:22:00] effectively and having impact at the work we're perceived as the most important at our company case study.

So a good manager out of your control being productive. I think a product of many factors, again, that. A fair reward. Well, this probably is related to salary and so on it, I feel that I'm getting, I'm getting fairly compensated, that I'm getting enough acknowledgement for my work using one's skills effectively.

I think this is an important one. If, if I feel I have a lot of skills and I'm not used for, for dad, right. I have to cook the coffee instead of really shining where, where my skills are, and this can definitely impact that. And then having impact. Having impacted work. I think they are going together as well.

Let's look at the second takeaway. Second takeaway was poor softer eye texture, legacy code, poor documentation, poor engineering tools, and too many work interruptions, which challenges the developers feel have a big impact. Right? So well, poor software architecture and nightmare. If you have to maintain that, if you have to go into that.

Yeah. Legacy code, well legacy code, obviously it gives you. Because of software, comprehension issues, right? Legacy code. I don't know exactly what, what the terminology here means, but I imagine no test cases. Yeah. I can see that poor documentation, poor engineering tools and too many work interruptions are challenges that have a big impact.

Right. Okay. And then the third one, and the last takeaway would be that developers who report they do impact for work and are important contributors within a positive work culture. Feel the most satisfied at work and developers who report they do impactful work. This comes up again, right? I'm I'm feeling that I've have impact that I'm meaningful.

My work is meaningful and are important contributor within a positive work culture. You have a contact him up. [00:24:00] In my study a lot. And actually it came up as this most important thing, as I said, I asked them, what's the most important for you? And it was very unclear. It's more about here's a problem. Then this becomes really important, but work cultures stood out and a lot of people said, well, work culture is number one.

As long as we're culture is good. I can drive change. If we're culture is bad, there's no positive change. That's going to happen here or there. The likelihood for that is happening that is decreasing. And this comes back to control controllability that we had at the beginning, right. Where we thought, apparently those things that I, that are out of my control make us much more unhappy than the things that are in my control.

Right. So, yeah, I totally see that positive work culture really important. Yeah, it's probably also the number one reason why I would leave somewhere. If the culture is not good. If I don't feel that this is a place that I want to stay. So these were the things that make people most satisfied, right?

Impactful work, important contributor, positive work culture. And then you also look at what makes people most satisfied with their productivity, not satisfied in general, but what makes them feel that they are really. And daddy say, well, autonomy. I can decide what I do doing impactful work can complete task.

Yeah, I see that if I can't complete the task, it would be very, very annoyed and satisfied with my productivity and terrified with engineering systems. Yeah. Engineered systems are also important. Let's come back to this can complete task thing, because this is something that I'm struggling a lot. I'm struggling along.

If I, if I can be so productive and making so many small steps to this task, but I feel like this task is still not done, but horrible feeling and feeling of unproductive. I actually talked with my husband about that last time, and I'm using productivity, several productivity apps, but one is a to do list [00:26:00] and like the version of wanderlust.

I liked that very much. Okay. So if I'm putting something there, like, for example, finding out how it works with having the baby now in Austria, how the whole, what, what kind of paperwork do I have to do? And so on, it's one of my tasks now, not really related to programming, but the only real example that just really comes to my mind because I was struggling so hard here.

Was that I put it on my to-do list and then I make several calls and, and all of the calls are either I don't reach somebody or somebody says, oh, call tomorrow. And then this person will tell you, or they tell you something, but that this is not the whole app. And so I have to, I did it right. I did it. And actually I was PR productive somehow.

Right. Or at least I was very active, but the outcome is not there. Right. I, I can't really check it off. And so sometimes I don't know. Should I put it on next day? And, uh, and this is what I'm doing or should I check it off because today I worked on it and then do it again tomorrow. So I think really this, uh, can complete task is a little bit also, how do we frame work and how, how do we think about the, for example, our JIRA tickets or our user stories, especially for things that we are not completely in control, how, how successful we will be with ending the task.

And yeah, it could be that we are accounting differently. Right? We say, make a, so I could have said, instead of finding out how to do X, I could say makes three call phone calls to find out what X is, but the problem is, I don't know how many phone calls I have to do. So I like that. I like that. Thinking about that a little bit more, I will definitely do that.

How to frame problems in the right perspective. And I think this is also important for, for engineering. My example was really far off, but I think we can, we can see the same instances of those problems in [00:28:00] engineering, beat our user story at somehow explodes or be the code review. Very rework a lot. And we haven't actually planned for that rework.

And what Y what am I doing? And help it to be filled with it. I be unhappy. I was satisfied. I was still feeling productive. It's, it's, it's a mindset, a framing problem, but also really how do we define work? And dad would love to hear how you do that. How, how do you do that? You know, have a task and you don't know exactly the sub-steps of it, or sometimes the sub steps are out of your control, whether or not you are able to, to finish that, to get that information.

Yeah. So let me know. I, I think this brings me also to the end of this, this episode, but yeah, I also want to know what. What do you think about happiness satisfaction at work? What makes you happy, unhappy as a developer and also maybe how do you work with these uncompleted tasks? How do you, how do you deal with them?

And so that you still feel productive, that you still feel happy that you feel still feel satisfied? I will link all the papers and the work that I talked about today in the show notes. So thank you so much for listening and bye. This was another episode of the self engineering unlocked podcast. If you enjoyed the episode, please help me spread the word about the podcast.

Send the episode to a friend via email, Twitter, LinkedIn. Well, whatever messaging system you use or give it a positive review on your favorite podcasting platforms, such as Spotify or. This would mean really a lot to me. So thank you for listening. Don't forget to subscribe and I will talk to you in two weeks.

Bye.