16 ms·

The Rust project has a burnout problem

235 points by Philpax 3y ago

Francesca12 3y ago
[dead]
xoac 3y ago
maybe software doesn’t need to move so fast
- kramerger 3y ago
  But the Rust project isn't exactly known for moving fast. I looked up a basic function I needed for a project and it has been stuck in nightly since 2017. Golang added the same function in a dot-n release.
- tonyedgecombe 3y ago
  I think most consumers of software would agree with you.
markphip 3y ago
This is a good description of what life is like working on almost any significant open source project. The only thing not included was the comments from overly entitled users that saps whatever morale and energy you have left. Probably best he did not include that though as that is what all discussion would be about. I am not sure what to do about the burnout problem. The way he described it is very on point though. Since everyone working on the project is overloaded there is a great feeling of things only get done if you do them. Most of my open source work was in the pre-GitHub days when we used mailing lists, not pull requests, to build community. I do think there was something better about that for the project itself as it encouraged a lot more discussion and community building. PR's and Issues become silos and are not great for general discussion. I think they also encourage drive-by contributions which honestly are intoxicating initially but once you see people are not coming back become defeating.
- oaiey 3y ago
  Not only open source. Also anyone taking ownership in companies end up like that. The difference is: The person gets paid and is ideally not emotional involved.
  - markphip 3y ago
    It is a fair point, but I think your last sentence hits on the problem. People that contribute regularly to OSS projects are nearly always emotionally invested. It brings a lot of pleasure initially which I think also contributes to the eventual burnout. These are hard problems.
  - tristor 3y ago
    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.
    - jynelson 3y ago
      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 https://tech.lgbt/@jyn/111771440884089084
cjs_ac 3y ago
> the best way to help the project is to keep contributing for it for years. to do that, you have to avoid burning out, which means you have to treat yourself well. When I was a schoolteacher, the way I expressed this is that you have to do the job in such a way today that you're capable of doing it again tomorrow. This did not go down well and I am no longer a teacher.
- vouaobrasil 3y ago
  Personally, I don't think it is natural to sit in the same role for more than a few years. And that's not just the primary tasks of the job -- the same people, the same administration, the same bureaucracy. I do feel that virtually no jobs will allow you to grow as a person and enjoy life. Here, by "job" I mean the traditional kind at a corporation or medium-sized organization. After seven years of working in such organizations I realized the only thing that was fulfilling was quitting and doing a bunch of random things like contracting, content-creation, and other passive income streams. Of course, that may not be for everyone but I still think (after talking to hundreds of colleagues in various places) that after a while, most jobs suck. Sure, some of them pay well but then again, I personally feel that no amount of money is worth spending the best part of your youth doing mostly meaningless things. And, if the money IS good enough, it makes sense just to work for a decade and then retire early...
  - nyokodo 3y ago
    > I personally feel that no amount of money is worth spending the best part of your youth doing mostly meaningless things It depends on why you’re doing it. Supporting a family, and contributing money and spare time to your community, are very meaningful. I’m building <yet another API> for <Company> in order to do my real job which is being a parent and citizen.
    - vouaobrasil 3y ago
      That is true. I agree with it for sure. Just so many jobs don't let you do this. But if you managed to find it, that's great!
datadeft 3y ago
It seems a bit far fetched.
riwsky 3y ago
Turns out there are some resource management problems even rustc can’t solve.
- Faaak 3y ago
  That's quite uncool of you, even if it's supposed to be a joke
  - jynelson 3y ago
    i thought it was funny lol
    - aio2 3y ago
      same
- amelius 3y ago
  Some resource management problems are better automated.
gtirloni 3y ago
> new contributors make PRs. they make silly simple mistakes due to lack of experience; you point them out and they get fixed. this can be fun, for a time. what it’s teaching you is that you personally are responsible for catching mistakes. Every team I've worked with that was feeling exhausted about code contributions actually needed to focus on better documenting guidelines but most importantly, improve CI. Catching silly mistakes is the textbook definition where automating stuff can help the most. This should improve reviewer's peace of mind and speed things up because people will work by themselves to fix things before asking for a review. I don't know what's the CI situation in the Rust project but if it's anything like what I'm used to, it probably needs improvement. Adding more human-hours to reviewing things isn't sustainable.
- raverbashing 3y ago
  I agree At the same time lint tools sometimes move into the 'pedantic unhelpful' field because those things are the easiest to check (no, nobody likes pep8 and its brain-dead char limit - Black is much better) But yes, if it can be automated it should be automated
- jynelson 3y ago
  rust's CI is quite extensive actually; there's a talk on it here: https://www.pietroalbini.org/blog/shipping-a-compiler-every-six-weeks/ https://www.pietroalbini.org/blog/shipping-a-compiler-every-... CI is good. more tests are good. but there's a limit to how much they can catch. here is an example: there is an internal type checking API called [`resolve_vars_if_possible`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_infer/infer/struct.InferCtxt.html#method.resolve_vars_if_possible https://doc.rust-lang.org/nightly/nightly-rustc/rustc_infer/...). this needs to be called on the output of almost any call to `.normalize()`, or you will get an internal compiler error. the conditions under which you get an ICE are quite complicated; sometimes you need 6 or more items in the crate with `impl Trait` or type_alias_impl_trait or const generics involved. but it's very easy to see there's a bug just by looking at the code and seeing the missing `resolve_vars()` call. how can we automate this? well, rustc has a mechanism for "internal lints", but they're somewhat annoying to write - you're basically writing a new compiler pass, and it needs to not have false positives. it's much easier to just catch this one instance. so the reviewer, who's already burned out, does this quick manual review instead.
