Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Study finds 83% of software developers feel burnout

usehaystack.io

Post reply on HN
Print view View original

191–200 of 308 posts

Re: Study finds 83% of software developers feel burnout

#191

Post by Volrath89 »

protonimitate wrote: post #47
briefcomment wrote: post #5

Earlier quoted context omitted.

Is maintenance the cause of burnout then?

For me burnout comes from the endless treadmill of external pressures (arbitrary deadlines, changing requirements) and the endless treadmill of development work. There's not really ever a chance to step back and take a breath - just constantly moving from one high priority task to the next. It's also a bit thankless, being good as this job, in a lot of cases, means you are moving really fast from one task to the next…

The best/fastest performers usually get rewarded with... more work.

Something I've seen more and more often is that a lot of developers take a lot of time for every ticket. Much more time than I'd take, but I suppose it's because they are not incentivized to work fast, they'll still get paid the same no matter how many tickets they close. But I don't think paying more if you close more tickets is the solution, I don't have any solution, really.

Re: Study finds 83% of software developers feel burnout

#192

Post by hallway_monitor »

Spartan-S63 wrote: post #98
kube-system wrote: post #90

Earlier quoted context omitted.

It's important for managers to plan time for design, testing, feedback, meetings, administrative tasks, and context switching. In places I've worked that has planned this well, we usually allocated somewhere around 4 hours of development work per day to someone. I think most burnout is systematic, and caused by incomplete task breakdowns.

I agree. I previously worked in an XP shop that spent seven hours a day doing pair programming. It was exhausting, and challenging to do non-dev work in the hour a day left. Especially as a team lead, it took a lot of extra time or carving out time away from the pair to get enough done. I also don’t know if full eight hour days are good, in general. I feel like 5x6 or 4x8 would be a better schedule, though, with a fo…

I agree that their programming is extremely draining when done non-stop. I can't do it 8 hours a day and I don't expect my team to do that either but I would like them to average 4 hours a day. In my experience if the rule is pair programming then the exception is working solo on simple or repetitive tasks that you've done before which works well.

Re: Study finds 83% of software developers feel burnout

#193

Post by danenania »

dragontamer wrote: post #146
p_j_w wrote: post #133

Earlier quoted context omitted.

Your criticism of the sample size is unfounded. You absolutely can have meaningful results with only 258 people provided you have good sampling. If you want to criticize their sampling, then by all means do it, but that's not what you've done here.

A lot of the COVID19 stuff only has a population size (NOT EVEN sample size) of like, 15. Ex: J&J's blood clot issue. People make conclusions off of tinier sample sizes. There are plenty of scientific studies with just 50 or 100 people, but you need to keep the small numbers in mind. As long as sampling was done correctly, then small sample size won't matter much !!

People make conclusions based on tiny sample sizes when the results fit their biases.

Most studies are worthless due to small sample sizes and confounding variables, and most “conclusions” are based on cherry-picked outliers. The fact that it’s common to do this doesn’t make it responsible or correct.

Re: Study finds 83% of software developers feel burnout

#194

Post by milesvp »

SketchySeaBeast wrote: post #167
karaterobot wrote: post #57

Earlier quoted context omitted.

Somebody said that the cause of burnout is working hard and then not seeing results. Some common ways that happens in software development are working for months on a feature that gets cut (or undercut) at the last minute, or trying to demonstrate your ability for some role and not being recognized for it, or even just putting your heart and soul into a company that is circling the drain. If those experiences happen…

That actually aligns nicely with parents comment about maintenance. I work on a maintenance team and I'm constantly toeing the burn-out line. At best the system works as well as it did before, but that's really it. Sure we tweak it here and there, but otherwise it's hard work with no real visible changes.

I personally really like maintenance programming, but I wonder if I've been lucky. All the systems I've ever inherited, I've been able to make impactful changes to them such that they stopped being that one system that causes everyone production headaches. Even the systems that I couldn't make much changes with directly, I was able to isolate, and route other systems around them, such that new data stopped depending on the system. It took a lot of effort, and politicking, but I seem to find the exploration and the juggling to be far more satisfying than greenfield building.

Re: Study finds 83% of software developers feel burnout

#195

Post by hallway_monitor »

Spartan-S63 wrote: post #156
kube-system wrote: post #110

Earlier quoted context omitted.

I feel like measuring a workday in hours is more useful for measuring the workload of a non-stop assembly line type work than it is for a knowledge-based job. 8 hours of work where you can grab a coffee and read HN whenever you want could be easier on the mind than 6 hours of work where your attention is in constant demand. I do wish I could do the same number of hours over 4 days instead of 5, though.

I agree. Ideally, we get to an end-state where it doesn't matter what hours (or how many) you work as long as your team's outcomes are being met (and the outcomes are reasonable). There are a lot of caveats and complexities in that statement, but it's a state we can keep pushing towards as an industry.

