How grunt work affects devs’ motivation: A Sprkl Expert Talk

Meet Baruch Sadogursky: DevRel @JFrog

Hello everyone, and welcome to the Sprkl Expert Talk series. We’ll host a prominent developer in each episode and discuss a trending topic around Personal Observability, modern software, and complexity. 

We sat down with Baruch Sadogursky, Developer Relations, and DevOps Advocacy @JFrog. Co-author of #LiquidSoftware and Co-host of the @DevOpsSpeakeasy to explore “How grunt work affects devs’ motivation.” My name is Lee, devs communication here at Sprkl, and I’ll be leading the interview today.

Lee: To start, we’d like to hear a little bit about you and get to know you a little better:) So, let’s open the discussion with an ice breaker, the ultimate developer question. When did you start developing – at what age did you write your first piece of code?

Baruch 🎩: So I started developing in Java in early 2000. Obviously, it wasn’t like the early days, but it was exciting that Java was only out for 4 or 5 years back then. As I was still a fresh developer, that was exciting and interesting. Before that, I did the mechanical engineering stuff, and that was like a lot of hard work outdoors, and I was not too fond of it. So instead, I decided to do the “computers” thing and got a degree in Computer Science and program engineering. And the rest is history! Wow, I’m just thinking how it’s been 21 years. I can confidently say I’m more experienced now. 

What I like about coding is that suddenly you have something functioning. I love building software that works. It’s amazing because that’s the process of creation. I genuinely feel that there aren’t many satisfying things as creating something new.

When I first joined JFrog in 2012, I switched from R&D to developer relations. Back then, no one even knew what dev relations was, and there wasn’t a name for this position in the tech space. So we created one. Developer relations is exactly what it sounds like. It’s all about maintaining a tight relationship with the developer community. The primary responsibility of a dev rel is to help developers be more productive, solve problems, find products for them and even build better tools. My goal is to help devs maximize efficiency and to help them solve complex problems. I usually refer to it as a bidirectional discipline that takes care of speaking and listening to developers, understanding their needs, and trying to help them meet them.

How to deal with grunt work?

Lee: Let’s continue with what you consider to be grunt work?  

Baruch 🎩: It relates to what I said before about creation. Developers are creators. Well, let’s rephrase that’s what we strive to do. We want to create new things, we want to write new code, and we want to develop features. But unfortunately, there is a lot of other work that we have to do instead—stuff like fixing bugs, troubleshooting, maintenance work, and fighting technical debts. 

At the end of the day, when we look at the developers’ jobs and try to analyze what they do their entire day: we’ll often discover that the time allocated for creating something new, shiny, and extraordinary is limited. And a generous portion of the day involves the repeated maintenance work I’ve mentioned before.  

“Developers are creators, but unfortunately for them, the time allocated for creating new, shiny, and awesome software is limited. And a generous portion of their day involves the repeated maintenance work“. Baruch Sadogursky, JFrog 

I’d say that anything that doesn’t involve new creation is grunt work. For example, any work that consists of a struggle to find out or sort out data just to understand what happened before to fix something now. In these kinds of situations, developers can spend hours trying to find out what happened to their code, where it disappeared, and how it behaved? And sometimes you end up asking yourself: Is it even my change, or is it the latest version? That’s what I call grunt work. 

“Anything that doesn’t involve new creation is grunt work.” Baruch Sadogursky, JFrog

Lee: Generally speaking, in tech companies today, and based on your experience, what portion of the developers’ time is allocated for tough, challenging, satisfying problems? Literally, developing? And, what amount is spent on routine grunt work, debugging, and fixing problems? 

Baruch 🎩: Well, that would depend on the type of company, its culture, and the developer tools. When developers operate in the “right” environment in terms of processes, culture, and tools to prioritize new work and avoid grunt, the percentage of the time allocated to “New” work can be as high as 60 – 65%

And that’s a lot because when you compare it to companies in which there is no such culture of prioritizing new work, avoiding grunt work or finding ways to do it. You’ll notice that the percentage of the time allocated to new work can be as little as 30- 35%. So it’s half of the time between the companies that do the right thing and those companies that don’t prioritize. The difference is double; it’s huge.

Lee: Before I move on to the next question – I’d like to read you a short quote.  

“I’ve been fixing bugs for 6 months now, and I don’t know how much longer I can just keep fixing bugs. I’ve asked if new projects will be coming in, and have asked about carving out time to create the test suite. My manager told me that we need to improve the quality of the code and that means fixing bugs. However, what my manager doesn’t get is that we aren’t improving code quality. We’re just adding more bugs! I feel like my days are filled with grunt work; it’s demotivating. Poornima Vijayashanker’s blog, Hackermoon.

What do you think should be the balance of grunt work a developer can handle without burning out?