bArray 3y ago
I see a trend in blogging to stop using capital letters - it makes it much harder to read. It's not even like they don't know how they work: > rotate responsibilities. don’t have the same person assigned to the majority of PRs.
- la_oveja 3y ago
  i take it as an aesthetic move, like using weird monospace fonts... adds the writers personality to it
  - bArray 3y ago
    It's not that unique or quirky when a considerable number of people are doing it. There are also other things like emojis, memes, etc, but all lowercase makes it simply harder to read.
rkangel 3y ago
Do other people react as strongly as I did to the lack of capitalisation at the start of sentences? The post is generally "well" written with good grammar and punctuation so I find it strange - it feels like a style choice. But the style choice just instinctively makes part of my brain feel like it's written by a child.
- navane 3y ago
  I didn't even notice. The structure of the post is very strong.
- Hamuko 3y ago
  Yeah, I don't really have the patience to read through uncapitalised text for long. Enough blog posts around to skip some of them.
- vouaobrasil 3y ago
  I hate it with a passion and would never read any text without capitalization.
- dml2135 3y ago
  Ha, that’s funny, I didn’t even notice.
- Traubenfuchs 3y ago
  It's painful for me, apparently my brain normally uses the low frequency capitalised letters as anchor for "navigation" in big blocks of text.
- Max-q 3y ago
  Yes! I didn't write a comment here about it, due to the forum rules, but I'm glad you pointed it out.
- block_dagger 3y ago
  not an e.e. cummings fan i take it.
- jwmoz 3y ago
EmilyHughes 3y ago
If you don't get paid to do something it's not fun, how about you just stop doing it?
- jynelson 3y ago
  it's not that simple. people form an emotional attachment to the work; they feel obligated to keep doing it. https://news.ycombinator.com/item?id=39027226 https://news.ycombinator.com/item?id=39027226
  - EmilyHughes 3y ago
    That might be, but then don't wonder if people look at you strange if you tell them you got burnout from a job where you never met any colleagues and didn't get paid either.
- palata 3y ago
  Just like ending a relationship. Sometimes it takes time to realise that it is not fun anymore.
mgaunard 3y ago
Just close PRs that don't meet basic quality criteria, and you will go through them in no time. Oh, but I suppose that's not compatible with the "no one left behind"-type rust manifesto.
- Ygg2 3y ago
  Then you get into Stackoverflow territory - closed for X.
thomascgalvin 3y ago
I think this is true of most open source projects, and probably all of the bigs ones. Software in general has a burnout problem. I am regularly stumbling around like a zombie by friday afternoon, and that's just for my actual, paid job. If you added maintenance of a large open-source project like Rust ... I don't see how I would manage it, at least without letting my health -- and probably my family -- suffer for it. I know that some people are fortunate enough to be paid for their open-source work, but that doesn't mitigate the burnout from software engineering itself. Add to that baseline stress the fact that your customer is "the internet" and feedback is often coming from "whoever is currently angriest," and it seems wildly unsustainable.
twen_ty 3y ago
This is why I think that C++ will be around in the next 50 years but Rust? I can't tell.
- chillingeffect 3y ago
  C is/was fueled by positive energy: "Let's be (relatively) portable and improve on Assembly." Rust seems to have vengeful victory at its heart: "Let's sock it to those reckless, ignorant C programmers."
  - trealira 3y ago
    It's more like "let's improve on C by catching errors C compilers don't check." Rust took a lot of inspiration from Cyclone, which was meant to be a safe version of C. Writing C makes certain classes of sloppy assembly bugs unwritable, like accidentally using the wrong calling convention, forgetting to preserve a register, or forgetting to pop something off the stack. Similarly, Rust makes classes of sloppy C bugs unwritable, like using a dangling pointer. Why do you view that as an attack on C programmers? It's no more an attack on them than C was an attack on assembly programmers.
    - uecker 3y ago
      The attack is the idea that everybody needs to have the same priorities that Rust has and so everybody else is wrong. With regard to memory safety, this even something I could partially agree with, but then there is another problem: In contrast to Cyclone, which was a safe version of C, Rust changes a lot more than simply adding memory safety features. It is not at all like C but has completely different syntax, different conventions, and complexity similar to C++. So in many ways, I find it inferior to C (although I agree that memory safety is good), but Rust people think it is superior in every way and behave like this.
      - deleted 3y ago
        [deleted]
      - 3y ago
PoignardAzur 3y ago
I've recently been contracted to do some open-source work in the Rust ecosystem, and this article feels like a warning from my future self to me. I'll make sure to heed it. > “it won’t get done if i don’t do it” and “i need to review everything or stuff will slip through” is exactly the mindset of my own burnout from rust. I've already caught myself getting into this mindset a few times. For one particular issue, I got a bit mad because it felt like I was the only one trying to move a critical issue forward, and other people were treating it as a distant priority. In that case, what helped was moving away from the issue for a few days, and seeing other people pick up speed and make progress on it in the meantime. Having supportive colleagues is super helpful. I don't know how much this will be a problem in the coming year. I'm hoping we can strike a healthy balance.
- jynelson 3y ago
  <3 wishing you well. good luck with your work. yes, there are lots of things you can do to get work done that don't involve you personally writing the code. i would like to write a post about that at some point but i have at least 3 blog ideas up in the air currently so it might take a while
hprotagonist 3y ago
> i’m not going to name names because either you know what i’m talking about… Consider: this attitude of nod and a wink “can’t name names” strongly contributes to burnout in every community i’ve seen it in. Rust has it in absolute spades, but i’ve seen it eat other groups alive too. Maybe we can stop doing it.
- jynelson 3y ago
  this is mean-spirited. i am not talking about malfeasance in the project, i am talking about people who are trying their goddamn best and whose lives and jobs are at stake. what benefit do you think would come from announcing to the world "hey this person might shortly be unable to do the work that makes them a living"?
