The Rational Software Engineer: How To Be Passionate About Your Work

I am a software engineer who geeks on learning, using a scientific approach to solve problems, and optimizing my performance. As a software engineer, I tried to analyze and dissect what contributes to my job satisfaction. And I feel like I’ve gained some insight into this topic, which may be useful for others. In this article, I will share general information about job satisfaction in IT, what criteria are likely to define how happy you are at work, and what helps me personally to be passionate about my work while providing media/scientific sources and jokes whenever I can.

Software Engineering may not be that meaningful and satisfactory field

Let’s start with a bit of a frustrating fact: the software engineering field may not be the most meaningful or satisfactory among all of the fields that exist. According to Research done by PayScale, 57% of computer software engineers told PayScale they were either “Extremely Satisfied” or “Fairly Satisfied,” while 29% reported that they think the job is of high meaning.

Among other computer-related jobs, software engineers lag behind as well. However, even though only 29% consider their job “making the world a better place,” a lot of developers are still satisfied with what they do.

While 57% percent of satisfaction doesn’t seem that bad, if we compare it with other fields, we will quickly notice that most of them report much higher satisfaction levels. For example, 96% of surgeons find their job meaningful, and 83% say it brings them a lot of satisfaction.

While it’s not that nice and shiny on average, one should not forget that individual cases vary greatly. The IT sector typically provides a pleasant environment to work in, different paths of constant growth, and high compensations. I am sure that one can truly enjoy the job and make an impact on the world under the right conditions and mindset. Let’s discuss what aspects have the greatest impact on job satisfaction at a workplace.

Main Aspects of Job Satisfaction

There are a lot of different studies and researches around the topic, especially when it comes to how much salary is important for job satisfaction. Both the 2014 SAP survey and the 2013 SHRM survey reported pay as the main criteria. However, a recent study from Boston Consulting Group, which surveyed over 200,000 people around the world, reports that the most important factor for employee happiness is the appreciation for what they do.

The top 10 factors are:

1. Appreciation for your work
2. Good relationships with colleagues
3. Good work-life balance
4. Good relationships with superiors
5. Company's financial stability
6. Learning and career development
7. Job security
8. Attractive fixed salary
9. Interesting job content
10. Company values

It’s also very illustrative how much the factors depend on culture and location.

For example, in Switzerland, good relationships with colleagues are the top priority, while for workers in China, learning and career development were reported to be more important.

The chances are that the mentioned criteria make a different priority order for you as well. Still, I think that most will agree that the list is the foundation for most of the main things that make an environment pleasant and enjoyable to work in. We will talk later about how we can make sure that we are in an environment where most of the mentioned aspects are present. And now, let’s discuss the software engineering specific aspects that play a significant role.

Software Engineers Aspects Job Satisfaction

Two years ago, authors Daniel Graziotin and Fabian Fagerholm studied more than 1300 developers to rate their happiness, assess factors that make them unhappy, and see if software developer job satisfaction was truly linked to improved productivity. They used the Scale of Positive and Negative Experience (SPANE), and their results were published in Rethinking Productivity in Software Engineering.

The findings were pretty interesting. The two main reasons for unhappiness are being stuck in problem-solving and time pressure. And it can be even worse if these are combined, and they typically are. Personally, when I don’t know how to fix a bug combined with an imminent deadline can be really daunting and frustrating. Such a situation can happen if you don’t have somebody to ask advice from or you are a “gatekeeper” of some piece of the project that only you understand. Interestingly, it happened to me much more often in the past because I used to work in small teams and didn’t know how to react properly to my PM asking to add 1 “small” feature on the last day before release. Now, I know that “last-minute” features are typically awful ideas.

They are buggy, introduce overtimes, and typically can be easily moved to the next sprint. I had an illustrative story of a last-minute feature that should have been moved to the next week. Close to the release, we found out that we handle timezones incorrectly in our app. One of the main app features was built upon a calendar and time booking, which was critical. After tweaking timezone handling in some places, I realized that the issue is not a bug somewhere but rather an incorrect approach in timezone handling altogether. As a result, I needed to go to the management and bring them great news before the release. Even though there was no impact on the users (as the platform didn’t have real users just now, and to be honest ever after), we needed to complete the outsource project for the customer as we already delayed a few weeks because of a few bugs and were losing money on the project.

Management didn’t want another week paid out of our company’s pocket, so they asked me whether it’s possible to rebuild the timezone handling until the end of the day. The superhero inside me gleamed and said, glorifying, “yes, I can finish it till 6-7 pm”. My reason shouted, “you don’t know the system well and implication of the time zone mechanism change will lead to,” but who cares if it is a possibility to feed the ego!

It ended up the way it should have. I changed the timezone handling fairly quickly and had 1 hour left to change the tests that I saw for the first time. There were pretty a lot of them, and my change broke around 20, but “it is not the point to give in.” After 2 hours, I fixed all of them but still got a couple of tests failing even though they didn’t seem related to the timezones. I had nobody to ask for help from as there was only another engineer on the team, and she was a Junior as well who didn’t understand the tests well enough to help.

Having spent another hour seeing everybody leaving the office apart from my manager and not being able to resolve the issue, I came to my manager in complete despair to say that I didn’t manage. For me, it was a complete failure. I didn’t meet the deadline, I didn’t know why the code was broken, and my head was dizzy from having been coding for 6 hours straight. And the biggest hit, I was afraid to let down my manager, who was a role model for me. I thought that when I came to her, she would be disappointed as much as I was, but, guess what, she took it at ease, said brief “ok” and left home. Why? Because, apparently, nobody cared.

