What’s The Recipe For Burnout?

What’s The Recipe For Burnout?

9 de diciembre de 2021 | Compiler Team

Comunidades

Cultura y proceso

Open source

Comunidades de open source

Desarrollo profesional

Compiler • • What’s The Recipe For Burnout? | Compiler

What’s The Recipe For Burnout? | Compiler

About the episode

Working on a popular open source project can be demanding. Just ask the maintainers on GitHub’s ReadME podcast. In a special episode of Compiler, we teamed up with ReadME’s Brian Douglas to learn more about the challenges open source maintainers face—and investigate why burnout seems to be so prevalent in the industry.

Burnout’s always going to be a problem. But we can still try to avoid it. To do so, we wanted to understand the recipe for burnout: what factors could we identify that seem to bring it about? This episode’s guests share their own experiences and bring the weight of academic research to uncover the reasons too many of our beloved maintainers burn out.

Compiler team Red Hat original show

Transcripción

Angela, did you know that we are not the only tech podcast out there?

We're not the only tech podcast? I'm joking, of course not. I listen to a number of tech podcasts.

So do I, there are so many good tech podcasts out there. One that I just discovered is called the ReadME Podcast from GitHub. Have you heard of this one?

No, I haven't. What is it about?

I could tell you about it, but what I really wanted to do was invite the host of that show to talk to us right now.

Even better.

All right, welcome Brian Douglas, bdougie.

Hey, and thank you very much for having me. I'm excited to chat with you all about why I'm here.

Welcome.

We're happy to have you, thanks for joining us.

Yeah, no problem.

Why don't you tell our listeners who you are?

I am Brian Douglas, AKA bdougie, and I am a developer advocate at GitHub and co-host of the ReadME Podcast.

Why don't you just tell us a little bit about ReadME?

The ReadME project is an opportunity for GitHub to interview some of the most impactful maintainers in our ecosystem, which is the DevSpace. We have conversations about where they started, their first interaction with the computer, but also what they're working on today to figure out how folks got to where they are, but how they sustain themselves.

Here's what I'm curious about. One, what is a maintainer?

That's a great question. In the context of code, these are folks, who either create projects or take the role of mantra of maintainer on a project. On the actual GitHub platform, you could actually set up in your repository to your organization, the role as maintainer. As folks grow projects, they invite other maintainers to answer questions, review PRs, open and close issues. This basically just get the project to move forward in cutting future releases.

I think what I've found so interesting about your interviews is that it often seems like the role of the maintainer tends to grow over time. It can very easily become overwhelming; something that started as a small project or something you spend a little bit of time on can very quickly grow into being really overwhelming.

Yeah, and like most maintainers, they start writing code because they love what they're doing. They love the little side project, love seeing performance increases, or getting adoption and issues opened.

There's actually an interview we did with this developer, Yanni, who's previously the maintainer of this project called Foam. I say previously because that was what the discussion was about. It's understanding burnout and understanding when to walk away. With Yanni, his project became so popular at the beginning of the pandemic in 2020 that he loved the interactions and the conversations so much. He just never said no. It got to the point where he had enough people reaching out to him, even with this being an open source project VCs asking to invest millions of dollars and folks asking for new features. He had to take the decision to step away from the project and say, "I realized I am burned out, I need to hand this over to somebody else."

It sounds like there are some elements in this story that when combined might lead to burnout, and I'm wondering now, what are those contributing factors? Could we put together a recipe for burnout?

This really sounds like a question for one of our producers. I think we need to find someone that can help us explore this more.

All right bdougie, we are going to say goodbye to you right now. We are going to put Johan on the case, but we are going to be back with you. We will come back to you at the end of the show. Sound good?

Sounds good. See you soon.

This is Compiler, an original podcast from Red Hat.

We're your hosts.

I'm Brent Simoneaux.

I'm Angela Andrews.

We're here to break down questions from the tech industry. Big, small, and sometimes strange.

In each episode, we go out in search of answers from Red Hatters and people they're connected to.

Today's question, what's the recipe for burnout?

Producer and baker Johan Philippine is here to help us out.

All right, Johan, we have put you on the case. We are trying to understand burnout. What do you have for us?

Quite a bit. I spoke with maintainers who have experienced burnout, and I've also spoken to some people who actually did some empirical research on the causes of burnout. Now it wasn't all that difficult to find people who've burnt out.

I believe that.

I spoke with Nolan Lawson, who wrote a widely read blog post about his experience as a maintainer.

My name is Nolan Lawson. I'm a software engineer, a JavaScript programmer, JavaScript Slinger, basically.