reisse 3y ago
> new contributors make PRs. they make silly simple mistakes due to lack of experience; you point them out and they get fixed Sometimes the right answer is to immediately say "your PR is not up to project standards, it won't be reviewed, please revise it yourself if you want it accepted". It's not a job of a maintainer to educate every wannabe-contributor.
- UncleEntity 3y ago
  Thinking back to my earliest FLOSS contributions, I don't agree. Up to a point. Some of the PRs I submitted were pretty dumb and a complete waste of someone's time to review/reject but they showed enough patience to help me get "over the hump" and to eventually get commit access to the repo -- which didn't really help with getting features implemented because I have an apparently unlimited supply of dodgy ideas and would get "why is this needed?" a lot. I also had a habit of getting code to about 80% there before doing a PR "for discussion" knowing full well the lead maintainer would fix up the remaining 20% if it were a valuable enough addition. Probably also helped that the project has a history of working with GSoC students and the devs were a generally helpful bunch with getting new contributors up to speed on the codebase. Honestly, if they weren't so welcoming I'd be half the halfassed-coder I am today.
hannofcart 3y ago
What's not clear to me from the post is, is the author talking about just the rust-lang projects? Isn't this a characteristic of active contributors of many (or I daresay, most) large open source projects? I am not an active contributor to any big OS project but whenever I stumble across the Github issues sections for one of them, they are full of "by when can we expect to see this fixed?" kind of questions.
medo-bear 3y ago
> if you are paid to work on rust, you likely started as an unpaid contributor and got the job later. treat it like a job now. do not work overtime; do not volunteer at every turn; do not work on things far outside your job description. But if I don't work overtime how can I rewrite everything in Rust?
- burjui 3y ago
  Simple: attract more people to do it. If everyone ditched their $LANG and started rewriting everything in Rust, we could do it in a month.
- nusl 3y ago
  Ask your employer to let you do it in work hours rather than burning employees out with overtime for essential maintenance tasks
nightowl_games 3y ago
I'm a game dev at a small studio. I have a discord full of gamers who all want me to do something or at least pay attention to them. Every time I release something new, someone hates it. It was hard for a bit, but I've been doing this for years. Honestly you just gotta tune out the noise and prioritize what you want. Open source project is a bit harder because you have to collaborate more than I have to collaborate with my gamer fans, but still, stop people pleasing and prioritize yourself.
- nusl 3y ago
  I don't think it's in any way possible to please everyone, and even if you find the objectively-best solution, someone will hate it and be very vocal about it. Most of the folks will carry on and not say anything.
- aftbit 3y ago
  Relevant XKCD as always: https://xkcd.com/1172/ https://xkcd.com/1172/
- BobaFloutist 3y ago
  There's little I hate more than watching game devs engage with and respond to vitriolic fuming. Communities try so hard to tell people not to shit on devs, to be polite, to engage calmly and rationally, and then a certain subset of devs see a shitty, cranky post or comment getting attention and just can't help but weigh in to defend themselves. I understand the temptation, but it's deeply frustrating to see.
  - nightowl_games 3y ago
    I'm pretty hard on the gamers. I'm a dad now and most of the gamers are like 13 year old boys. So I try to teach them life lessons and I give them real consequences. I'm not very sensitive to negative feedback.
throwawaylolx 3y ago
[flagged]
- _aaed 3y ago
  I assume you say that be cause they don't capitalise the first letter of a sentence, which is fine since it's an informal blog post. This isn't a journal publication
  - throwawaylolx 3y ago
    Do you think that the difference between journal publications and blog posts are the use of capitalisation?
incomingpain 3y ago
It has been crazy how successful the rust project has been and they have been working to meet expectations. Lots of work to do. I just wish they had python syntax, I'm not smart enough for {};
- burjui 3y ago
  You are. Maybe you just need some additional time to get used to it. After all, even webdev monk... I mean people are used to {} in JS.
