[tristor]

Unfortunately, people who take ownership and accountability are often the same people that take pride in their work, which means they aren’t emotionally detached. As long as you're emotionally attached to your work, burnout is a real risk whether you get paid or not.

Ironically, the solution from my perspective is the opposite of most advice. It’s not for everyone to become drudging zombies apathetic about their work and just kicking the can, it’s that more people take pride, ownership, and accountability in all aspects of their lives.

Having gone through burnout and a lot of therapy, my conclusion was that my burnout (and I think others too) was caused by being a caring decent person in an uncaring world. There are far too many people who surround all of us who are apathetic and/or incompetent, yet are entrenched, and being “forced” to carry their burden has an amplified effect on the misery we feel when doing that work. When you work with a team that only has accountable, competent, engaged people it becomes energizing rather than draining.

Realistically even if I am entirely correct above, this isn’t a solution. This is just a confirmation that in my experience the old adage “hell is other people” is true and the primary driver of burnout.

[pdimitar]

> my conclusion was that my burnout (and I think others too) was caused by being a caring decent person in an uncaring world

Yikes! That hits way too close to home. You didn't have to attack me like that.

In seriousness, this is a very astute and correct observation. Noticed it in myself and several others as well. It really pays off to correct your level of caring with what you see from your superiors and colleagues (and peers, in non-commercial activities).

[Buttons840]

I also see some truth in that insight.

A problem I have is I don't know how to work if I don't care. At my last job I tried to not care and succeeded, but then got fired for poor performance.

Are there sufficiently productive people who don't care? Or does everyone care, but some hold themselves to impossibly high standards?

I don't know how to separate "lower standards" and "stop caring". They are the same to me, because lowering my standards requires not caring about the things that comprise my high standard.

[pdimitar]

Oh, that one is easy IMO.

Create a backlog of tasks that you would want to do in a week. Then do it in a month.

Not caring doesn't mean slacking off. It means to reduce your output.

[Dalewyn]

>Or does everyone care, but some hold themselves to impossibly high standards?

That's your answer right there.

Do you know the age old saying "That is above my paygrade."? It means you shouldn't care more than what you are paid to do, which in turn will hopefully prevent you from burning out.

>I don't know how to separate "lower standards" and "stop caring".

You need to remember that your personal satisfaction ("I did good work!") is independent from your peers' satisfaction ("He did good work!"), and that correlation is not causation.

Life is short, draw a clear line between your personal and professional lives and budget your limited capacity for passion appropriately.

[Buttons840]

That explains how to set time boundaries, that's easy, set a timer, use the clock, etc. It's a mechanical process to adhere to time limits.

I'm thinking about things like finding millions of real user passwords in the test database. I complain and push and eventually we delete all the passwords from the database which breaks everyone's test build and in the end I don't make any friends. Did I care to much? I harmed my career because I cared.

Early in the project we agreed to organize our code into modules a certain way, but that fell apart and the code was not organized. I never knew where my code should go, the existing code was not organized, it bothered me a lot. How do I stop caring about that?

Shortly before I was fired a unit test I had written was passing even though it shouldn't have. The code was something like "assert(x == 1); assert(x == 2);" and the test was passing, it was impossible. It was some custom TypeScript stack and I got on the phone with the guy who created the tech stack and he agreed something was off, but none of us had time to look into what's up. I was fired before we ever got to the bottom of it.

These are the most recent examples, but I've had similar issues at other jobs. Imperfections, big or small often bother me more than other, and, again, I don't know how to lower my standards without also stopping caring, but without caring I have a hard time working.

[Dalewyn]

Again, you need to consider what you are paid to do.

Are you paid to care about "finding millions of real user passwords in the test database"? About caring how or whether your code is organized? About what should be happening in a unit test?

If you are paid to care about it, absolutely do so because that's your job. If you aren't, though, at most you should inform someone who is paid to care about it and then forget about it because it's not your concern.

Life is short and there is only so many waking hours in a day, so we need to budget them accordingly. If you can't bring yourself to be less passionate about your work even though you realize it's actually causing you and your coworkers problems, perhaps it's a sign you need to change professions entirely.

[Buttons840]

They say I'm paid to deliver working software, but I'm not able to do that with confidence until lots of things with the system are fixed.

Their actions, though, say that they want someone who hustles and creates bugs and then puts on a good show fixing the bugs they themselves created.

Saying it like that, I guess the solution is to just get out, but it's hard to accept "just find another job" as the solution when I'm not even employed right now.

[pdimitar]

I agree with your comments a lot, just want to point out that questions like these:

> Are you paid to care about "finding millions of real user passwords in the test database"?

...are never clearly answered, in 99% of all jobs everywhere.

[jynelson]

i think this is partially true, but i hesitate to call people zombies. the vast majority of people in the rust project are competent and engaged. the problem is they have different priorities and collaboration is hard when everything is bottom up. i have some more thoughts on this here: https://tech.lgbt/@jyn/111771440884089084

[tristor]

> i think this is partially true, but i hesitate to call people zombies.

To clarify, I was more responding from the perspective of the workplace rather than the Rust project. That said, I have been an open source contributor off and on since 2003 and my observation has been the situation isn’t much different.

In a project, rather than apathetic coworkers, you deal with users of the project that have complaints and expectations but without the ability or motivation to contribute themselves. I imagine Rust has slightly less of this than the consumer-focused projects I have worked on, but people are people at the end of the day. Contributing to any large project is largely thankless because there will always be one more complaint/demand issue, or one more PR from someone that didn’t read the contribution guidelines.

It can turn what you’re passionate about into a slog, and while the form may differ, it’s not meaningfully different from having apathetic or incompetent coworkers dragging you down.

To be honest, dealing with open source slog is slightly worse, because it takes much longer for the hope to die. Somebody that submits a bad PR seems to care somewhat, it’s not total apathy. Somebody that submits a whiny issue at least demonstrates that they used the project and cared enough to write. But both demand your attention without demonstrating competent contribution in and of themselves. It’s somehow worse than the coworkers that are on an in-office vacation.

[jynelson]

i agree! i hadn't realized you were talking about people who weren't already team members. they're usually well-meaning, but it's true that some drain a lot of contributor time on things that aren't important.

rust has a conflict avoidance problem. i think rust could be much more effective at saying no, and saying it more quickly. i want to talk about that in my next blog post.