I really like this idea but I'm not sure how to implement it. If Bob works twice as fast as Jim, does Bob get to go home at noon or does Jim have to work late?

Re: Study finds 83% of software developers feel burnout

#196

Post by Volrath89 »

jnwatson wrote: post #150
dfxm12 wrote: post #32

Earlier quoted context omitted.

In my experience (and I think also in the spirit of the analogy), it's not just maintenance. It's expecting to maintain everything you've ever done while also simultaneously being expected to keep producing new work at the same rate (and then being expected to maintain that). It's that your work load seems to only increase. As the study found with regards to the causes of burnout, increased workload cited as the main…

One of the undersold advantages about getting a new job is that all the implicit commitments you built up go away. Try it.

Yes but then in the new job you need to maintain other people's stuff, which is even harder that maintaining your own stuff. And over time you get to own that, including all the previous tech debt that you didn't create

Re: Study finds 83% of software developers feel burnout

#197

Post by SketchySeaBeast »

milesvp wrote: post #194
SketchySeaBeast wrote: post #167

Earlier quoted context omitted.

That actually aligns nicely with parents comment about maintenance. I work on a maintenance team and I'm constantly toeing the burn-out line. At best the system works as well as it did before, but that's really it. Sure we tweak it here and there, but otherwise it's hard work with no real visible changes.

I personally really like maintenance programming, but I wonder if I've been lucky. All the systems I've ever inherited, I've been able to make impactful changes to them such that they stopped being that one system that causes everyone production headaches. Even the systems that I couldn't make much changes with directly, I was able to isolate, and route other systems around them, such that new data stopped depending…

You may have been incredibly lucky, or have a secret sauce I don't understand. I've worked a pair of maintenace positions. The previous one was incredibly creaky and had no other systems, so changes were scary and there was no recourse to move to something else. The only I'm working now I'm maintaining client code so I don't have any agency there either.

Maybe it's agency? Ultimately I don't feel like my contribution wows anyone.

Re: Study finds 83% of software developers feel burnout

#198

Post by throwawayswede »

dheera wrote: post #153
throwawayswede wrote: post #56

This is such a great example of bullshit studies. Yeah I'm gonna go on a limb and say this is a marketing campaign. It's an insult to science to call this a "study". From the pdf: > The fieldwork of this study was carried out at remarkable speed, from the 23rd to 24th of June 2021 Data was collected in 1 day. Is this a joke? No it's not! > The population sampled included Software Engineers aged 18+ living in the Unit…

The thing is, everything in this world is now gauged by engagement , not quality. The fact that this is getting more reactions on HN gives it even more exposure, and actively reinforces this behavior even more. If you have a really good, thorough study that is so thorough that people have nothing to comment on it, it will not rise to the top of pretty much any platform, because comments are valued higher than upvotes…

> everything in this world is now gauged by engagement

nope not true, only algorithm driven website. just because this post or comment made it to the top of HN doesn't mean people think it's valuable now, it just means like you said: it has buzz around it, and it should, because it's bullshit and should be exposed for the bullshit it is. Is that enough to get people to be more skeptical about what they read? I don't know, probably not though.

Re: Study finds 83% of software developers feel burnout

#199

Post by hallway_monitor »

raxxorrax wrote: post #94
karaterobot wrote: post #57

Earlier quoted context omitted.

Somebody said that the cause of burnout is working hard and then not seeing results. Some common ways that happens in software development are working for months on a feature that gets cut (or undercut) at the last minute, or trying to demonstrate your ability for some role and not being recognized for it, or even just putting your heart and soul into a company that is circling the drain. If those experiences happen…

Just going through this with some hosted cloud software because some environments were "deprecated". The best possible result from finishing migration will be that it worked as well as before. This is so frustrating since I don't even know why Microsoft or Amazon deprecated these in the first place. It is work purely generated on their whims. Apparently some AWS tools also got changes since some scripts seem to be fa…

"The best possible result from finishing migration will be that it worked as well as before." Talk about working hard and not seeing results. Having worked in several large enterprises, keeping up with new standards causes this situation constantly. Authentication, security, configuration, static analysis, deployment systems. It feels like eventually you get to a point where you are always working but never add a new feature. This is the most demoralizing thing possible in software IMHO.

Re: Study finds 83% of software developers feel burnout

#200

Post by danenania »

antris wrote: post #157
enraged_camel wrote: post #142

Earlier quoted context omitted.

Sorry, but what part of "they only surveyed software developers in the United Kingdom" gives you the impression that their sampling might actually be good ? Worth noting that the study itself doesn't seem to mention their sampling methodology.

Studies are never meant to be an ultimate answer to everything. And just because they're not the ultimate answer, doesn't mean that they are therefore worthless, bad or "bullshit".

It actually does mean that in most cases. Having false confidence in a hypothesis based on non-rigorous studies is much worse (and in some cases, a lot more dangerous) than withholding judgment until the data (all the data, not some cherry-picked slice of it) really is conclusive.
Post reply on HN