gillesjacobs 3y ago
The things that cause burnout like high expectations, pressure and endless bureaucratic project management slog sound like any software development job. Except the devs aren't getting paid which exacerbates the issue.
deleted 3y ago
[deleted]
fluoridation 3y ago
Excuse the flippant tone, but isn't this just "I treated my hobby as an unpaid second job and I burned out because I was working two jobs"? It's worse than a job, actually; some of the stuff OP says I don't say about even my actual job. I have a set of responsibilities and I just make sure to fulfill them. If my coworkers don't fulfill theirs I'm not going to shoulder them. Am I going to give them a hand? Sure. But I'm not going to do their job for them, and I'm not going to avoid delegating because I don't trust their judgement. If they fuck up, they fuck up; maybe the business suffers, but how is that my problem? OP shouldn't be thinking the way they are even if they were being paid to work on Rust.
ChrisMarshallNY 3y ago
I was the original author of an open-source, server-based, federated, infrastructure system, that has become fairly ubiquitous, for the demographic that it Serves. But it didn't start off that way. I shepherded it -almost entirely alone- for a decade, before I found a dedicated, motivated team that I trusted to take it over. They have done wonders for it. Most of its explosive expansion has taken off, under their watch. Walking away from it was the best thing that I could do for it. The last thing these folks need, is a "Benevolent Dictator," peering over their shoulders, and giving suggestions. During the gestation decade, I had to be a not-so-benevolent dictator, many times, as people tried to take it over, change it to suit narrow sub-demographics (at the expense of everyone else), and even change its entire raison d'etre. I got a ton of pretty vicious hate mail and there are people that still hate me (I cry myself to sleep over that, every night), after a decade. In one instance, I had to wait until one nasty old bastard popped his clogs, before I could spread it to the entire Pacific Northwest. During that time, I learned how not to behave. A lot of that hate, was because I'm actually pretty good at slapping back, but I really needed to learn diplomacy. Even when they are nasty, and we are right, we often need to just swallow our pride, and let the dervishes whirl. I don't miss working on it, and I'm really glad the new team are doing so good with it. I suspect there's very little of my original code in it, but the team mindset is still very much what I established. I am about to release a project that actually uses that infrastructure as a feeder to my backend.
CyberDildonics 3y ago
On top of the usual problems of a project becoming about maintenance and negativity, languages are destined to become diminishing returns and new languages always end up ruining themselves trying to add more to the foundations. You can see with D, Rust, haskell, and whatever else, the transition to working on an ecosystem with easy to use and polished tools, IDEs, debuggers, autocompletion just never happens. The languages that get heavy use like C++, java and python solved the chicken and egg problem of having an ecosystem at some point where there was an actual workflow instead of just a hacked plugin and a command line.
herdcall 3y ago
Not sure if this is Rust specific though; if anything Rust is easier to review because the compiler takes care of a large class of problems like use-after-free or race conditions. You let the compiler do the "review" on your behalf on most common issues and mainly focus on logic errors, which makes life much easier IMO for the reviewer.
mrec 3y ago
Brian Anderson (AKA brson, who as it happens used to head up the Rust project) wrote a good piece back in 2017 called "The Minimally-nice Open Source Software Maintainer" which has tips to reduce burnout/disillusionment in junior contributors. It's less geared toward preventing burnout at the top, but still well worth a read, and there's no reason much of it couldn't be applied in reverse. https://brson.github.io/2017/04/05/minimally-nice-maintainer https://brson.github.io/2017/04/05/minimally-nice-maintainer
estebank 3y ago
I'm surprised at how many people seem to focus so much on the effect of incoming PRs that require some mentoring to get them to a mergeable state or on "entitled users". I don't think those are significant contributors to burn out in the Rust project. Those you can ignore. More significant is "X is important, but I'm the only one that thinks so, so I have to carry X to completion single handedly". That causes a lot of the demoralization and heartache and guilt that contributes to burn out.
- jynelson 3y ago
  they both contribute a lot, although rereading my post i realized i dedicated more discussion to review burnout. i think it's a question of whether you feel more of an obligation to your users or to other people in the project, i've noticed you and i differ there. for me particularly, reviews were bad because there was a time component, if i waited too long people would get frustrated and give up.
  - estebank 3y ago
    I enjoy helping people get up to speed, but after a while it becomes overwhelming for sure. It's just that if I'm not around for some reason I know that others will review things, eventually. PR reviews will continue if I get hit by a bus, pet features likely won't. I am happy that other people have taken some of my stances around DX and run with it, so at least on that one facet of the project I feel like I succeeded in becoming dispensable.