His story is pretty typical. He got started contributing to a project and noticed that he was able to help with some open issues. The more he helped, the more he found that he enjoyed doing that.

It was just kind of fun to get involved, and then I noticed, "hey, there's all these other open issues that could also be improved." I started kind of working on those and before I knew it, I was one of the top maintainers of the project. One of the go-to people for questions and support.

Unfortunately, it didn't always end up being something joyful for him.

In my post, I use this metaphor of having a line of a hundred people standing outside your door, all just kind of patiently waiting for you to let them in and deal with them one at a time. Each one is bringing with you a problem. Nobody comes to your project and files a bug on you or opens a poll request because everything is fine with the world. They love your project and it perfectly satisfies all their needs and they just ride off into the sunset.

That hit me to my core. I remember when I used to be on the help desk, and when your phone rang, you were filled with dread because you knew someone was calling to complain about something. I'm likening that to being a maintainer, when he was like, "you open your door and there's a hundred people standing in the line." I'm looking at my phone and every light is lit. It's like, oh my gosh, how overwhelming is that?

That's the first ingredient in our recipe, an overwhelming or seemingly unending amount of work. That would be draining enough if it was your day job, which to be clear for many people, it is their day job to be a maintainer. For a lot of them, and in Nolan's case, this role is something they do in their spare time.

This was something that I was doing on nights and weekends. It got to the point in 2016, where it was basically my only hobby and I was doing it every night, and every weekend.

That sounds like a lot of non-work, work. That's ingredient number two, not having healthy limits or boundaries on your work. Why would he put himself through that?

The guilt was a huge part of it. I constantly had people telling me, "hey, I lost data because of this bug permanently," or "my app that I build, I'm struggling to make it work."

One example that was both encouraging and discouraging was, I remember during the Ebola outbreak in 2015, there was a team that had used our project that had used Pouch TV to build an app. They were actually using it to do contact tracing out in Africa somewhere. It worked, but they ran into problems. When they described the problems to me, I thought to myself, "I remember that bug." I knew about that bug, but I didn't address that bug because I addressed other bugs instead. I actually had to think to myself, "did this impede their efforts?" Or should I just be happy that they used it in the first place.

That is heavy.

That is a lot of pressure to put on yourself.

Is he saying that in the back of his head, is this a matter of life and death?

That's very heavy and to carry that with you because he knew, he remembered like, "I remember that bug, but I didn't have time to get to it" because there were other things that he had to address.

Guilt is a powerful motivator, and that's really the third ingredient for our recipe for burnout. It's the sense of obligation to do more of never doing quite enough. We're going to get back to Nolan. There's a bit of a happy ending there. We started off pretty heavy with this episode, but it's going to get better, I promise. Before it gets better, it's also going to get a little bit worse, so buckle in everyone.

We're going to talk a little bit about some of the other pressures that maintainers can face because apparently the stress of helping even well-meaning people, isn't enough to deal with. There was a recent study put out by a research group that looked at the incidents of toxicity in open source communities. The reason that they started this study is because they noted on blog posts, and social medias, and all over the internet that this is a conversation that was becoming more prominent in the past few years. They decided to say, "hey, we can see all of this anecdotal evidence that something is happening. Let's do an actual study to see what's going on."

A lot of people are talking about this, but as researchers, they want to investigate. They want to put their methodologies behind this to see what's really going on here.

Well, here's Dr. Vasilescu on the initial findings of their study.

One thing that we're finding, and this is largely a confirmation of what people have talked about, is that entitlement is a really common theme. More so than hate speech or other things like that, that are more prevalent on other platforms.

For those of you who somehow aren't familiar with comments on the internet, they can be pretty awful.

You don't say.

That's really interesting. What we mean by entitlement is that often people take each other for granted and make these demands or requests that can be perceived as entitled. For example, "I've opened an issue two hours ago and you still haven't fixed it."

It's a perfect example for the fourth ingredient for burnout: receiving criticism that makes all the other ingredients stand out more. It's like adding salt. Like Dr. Vasilescu mentioned, there's been a lot of talk from maintainers and contributors about the problem.

We spoke to Naveen Raman. He's one of the students who worked on the project and he's about to bring out the receipts.

What we did is we started with a list of toxic issues. The way we found this was we went through GitHub recently or a couple years ago, what they did was they closed certain conversations because they were too heated. We looked at these conversations because we predicted that there would be a higher level of toxic interactions in these conversations. We looked through some of these conversations and we labeled each comment as either toxic or non-toxic. This is kind of our training dataset, and we use this to train an SVM, our support vector machine based classifier to predict. Given a comment in some GitHub conversation or GitHub issue, is it going to be toxic or not?