Baruch 🎩: So I guess that depends on the person. Some people are more resilient and can stand an overload of unmotivating work. And some people will burn out quicker. Regardless of the personality, it will get to everybody who’s grunting regularly at the end of the day. 

Drowning in grunt work will eventually burn people out. Some will be able to stand it for two months, others for 6. Eventually, orgs will lose productivity, great people, and the software quality will decline. Usually, what happens is that you’ll remain with a bunch of burnt-out unmotivated people that frankly could’ve gotten a better job but didn’t for some reason. 

Probably these are not the people that you want to retain anyway. There is no doubt that grunt has significant effects on the company, the employees, and the product. And not in a good way. 

What causes grunt work? 

Lee: Let’s move on to the next question. Can you list a few factors that may cause grunt work? 

Baruch 🎩: Sure, the two main factors are the company’s mindset and the team’s technical ability to implement changes. What I mean by that is that you can work for an organization that doesn’t care or doesn’t see the importance of motivating its developers to innovate and create new work. And instead, it just kind of shrugs and says, well, yeah, that’s the job. Just do it! Sadly, it’s similar to working in a factory. Where you get a task, now go ahead and do it. Obviously, the developers aren’t these types of employees and don’t do this type of work. In software development, it’s not like one day you assemble boxes and the other day you sort bottles. This is a different type of work that requires high levels of cognitive levels in which motivation is crucial for productivity and delivering high-quality products. Ignoring the developers’ motivational factors is the first cause of grunt. And it’s the most fundamental reason.

The second reason is when orgs realize that grunt work is demotivating and that it will impose a threat to devs’ motivation and will hurt the org’s efficiency and productivity. But they lack the right tools to help them to avoid it. For example, there is an organization whose devs work with extremely complex systems and drown in software complexity. Even if they don’t see any way out of it, this is much less a problem because if they understand that they want to get out of that situation, they can use the right tools, processes, and techniques to help them.

So I’d say understanding the problem is the first step, and being able to find a solution is the second step. Not understanding the problem or not knowing how to find a solution can cause orgs to be drowning in grunt work and ultimately lose their talent, or at least lose the motivation amongst R&D teams. 

“Ignoring the developers’ motivational factors is the first cause of grunt. And it’s the most fundamental reason”. Baruch Sadogursky, JFrog 

Lee: Do you feel that developers today have embraced the idea that a large part of their daily tasks will include spending time on what they consider boring, necessary & easy development? Or do you think they still expect to spend most of their time delivering innovative solutions?

Baruch 🎩: I think it’s the other way around. I believe developers actually know and expect to spend less time doing grunt work. It was previously perceived as something unavoidable, but today more and more developers understand that there is a way around it.

The fact that modern systems are large, complex, and hard to understand doesn’t necessarily mean that you’ll drown in grunt work. On the contrary, today, devs understand that they need to deploy processes, techniques, and tools that can decrease the amount of repetitive, tedious tasks. 

This way, they can go back to what gives them joy: the new work, innovation, and creation. 

“Grunt work was previously perceived as something unavoidable, but today more and more developers understand that there is a way around it.” Baruch Sadogursky, JFrog 

Lee: In one sentence, what is the most significant effect of grunt work on devs?

Baruch 🎩: When we talk about what motivates devs, you need to understand why grunt work is awful. If you know my presentations or talks, I recommend tons of reading materials each time. So this interview won’t be an exception, and I feel that I have to recommend at least one book today.

One of the most important books about motivating people is Drive, written by Daniel Pink. This book explains what motivates employees beyond “the carrot and the stick approach.” And this is exceptionally important when we talk about mental workers like engineers and developers, as opposed to maybe people employed in grunt-oriented work, to begin with like a factory or in agriculture and stuff like that.

Daniel Pink claims there are three main drivers for modern motivation and grunt work affects every one of them.

• Autonomy – the ability to do something yourself. When you drown in grunt, mainly when operating in complex systems of modern software engineering, you can’t be autonomous. You constantly need help from tons of other people to help you do something that you don’t even know you need to do. So Autonomy is out.  
• Mastery – the ability to grow and to master. When you do grunt work, you don’t grow. If you don’t grow, you don’t learn something new. So there is no mastery.
• Purpose – the ability to create new things, writing new code. Doing grunt work keeps you away from that. So the purpose is also out.

So all three motivators are out the window when you do too much grunt work, and obviously, that kills motivation and leads to burnout. 

How can you balance grunt work with fun work?

Lee: How do you guys balance grunt work with fun work? And who in the organization is responsible for keeping the balance?

Baruch 🎩: It’s a joint effort of everybody, and we can talk about how each layer of the organization can help. So obviously, it starts with the developers themselves. Once the developers start realizing what’s happening, they spend more time on grunt work. As a result, they will become unmotivated and won’t have the drive to go forward.