The customer didn’t even check the app that day. The management was already in their Friday evening rest time. The only person to whom the time zones were important was me, and there was no good reason for that. When I fixed the test issue on Monday, which turned out to be an unnoticed incorrect concurrent resource access during tests, nobody even noticed that it was not done on Friday. It was absolutely possible to move the feature to the next sprint and rest at home that Friday evening, but, unfortunately, my ego and lack of experience didn’t help me to make the right choice.

Returning back to handling situations when I am stuck with some task or bug, as I work in bigger teams with Senior members more often now, I almost always have somebody to turn to if I’m stuck. As well as that, my networking has grown since, so most of the time, if I cannot find support in the team, I have somebody more experienced than me to reach out to. Having more personal seniority also helps to avoid being stuck. Last but not least, I try to rotate with my team members inside the project so that there is no “gatekeeper” for some pieces of the project.

Not all of the things I mentioned are easily controllable, as is the seniority of people who work in our team, but it’s useful to be cautious about them and use processes that can decrease the chances that you will get stuck with a problem not meeting the deadline.

The third important problem by the report is working with bad code and bad coding practices. Сode debt is one of the major causes of bad code quality. Nobody likes to write bad code, but sometimes we have to. It’s important to keep the code debt in the project under control. Doing Code Review, dedicating 20% of the time each sprint to refactoring, throwing away the code that was supposed to be thrown (I know how much you want to build on top of your PoC, but, please, don’t). All of these can increase the code quality and make the satisfaction much greater. Another important thing is well-being in a team, so let’s cover it as well.

Well-being in a team

Most of the software engineers work in a team. They can be either small or large, but it is hard to enjoy your job if you are in a poor team. As Google was really interested in what made effective teams in their company, they conducted a research project, “Aristotle.” They identified 5 main things that meant a lot for team efficiency, in order of importance:

1. Psychological safety: I feel safe to take risks in a team and fail

2. Dependability: My teammates get things done they promised

3. Structure and clarity: I have a clear path of what to do and a clear role

4. Meaning: I find my work meaningful

5. Impact: My work makes an impact

   
   

Team efficiency is also a good marker of well-being in a team, especially if the main aspects of efficiency are psychological safety, dependability, and clarity. We want to nurture our team processes and structures so that we improve these three things.

Psychological safety, for example, can be increased by letting people make mistakes and learn rather than punish them for that. Don’t be afraid to ask “stupid” questions and fail. Everybody does it. It’s good if the behavior begins with the manager. If the managers show that they are not faultless and make mistakes and not be ashamed of speaking about it freely, the team will feel so as well. The worst thing that a manager can do in terms of psychological safety is to build a culture of fear. In my experience, in a culture of fear, many essential things such as creativity, initiative, and motivation fade away almost instantly. In the same manner, don’t be afraid to say “stupid” ideas. Out of each 10 “stupid” ideas will be at least a good one, and this is enough to be worth saying all of them

Dependability means a team of responsible people. Commit to only what you should commit to and communicate your status early rather than late. It’s better to do a little bit more than promised rather than less as it will bring positive emotions in the lucky case and neutral in the expected one. Don’t promise to build a feature in 3 days if you think it takes 4. It makes much sense to estimate it for 5 so that your teammates can rely on the estimate more and be sure that it’s very likely it will be done in 5 days. They will be glad that the blocker for them took 4 days to resolve instead but will be just fine if it takes 5 days as well.

Structure and clarity. Help to divide work between people, so everybody knows what they are responsible for and clear the project goals. For example, in one of the teams I worked with, our project vision was blurry, actually, very blurry. It demotivated me a little to understand that I’m not sure what we do and why. It affected both the level of meaning and impact. Luckily, soon after, we got a great Product Manager in the team, who made the project goals much clear. I noticed how much more enthusiastic and motivated team members started behaving after it.

Job Satisfaction Criteria Summary

As we have covered both general and field-related satisfaction points, the important question is how to get into the environment where all of them are present. Building most of them from the ground up is hard, in some cases - almost impossible, and while I think it’s a must to invest your time and energy in improving all of the mentioned aspects in your team, the most pragmatic option is simply to get to a team that functions well already.

Assessing some aspects such as level of gratitude, dependability of your future colleagues, and work-life balance is really challenging and error-prone when done from outside the company during an interview. I plan to dedicate a whole article to how to do it most effectively, but another good option is to look for a good internal team with the values that meet yours.

You already have a lot of insights into your company. Its security level, your management seniority, and the overall agreeableness of the people, so there is apparently much less to figure out when you rotate internally. If, for some reason, your team doesn’t have a good level of emotional safety, start looking for a team where teammates have shining eyes and/or the most efficient teams in the company. There is a big chance that their team functions well, and this is the reason that makes them so happy or helps them to progress fast.

Conclusion

Here are all of the markers that are likely to determine how satisfied you are in one list:

• Appreciation for your work
• Good relationships with colleagues
• Good work-life balance
• Good relationships with superiors
• The company is financially stable
• You have opportunities for learning and career development
• The job is secure
• Attractive fixed salary
• Company values match yours
• Psychological safety in the team
• Dependability of your colleagues
• Structure and clarity of your role in the team
• Meaning of your work
• Impact you make
• You don’t get stuck with your tasks
• You don’t have time pressure often

Remember to look for them when you choose a team you would like to work in and strive to develop them in your team.

In the second part of this article, I will focus more on approaches to increase job satisfaction that I find useful for myself and what helps me to be passionate about work.