dougdonohoe 3y ago
“it won’t get done if i don’t do it” sounds like every job I've ever had, not just open source
pierotofy 3y ago
A few guidelines to avoid maintainer's burnout: * Do not allow questions on GitHub issues, it's a poor place for conversations. I find Discourse or some other forum (or mailing list) a better place to do that, which allows community participation (and you can automate moderation using something like https://github.com/pierotofy/issuewhiz https://github.com/pierotofy/issuewhiz) * People owe you nothing, just as you owe them nothing; you don't have to fix an issue or merge a pull request because somebody opened one. * Try review and merge contributions, but on your own timeframe. If people have urgency, kindly invite them to get a paid support agreement. * Don't engage in quarrels; you always have the option to ignore or ban the offenders. * Document FAQs.
cangeroo 3y ago
I'm excited for the Rust project. But to add a superficial observation: It seems that the Rust project is not very diverse. Could that contribute to culture problems? It seems to have a disproportionately high, relatively to society, percentage of white, male, strongly LGBT-oriented personalities, who usually have a female Japanese cartoon character, or maybe a furry, as their profile picture on GitHub. Which is fine, whatever, but I worry that it suffers from groupthink and excludes different minds. Maybe it's hostile to plain people that just want to focus on programming? I suspect that people like Torvalds wouldn't survive long, and that's a shame. And if you want to be really critical: Maybe the leadership is happy that specific people are leaving? Maybe burnout is a tool? Maybe it's a way of social control and censorship? I personally hope that Rust finds more mainstream support and funding, because I'd love to work full-time in Rust for many years to come.
- camdenlock 3y ago
  Bingo. Nobody wants to recognize this issue, for various inconvenient reasons. Rust has a major insularity problem.
deleted 3y ago
[deleted]
camdenlock 3y ago
[flagged]
- soulbadguy 3y ago
  > it also skews communist. Interesting claim. Care to substantiate it a bit ?
  - nerdponx 3y ago
    Even more interesting is the implication that the Rust project governance and structure is somehow more socialist than other large OSS projects.
soulbadguy 3y ago
The whole industry has a burnout problem... I can't imagine the pressure with something as visible and complex as rust compiler and tool chain. The authors is pointing the best remedy, encourage and promote health work habits.
alchemio 3y ago
Are there companies contributing to the Rust compiler?
- jynelson 3y ago
  yes. most of the "platinum members" of the foundation have multiple full time employees working on rust: https://foundation.rust-lang.org/members/ https://foundation.rust-lang.org/members/
WuxiFingerHold 3y ago
It felt like a depression. But only of the core development. Organisation and ecosystem are evolving. The layoffs by Mozilla in 2020 might play a role here. On the other hand, when withoutboats started writing about async again recently, it felt like the sun rises again.

235 points by Philpax 3y ago

Francesca12 3y ago

[dead]

xoac 3y ago

maybe software doesn’t need to move so fast

kramerger 3y ago
But the Rust project isn't exactly known for moving fast. I looked up a basic function I needed for a project and it has been stuck in nightly since 2017. Golang added the same function in a dot-n release.
tonyedgecombe 3y ago
I think most consumers of software would agree with you.

markphip 3y ago

This is a good description of what life is like working on almost any significant open source project. The only thing not included was the comments from overly entitled users that saps whatever morale and energy you have left. Probably best he did not include that though as that is what all discussion would be about. I am not sure what to do about the burnout problem. The way he described it is very on point though. Since everyone working on the project is overloaded there is a great feeling of things only get done if you do them. Most of my open source work was in the pre-GitHub days when we used mailing lists, not pull requests, to build community. I do think there was something better about that for the project itself as it encouraged a lot more discussion and community building. PR's and Issues become silos and are not great for general discussion. I think they also encourage drive-by contributions which honestly are intoxicating initially but once you see people are not coming back become defeating.

oaiey 3y ago
Not only open source. Also anyone taking ownership in companies end up like that. The difference is: The person gets paid and is ideally not emotional involved.
- markphip 3y ago
  It is a fair point, but I think your last sentence hits on the problem. People that contribute regularly to OSS projects are nearly always emotionally invested. It brings a lot of pleasure initially which I think also contributes to the eventual burnout. These are hard problems.
- tristor 3y ago
  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.
  - jynelson 3y ago
    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 https://tech.lgbt/@jyn/111771440884089084

cjs_ac 3y ago

> the best way to help the project is to keep contributing for it for years. to do that, you have to avoid burning out, which means you have to treat yourself well. When I was a schoolteacher, the way I expressed this is that you have to do the job in such a way today that you're capable of doing it again tomorrow. This did not go down well and I am no longer a teacher.

vouaobrasil 3y ago
Personally, I don't think it is natural to sit in the same role for more than a few years. And that's not just the primary tasks of the job -- the same people, the same administration, the same bureaucracy. I do feel that virtually no jobs will allow you to grow as a person and enjoy life. Here, by "job" I mean the traditional kind at a corporation or medium-sized organization. After seven years of working in such organizations I realized the only thing that was fulfilling was quitting and doing a bunch of random things like contracting, content-creation, and other passive income streams. Of course, that may not be for everyone but I still think (after talking to hundreds of colleagues in various places) that after a while, most jobs suck. Sure, some of them pay well but then again, I personally feel that no amount of money is worth spending the best part of your youth doing mostly meaningless things. And, if the money IS good enough, it makes sense just to work for a decade and then retire early...
- nyokodo 3y ago
  > I personally feel that no amount of money is worth spending the best part of your youth doing mostly meaningless things It depends on why you’re doing it. Supporting a family, and contributing money and spare time to your community, are very meaningful. I’m building <yet another API> for <Company> in order to do my real job which is being a parent and citizen.
  - vouaobrasil 3y ago
    That is true. I agree with it for sure. Just so many jobs don't let you do this. But if you managed to find it, that's great!

datadeft 3y ago

It seems a bit far fetched.

riwsky 3y ago

Turns out there are some resource management problems even rustc can’t solve.

Faaak 3y ago
That's quite uncool of you, even if it's supposed to be a joke
- jynelson 3y ago
  i thought it was funny lol
  - aio2 3y ago
    same
amelius 3y ago
Some resource management problems are better automated.

gtirloni 3y ago

> new contributors make PRs. they make silly simple mistakes due to lack of experience; you point them out and they get fixed. this can be fun, for a time. what it’s teaching you is that you personally are responsible for catching mistakes. Every team I've worked with that was feeling exhausted about code contributions actually needed to focus on better documenting guidelines but most importantly, improve CI. Catching silly mistakes is the textbook definition where automating stuff can help the most. This should improve reviewer's peace of mind and speed things up because people will work by themselves to fix things before asking for a review. I don't know what's the CI situation in the Rust project but if it's anything like what I'm used to, it probably needs improvement. Adding more human-hours to reviewing things isn't sustainable.

raverbashing 3y ago
I agree At the same time lint tools sometimes move into the 'pedantic unhelpful' field because those things are the easiest to check (no, nobody likes pep8 and its brain-dead char limit - Black is much better) But yes, if it can be automated it should be automated
jynelson 3y ago
rust's CI is quite extensive actually; there's a talk on it here: https://www.pietroalbini.org/blog/shipping-a-compiler-every-six-weeks/ https://www.pietroalbini.org/blog/shipping-a-compiler-every-... CI is good. more tests are good. but there's a limit to how much they can catch. here is an example: there is an internal type checking API called [`resolve_vars_if_possible`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_infer/infer/struct.InferCtxt.html#method.resolve_vars_if_possible https://doc.rust-lang.org/nightly/nightly-rustc/rustc_infer/...). this needs to be called on the output of almost any call to `.normalize()`, or you will get an internal compiler error. the conditions under which you get an ICE are quite complicated; sometimes you need 6 or more items in the crate with `impl Trait` or type_alias_impl_trait or const generics involved. but it's very easy to see there's a bug just by looking at the code and seeing the missing `resolve_vars()` call. how can we automate this? well, rustc has a mechanism for "internal lints", but they're somewhat annoying to write - you're basically writing a new compiler pass, and it needs to not have false positives. it's much easier to just catch this one instance. so the reviewer, who's already burned out, does this quick manual review instead.

bArray 3y ago

I see a trend in blogging to stop using capital letters - it makes it much harder to read. It's not even like they don't know how they work: > rotate responsibilities. don’t have the same person assigned to the majority of PRs.

la_oveja 3y ago
i take it as an aesthetic move, like using weird monospace fonts... adds the writers personality to it
- bArray 3y ago
  It's not that unique or quirky when a considerable number of people are doing it. There are also other things like emojis, memes, etc, but all lowercase makes it simply harder to read.

rkangel 3y ago

Do other people react as strongly as I did to the lack of capitalisation at the start of sentences? The post is generally "well" written with good grammar and punctuation so I find it strange - it feels like a style choice. But the style choice just instinctively makes part of my brain feel like it's written by a child.

navane 3y ago
I didn't even notice. The structure of the post is very strong.
Hamuko 3y ago
Yeah, I don't really have the patience to read through uncapitalised text for long. Enough blog posts around to skip some of them.
vouaobrasil 3y ago
I hate it with a passion and would never read any text without capitalization.
dml2135 3y ago
Ha, that’s funny, I didn’t even notice.
Traubenfuchs 3y ago
It's painful for me, apparently my brain normally uses the low frequency capitalised letters as anchor for "navigation" in big blocks of text.
Max-q 3y ago
Yes! I didn't write a comment here about it, due to the forum rules, but I'm glad you pointed it out.
block_dagger 3y ago
not an e.e. cummings fan i take it.
jwmoz 3y ago

EmilyHughes 3y ago

If you don't get paid to do something it's not fun, how about you just stop doing it?

jynelson 3y ago
it's not that simple. people form an emotional attachment to the work; they feel obligated to keep doing it. https://news.ycombinator.com/item?id=39027226 https://news.ycombinator.com/item?id=39027226
- EmilyHughes 3y ago
  That might be, but then don't wonder if people look at you strange if you tell them you got burnout from a job where you never met any colleagues and didn't get paid either.
palata 3y ago
Just like ending a relationship. Sometimes it takes time to realise that it is not fun anymore.

mgaunard 3y ago

Just close PRs that don't meet basic quality criteria, and you will go through them in no time. Oh, but I suppose that's not compatible with the "no one left behind"-type rust manifesto.

Ygg2 3y ago
Then you get into Stackoverflow territory - closed for X.

thomascgalvin 3y ago

I think this is true of most open source projects, and probably all of the bigs ones. Software in general has a burnout problem. I am regularly stumbling around like a zombie by friday afternoon, and that's just for my actual, paid job. If you added maintenance of a large open-source project like Rust ... I don't see how I would manage it, at least without letting my health -- and probably my family -- suffer for it. I know that some people are fortunate enough to be paid for their open-source work, but that doesn't mitigate the burnout from software engineering itself. Add to that baseline stress the fact that your customer is "the internet" and feedback is often coming from "whoever is currently angriest," and it seems wildly unsustainable.

twen_ty 3y ago

This is why I think that C++ will be around in the next 50 years but Rust? I can't tell.

chillingeffect 3y ago
C is/was fueled by positive energy: "Let's be (relatively) portable and improve on Assembly." Rust seems to have vengeful victory at its heart: "Let's sock it to those reckless, ignorant C programmers."
- trealira 3y ago
  It's more like "let's improve on C by catching errors C compilers don't check." Rust took a lot of inspiration from Cyclone, which was meant to be a safe version of C. Writing C makes certain classes of sloppy assembly bugs unwritable, like accidentally using the wrong calling convention, forgetting to preserve a register, or forgetting to pop something off the stack. Similarly, Rust makes classes of sloppy C bugs unwritable, like using a dangling pointer. Why do you view that as an attack on C programmers? It's no more an attack on them than C was an attack on assembly programmers.
  - uecker 3y ago
    The attack is the idea that everybody needs to have the same priorities that Rust has and so everybody else is wrong. With regard to memory safety, this even something I could partially agree with, but then there is another problem: In contrast to Cyclone, which was a safe version of C, Rust changes a lot more than simply adding memory safety features. It is not at all like C but has completely different syntax, different conventions, and complexity similar to C++. So in many ways, I find it inferior to C (although I agree that memory safety is good), but Rust people think it is superior in every way and behave like this.
    - deleted 3y ago
      [deleted]
    - 3y ago

PoignardAzur 3y ago

I've recently been contracted to do some open-source work in the Rust ecosystem, and this article feels like a warning from my future self to me. I'll make sure to heed it. > “it won’t get done if i don’t do it” and “i need to review everything or stuff will slip through” is exactly the mindset of my own burnout from rust. I've already caught myself getting into this mindset a few times. For one particular issue, I got a bit mad because it felt like I was the only one trying to move a critical issue forward, and other people were treating it as a distant priority. In that case, what helped was moving away from the issue for a few days, and seeing other people pick up speed and make progress on it in the meantime. Having supportive colleagues is super helpful. I don't know how much this will be a problem in the coming year. I'm hoping we can strike a healthy balance.

jynelson 3y ago
<3 wishing you well. good luck with your work. yes, there are lots of things you can do to get work done that don't involve you personally writing the code. i would like to write a post about that at some point but i have at least 3 blog ideas up in the air currently so it might take a while

hprotagonist 3y ago

> i’m not going to name names because either you know what i’m talking about… Consider: this attitude of nod and a wink “can’t name names” strongly contributes to burnout in every community i’ve seen it in. Rust has it in absolute spades, but i’ve seen it eat other groups alive too. Maybe we can stop doing it.

jynelson 3y ago
this is mean-spirited. i am not talking about malfeasance in the project, i am talking about people who are trying their goddamn best and whose lives and jobs are at stake. what benefit do you think would come from announcing to the world "hey this person might shortly be unable to do the work that makes them a living"?

reisse 3y ago

> new contributors make PRs. they make silly simple mistakes due to lack of experience; you point them out and they get fixed Sometimes the right answer is to immediately say "your PR is not up to project standards, it won't be reviewed, please revise it yourself if you want it accepted". It's not a job of a maintainer to educate every wannabe-contributor.

UncleEntity 3y ago
Thinking back to my earliest FLOSS contributions, I don't agree. Up to a point. Some of the PRs I submitted were pretty dumb and a complete waste of someone's time to review/reject but they showed enough patience to help me get "over the hump" and to eventually get commit access to the repo -- which didn't really help with getting features implemented because I have an apparently unlimited supply of dodgy ideas and would get "why is this needed?" a lot. I also had a habit of getting code to about 80% there before doing a PR "for discussion" knowing full well the lead maintainer would fix up the remaining 20% if it were a valuable enough addition. Probably also helped that the project has a history of working with GSoC students and the devs were a generally helpful bunch with getting new contributors up to speed on the codebase. Honestly, if they weren't so welcoming I'd be half the halfassed-coder I am today.

hannofcart 3y ago

What's not clear to me from the post is, is the author talking about just the rust-lang projects? Isn't this a characteristic of active contributors of many (or I daresay, most) large open source projects? I am not an active contributor to any big OS project but whenever I stumble across the Github issues sections for one of them, they are full of "by when can we expect to see this fixed?" kind of questions.

medo-bear 3y ago

> if you are paid to work on rust, you likely started as an unpaid contributor and got the job later. treat it like a job now. do not work overtime; do not volunteer at every turn; do not work on things far outside your job description. But if I don't work overtime how can I rewrite everything in Rust?

burjui 3y ago
Simple: attract more people to do it. If everyone ditched their $LANG and started rewriting everything in Rust, we could do it in a month.
nusl 3y ago
Ask your employer to let you do it in work hours rather than burning employees out with overtime for essential maintenance tasks

nightowl_games 3y ago

I'm a game dev at a small studio. I have a discord full of gamers who all want me to do something or at least pay attention to them. Every time I release something new, someone hates it. It was hard for a bit, but I've been doing this for years. Honestly you just gotta tune out the noise and prioritize what you want. Open source project is a bit harder because you have to collaborate more than I have to collaborate with my gamer fans, but still, stop people pleasing and prioritize yourself.

nusl 3y ago
I don't think it's in any way possible to please everyone, and even if you find the objectively-best solution, someone will hate it and be very vocal about it. Most of the folks will carry on and not say anything.
aftbit 3y ago
Relevant XKCD as always: https://xkcd.com/1172/ https://xkcd.com/1172/
BobaFloutist 3y ago
There's little I hate more than watching game devs engage with and respond to vitriolic fuming. Communities try so hard to tell people not to shit on devs, to be polite, to engage calmly and rationally, and then a certain subset of devs see a shitty, cranky post or comment getting attention and just can't help but weigh in to defend themselves. I understand the temptation, but it's deeply frustrating to see.
- nightowl_games 3y ago
  I'm pretty hard on the gamers. I'm a dad now and most of the gamers are like 13 year old boys. So I try to teach them life lessons and I give them real consequences. I'm not very sensitive to negative feedback.

throwawaylolx 3y ago

[flagged]

_aaed 3y ago
I assume you say that be cause they don't capitalise the first letter of a sentence, which is fine since it's an informal blog post. This isn't a journal publication
- throwawaylolx 3y ago
  Do you think that the difference between journal publications and blog posts are the use of capitalisation?

incomingpain 3y ago

It has been crazy how successful the rust project has been and they have been working to meet expectations. Lots of work to do. I just wish they had python syntax, I'm not smart enough for {};

burjui 3y ago
You are. Maybe you just need some additional time to get used to it. After all, even webdev monk... I mean people are used to {} in JS.

gillesjacobs 3y ago

The things that cause burnout like high expectations, pressure and endless bureaucratic project management slog sound like any software development job. Except the devs aren't getting paid which exacerbates the issue.

deleted 3y ago

[deleted]

fluoridation 3y ago

Excuse the flippant tone, but isn't this just "I treated my hobby as an unpaid second job and I burned out because I was working two jobs"? It's worse than a job, actually; some of the stuff OP says I don't say about even my actual job. I have a set of responsibilities and I just make sure to fulfill them. If my coworkers don't fulfill theirs I'm not going to shoulder them. Am I going to give them a hand? Sure. But I'm not going to do their job for them, and I'm not going to avoid delegating because I don't trust their judgement. If they fuck up, they fuck up; maybe the business suffers, but how is that my problem? OP shouldn't be thinking the way they are even if they were being paid to work on Rust.

ChrisMarshallNY 3y ago

I was the original author of an open-source, server-based, federated, infrastructure system, that has become fairly ubiquitous, for the demographic that it Serves. But it didn't start off that way. I shepherded it -almost entirely alone- for a decade, before I found a dedicated, motivated team that I trusted to take it over. They have done wonders for it. Most of its explosive expansion has taken off, under their watch. Walking away from it was the best thing that I could do for it. The last thing these folks need, is a "Benevolent Dictator," peering over their shoulders, and giving suggestions. During the gestation decade, I had to be a not-so-benevolent dictator, many times, as people tried to take it over, change it to suit narrow sub-demographics (at the expense of everyone else), and even change its entire raison d'etre. I got a ton of pretty vicious hate mail and there are people that still hate me (I cry myself to sleep over that, every night), after a decade. In one instance, I had to wait until one nasty old bastard popped his clogs, before I could spread it to the entire Pacific Northwest. During that time, I learned how not to behave. A lot of that hate, was because I'm actually pretty good at slapping back, but I really needed to learn diplomacy. Even when they are nasty, and we are right, we often need to just swallow our pride, and let the dervishes whirl. I don't miss working on it, and I'm really glad the new team are doing so good with it. I suspect there's very little of my original code in it, but the team mindset is still very much what I established. I am about to release a project that actually uses that infrastructure as a feeder to my backend.

CyberDildonics 3y ago

On top of the usual problems of a project becoming about maintenance and negativity, languages are destined to become diminishing returns and new languages always end up ruining themselves trying to add more to the foundations. You can see with D, Rust, haskell, and whatever else, the transition to working on an ecosystem with easy to use and polished tools, IDEs, debuggers, autocompletion just never happens. The languages that get heavy use like C++, java and python solved the chicken and egg problem of having an ecosystem at some point where there was an actual workflow instead of just a hacked plugin and a command line.

herdcall 3y ago

Not sure if this is Rust specific though; if anything Rust is easier to review because the compiler takes care of a large class of problems like use-after-free or race conditions. You let the compiler do the "review" on your behalf on most common issues and mainly focus on logic errors, which makes life much easier IMO for the reviewer.

mrec 3y ago

Brian Anderson (AKA brson, who as it happens used to head up the Rust project) wrote a good piece back in 2017 called "The Minimally-nice Open Source Software Maintainer" which has tips to reduce burnout/disillusionment in junior contributors. It's less geared toward preventing burnout at the top, but still well worth a read, and there's no reason much of it couldn't be applied in reverse. https://brson.github.io/2017/04/05/minimally-nice-maintainer https://brson.github.io/2017/04/05/minimally-nice-maintainer

estebank 3y ago

I'm surprised at how many people seem to focus so much on the effect of incoming PRs that require some mentoring to get them to a mergeable state or on "entitled users". I don't think those are significant contributors to burn out in the Rust project. Those you can ignore. More significant is "X is important, but I'm the only one that thinks so, so I have to carry X to completion single handedly". That causes a lot of the demoralization and heartache and guilt that contributes to burn out.

jynelson 3y ago
they both contribute a lot, although rereading my post i realized i dedicated more discussion to review burnout. i think it's a question of whether you feel more of an obligation to your users or to other people in the project, i've noticed you and i differ there. for me particularly, reviews were bad because there was a time component, if i waited too long people would get frustrated and give up.
- estebank 3y ago
  I enjoy helping people get up to speed, but after a while it becomes overwhelming for sure. It's just that if I'm not around for some reason I know that others will review things, eventually. PR reviews will continue if I get hit by a bus, pet features likely won't. I am happy that other people have taken some of my stances around DX and run with it, so at least on that one facet of the project I feel like I succeeded in becoming dispensable.

dougdonohoe 3y ago

“it won’t get done if i don’t do it” sounds like every job I've ever had, not just open source

pierotofy 3y ago

A few guidelines to avoid maintainer's burnout: * Do not allow questions on GitHub issues, it's a poor place for conversations. I find Discourse or some other forum (or mailing list) a better place to do that, which allows community participation (and you can automate moderation using something like https://github.com/pierotofy/issuewhiz https://github.com/pierotofy/issuewhiz) * People owe you nothing, just as you owe them nothing; you don't have to fix an issue or merge a pull request because somebody opened one. * Try review and merge contributions, but on your own timeframe. If people have urgency, kindly invite them to get a paid support agreement. * Don't engage in quarrels; you always have the option to ignore or ban the offenders. * Document FAQs.

cangeroo 3y ago

I'm excited for the Rust project. But to add a superficial observation: It seems that the Rust project is not very diverse. Could that contribute to culture problems? It seems to have a disproportionately high, relatively to society, percentage of white, male, strongly LGBT-oriented personalities, who usually have a female Japanese cartoon character, or maybe a furry, as their profile picture on GitHub. Which is fine, whatever, but I worry that it suffers from groupthink and excludes different minds. Maybe it's hostile to plain people that just want to focus on programming? I suspect that people like Torvalds wouldn't survive long, and that's a shame. And if you want to be really critical: Maybe the leadership is happy that specific people are leaving? Maybe burnout is a tool? Maybe it's a way of social control and censorship? I personally hope that Rust finds more mainstream support and funding, because I'd love to work full-time in Rust for many years to come.

camdenlock 3y ago
Bingo. Nobody wants to recognize this issue, for various inconvenient reasons. Rust has a major insularity problem.

deleted 3y ago

[deleted]

camdenlock 3y ago

[flagged]

soulbadguy 3y ago
> it also skews communist. Interesting claim. Care to substantiate it a bit ?
- nerdponx 3y ago
  Even more interesting is the implication that the Rust project governance and structure is somehow more socialist than other large OSS projects.

soulbadguy 3y ago

The whole industry has a burnout problem... I can't imagine the pressure with something as visible and complex as rust compiler and tool chain. The authors is pointing the best remedy, encourage and promote health work habits.

alchemio 3y ago

Are there companies contributing to the Rust compiler?

jynelson 3y ago
yes. most of the "platinum members" of the foundation have multiple full time employees working on rust: https://foundation.rust-lang.org/members/ https://foundation.rust-lang.org/members/

WuxiFingerHold 3y ago

It felt like a depression. But only of the core development. Organisation and ecosystem are evolving. The layoffs by Mozilla in 2020 might play a role here. On the other hand, when withoutboats started writing about async again recently, it felt like the sun rises again.