In situations like these, they need to ring the alarm. They need to articulate what’s happening, why it’s happening, and what needs to change in terms of processes and tools. The devs must escalate the problem, just like the quote you provided. And say to their team leaders – hey, I’m drowning in grunt work, I’m not motivated any more help! Let’s find a way out of it.

And here, by the way, the tools come into place. If you use the right tools based on the developers’ point of view, you can work more efficiently and minimize the time spent on grunt work. And it’s the managers’ and the organization’s responsibility to listen to them and say, hey, we understand that. Let’s explore the solutions bottom up and try to implement some. So everybody in the organization is responsible, the developers themselves as they’re directly affected, and the organization that should make a significant effort to minimize grunt work. 

Lee: What would you consider to be the indicators leading to a gradual decline in development teams’ motivation that managers should be aware of?

Baruch 🎩: So, there are two types of indicators. There are the early indicators and the proxies. The direct indicator is the behavior of the developers. And you can analyze it by observing their behavior and work performance. Also, you can do it by conducting constructive one-on-one meetings and looking for burnout signs through feedback. 

Burnout is a direct indicator that the grunt work took over. And this is because burnout is the result of a lack of motivation. And a lack of motivation, as we just discussed, is the result of grunt work. So that’s a direct indicator.

But you also have a lot of proxy indicators that might lead you to answer the question: Do people really drown in grunt work? These proxy indicators include the code’s quality, the number of regressions, the number of bugs, delays on schedule, and these kinds of stuff. So when work starts to pile up, you might ask, why is this happening? What are people doing? And then, you may discover that one of the reasons for this situation is the complexity that hurts both the ability of people to understand and move forward and the amount of grunt work that they’re doing. 

Lee: Would you say there is a direct connection between highly motivated teams and delivering high-quality software?

Baruch 🎩: There is a direct link because, as we spoke, developers are naturally motivated when doing what they love to do and what they know. Unmotivated developers obviously will do their job poorly. And there is a lot of research on this topic. 

Another reason, which is even more direct, is the time and effort put into the work if you spend 60% on new work. Or if you spend 30% on new work. The amount of the code you are generating will be twice as much. And that affects how many features you can implement and how much of the system you can implement. Plus, writing new code is always better than working on the old code.

What tools and processes can minimize grunt

Lee: You mentioned some tools and processes that could minimize grunt work throughout the interview. Would you be able to elaborate on those, please?

Baruch 🎩: Absolutely. Yes. There are two essential processes that a company or an organization must adapt to minimize grunt work. The first is agile. And the second is DevOps agile.

Agile minimizes grunt work because it’s flexible and helps fix big problems before or as they appear. So when going agile, you can kind of jump on issues as they start.

DevOps minimizes grunt work because dev-ops helps to communicate better within the organization, which can help prevent problems before they even start.

When we talk about tools, there are a lot of tools for implementing agile and DevOps processes. But obviously, I’d like to mention Sprkl because Sprkl helps developers deal with grunt work faster. The platform provides individual devs with personal feedback and insightful information about their code’s execution impact that otherwise would be grunt work to find—an easy way to fix issues quickly without drowning in software complexity. Learn more about how Sprkl can fix issues: Here.

So, yes, none of us is perfect, but bugs happen, mistakes happen, but being able to solve those mistakes faster minimizes the amount of grunt. Yes, there is no magic bullet. No one can say, you know what, tomorrow just implement this or that. And you’ll work 100% on your code. This will NOT happen.

There will always be bugs, regressions, issues to be solved, and miscommunication that results in technical problems. But as I just mentioned, the right tools will allow you to attack the problem and solve it. This is the difference between drowning in grunt work or quickly fixing the problems and moving forward to new work. So. Yes! Definitely processes and tools can help. If you are a developer or a team lead, you owe it to yourself. 

Lee: Thank you so much for your time. Just before we wrap up, And since the topic of this talk is devs’ motivation: Can you please tell us what motivates you and what demotivates you as a developer? Any other tips you’d like to share with us? 

Baruch 🎩: As I mentioned, try to see the big picture. Try to see the grunt work as part of your job. There is no way to avoid it completely. No one is perfect. For me, it works because I understand that, yes, grunt is a part of my job, but I do everything I can to minimize it. So, this is what keeps me motivated; even when I work on the less pleasant tasks of fixing bugs, doing maintenance, troubleshooting systems, debugging systems, etc, I know I’ll eventually get to create. Also, knowing that you have the best processes and the right tools to support you should keep you motivated:)

Lee: Great. So thanks again for joining us today! Thank you so much for everything; that was helpful and insightful. So we can call it a wrap. 

Any thoughts, suggestions, or questions about Sprkl or for Baruch, feel free to shoot me an email at [email protected], and I’ll address them with Baruch.

Connect with us: Here.

Sprkl offers a Personal Observability platform that provides insights about every code change execution impact right into your IDE.