What they did is they then took this classifier and they applied it to many, many more open issues over the course of years. An archive of these issues from 2012 to 2018 or 2019, and the results?

It is rather rare, which is maybe the good news of this story. According to our estimates, it is less than 1% of conversations of issues contain instances of toxic. It's closer to half of 1% rather.

Fairly low.

It's interesting because there's like the numerical experience of that. That's half of a percent, and then there's the psychological experience of that, or the emotional experience of that. That half of percent can feel like a lot more than that.

Even though it's a minority of interactions, it might still be the one thing that affects you for a day, a week, a month. Now there's more, but it's back to the good news.

One interesting trend that we noticed was that the rate toxicity on GitHub overall tends to decrease over time. We took it from 2012 or 2018. What we found was that there was a significant decrease in terms of monthly and yearly rate of toxicity. We think this is because toxicity has become a bigger issue. People have started to notice it and people have started to take some type of mitigation steps.

To recap, maintainers have a tough, often unpaid job as it is. Let's not add to their stressors by being toxic on top of it all. We're going to get back to Nolan now, and what he actually did to resolve his burnout.

Shortly after that post, I basically stopped looking at any pull requests or issues for this particular project or satellite projects. I took all the little plugins I had written that were important to the community and I passed over a maintainership to other people. I gave the keys to the GitHub repos and the NPM published rights. I gave them to someone else and said, "here." I completely stopped looking at it entirely. I also went through a bunch of my other projects that were smaller projects related or unrelated, and aggressively said either this is something I actually care about and maybe I'll keep maintaining, or I don't care about this anymore. I just put a big unmaintained in all caps on the project to indicate that I was not going to respond to any issues or anything anymore.

That's pretty drastic action, right? He's completely cutting himself off from these projects that he was very invested in, but for Nolan, it's what he needed to do to recover.

It's important for us to stop every now and then, and really reassess all that we're doing. What do we really care about? What is really important to us? What do we value? It is really hard, especially when you really care about a lot of things, but sometimes we have to say, no. Sometimes we have to sort of stop doing some of the things that we're doing.

Stop doing, it sounds so simple, doesn't it? It really does.

Nolan told us a little bit about what he, as a maintainer, ended up having to do for those projects, once he stopped maintaining them.

For projects that have got some momentum in the community and maybe have an active group of people working on it, it can go on without you. That was really a beautiful thing for me as well, to feel that people who had been in the community, and were kind of giving me license to leave were saying, "it's okay to leave, it's okay to step back." That made me feel a little less guilty about it. For other ones where it was a one man show, those projects essentially died in that moment. I had to just accept that.

Stepping back has different repercussions depending on the stage that your project is in. For big projects, where you're more likely to have that line of a hundred people out the door, you're also more likely to have other maintainers who can step in and really help out when you have to step back. For smaller projects though, like Nolan just mentioned, when you're the only person maintaining it, that might be the end of the project. It doesn't necessarily mean that no one else can use it. There's always the option for that project, someone else could fork it and kind of take over for you.

When it comes to open source, outside of my day job though, I mostly focus on really small, well defined projects with a limited scope. That's kind of been my main strategy to avoid burning out again. I'll have very small projects, and one of the first things I'll do when I publish it is I will explain in the README what the project is not meant to do. I'm mostly not doing open source every single weekend, every single weeknight. I'll take breaks of weeks or more, if someone opens an issue and they're having a problem and I don't get to it until four weeks later, so be it. I put this thing out there for free. If somebody wants to use it, that's great. If they're having problems, it's not my responsibility. I don't consider it my responsibility anymore to try to swoop in and be a superhero for every single person out there complaining about something I made.

In more recent developments, he's also noticed a special kind of pull request.

Another thing I've noticed, I don't know if this has just happened to me, but since I wrote that post, where I said, "nobody comes to your project and files an issue on you when they're completely satisfied." I've actually have got a few people since then, who have filed issues in my projects and said, "hey, I don't have a bug. I don't have a problem with your project. I just wanted to say, it's really great and I love it. I used it and was successful, and I wanted to say, thank you." That kind of warmed my heart to see that, I've seen that a couple times.

Someone took his post to heart and appreciated the work that he did and told him so. That doesn't happen enough. I'm going to go out on a limb here and say being a maintainer is probably a really thankless job. To get a little thanks every now and again, kind of puts a little bounce in your step. It kind of makes it all worth it, so I'm so glad to hear that. That made me smile.

It really made me smile too, and got me thinking that if we could systematize something like this, get the positive reinforcement a little bit more regularly, it would really help maintainers feel like it's not so much of a thankless job.

I'm actually writing a list. How do you circumvent burnout? I'm sure everyone's list looks different. At the heart of it, everyone's going to say you have to set boundaries. You can't let something consume you because it sounds like a recipe for burnout. He sounded consumed.

I wonder if that happens to other maintainers, have they gotten those types of warm thank yous? Thank you for maintaining this project, a little tip of the hat every now and again, I wonder if that happens to other maintainers.

I really hope so because it sounded like it was a big help for Nolan in his return to maintaining. It's a small thing, it didn't cost anything except a little bit of time to open the issue and write the little note. Just like those negative messages can have an outsized impact, clearly these positive ones can counteract them, at least a little bit. I hope it's something that's becoming more widespread than just in Nolan's projects, because maintainers do a lot of work and a lot of the times it's voluntary, in their free time, and they deserve a little more recognition.

bdougie, you just had a listen to our episode on burnout and I'm wondering, how did it make you feel? I'm sure you hear about it and you talk about it on your podcast, but give me some of your thoughts on this subject and how pervasive it is in the community right now.

I would say that there's a lot of eye-opening data out there. I think as we're all trying to navigate in this new space, which is like remote/hybrid interactions is like being able to have those boundaries. Understanding that as humans, being okay with saying no, is something that even myself personally, I try to think of on a constant basis. I'm just thinking about all these new engineers, all the people coming out of college or starting their first jobs. They all also need to hear these stories. That way they could start off with the right foot forward.

Part of what Johan brought us was that, it's not always clear that you're talking to a human. It is really part and parcel with talking to people on the internet. A lot of times you're just sort of like pushing things out into space. What I think I love about your show is that it really puts a human behind the project.

It's very true because like a lot of folks, like you, strangers on the internet, in the night, it's easy to have a really quippy response, or a very like non-warm interaction.

That can lead to a lot of toxicity, right?

Exactly, more and more people get brave, but once you actually understand these humans... Or not even understand humans, understand there are humans. You tend to interact differently. What really comes down to is what we learned from the stories that are existent and the more conversation we have about burnout. More conversations about maintainers stepping down from projects, or looking for a new maintainer ship, we can help push the community in a positive direction by talking about some of the stuff that maybe isn't as positive at the end of it.

I like that we can talk about burnout being a real thing. It's not taboo. In the past five years or so, we would never hear people talking about their mental states, and their mental health. I like the fact that we're having this conversation, so people can turn the mirror on themselves, maybe if need be.

We've been talking about maintainers and open source communities, and in the tech industry as a whole. There's a lot of burnout happening, and a lot of people are talking about it more and more.

In the last two years, think about it. We've been working from home, and where our lines are getting more and more blurred. It's nice that folks can start talking about it and recognizing it, and then taking action on it.

Brian, your conversation with Yanni, that's actually out today, right?

Correct, it just shipped today. Anywhere you like to find podcasts and listen to podcasts then check out the ReadME Project, the ReadME Podcast, and also go to github.com/readme if you want to listen to it in the browser. Also, shoutout to the GitHub Twitter, where we post every time we publish a new episode, we do publish it from the Twitter account.

Listeners, we definitely want you to share your thoughts with us. Tweet us @RedHat, and make sure you use the hashtag Compiler Podcast. We want to hear your thoughts about burnout. Be honest. How are you dealing with things now? If you've had burnout, how did you turn a corner? Definitely share your secrets, our listeners would love to hear it.

Thanks bdougie, we'll catch you next time.

See you.

Thanks for joining us.

That does it for this episode of Compiler.

Today's episode was produced by Johan Philippine and Caroline Creaghead. Victoria Lawton has the fire extinguisher at the ready, so we don't burn out.

Our audio engineer is Kristie Chan, special thanks to Shawn Cole. Our theme song was composed by Mary Ancheta.

Big thank you to our guests: Brian Douglas, AKA bdougie, Nolan Lawson, Dr. Bogdan Vasilescu, and Naveen Raman.

Our audio team includes Leigh Day, Laura Barnes, Claire Allison, Nick Burns, Aaron Williamson, Karen King, Boo Boo Howse, Rachel Ertel, Mike Compton, Ocean Matthews, and Laura Walters.

If you like today's episode, please follow the show, rate the show, leave a review, share it with someone you know. It really does help us out.

Thank you so much for listening.

All right, see you next time.

Sobre el podcast

Compiler

Do you want to stay on top of tech, but find you’re short on time? Compiler presents perspectives, topics, and insights from the industry—free from jargon and judgment. We want to discover where technology is headed beyond the headlines, and create a place for new IT professionals to learn, grow, and thrive. If you are enjoying the show, let us know, and use #CompilerPodcast to share our episodes.

What’s The Recipe For Burnout?