Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The issue with most developers is they don't care about being burnout or not. I've seen many of them don't care about, instead of spending 1 or 2 day for automation, they keep pushing the boundaries of manual, repitition to next levels, leading to burnout.

Burnout is the result of lacking of automation.

The reason is simple: Manual, repetitive job is what they're paid for, and also task automation is HARD.

One example: Ruby on Rails is the result of automation to remove all manual and repetition when working on a web application (poiting at you, Enterprise Java). And the result is, all Rails developers are happy (!= burnout)



Blaming the victim? An odd thing to do.

How often do developers raise the need for improvement, and technical debt removal? Particularly in Agile environments where there is never room for such "stories". Let alone poor management that simply ignores those requests.

Developers by definition want to automate and improve things, but are often not allowed to. Add in the long hours and pressure to constantly deliver "in fast paced environments".

As an industry there needs to be more pushback against this sweatshop like mindset.


> Particularly in Agile environments

It is "funny" how that has come to mean strict and stiff developement process.


Thats what you get when you put inexperienced management in charge of software. All processes diverge from their initial intention. These types of managers are those who treat software engineers like construction workers - they measure performance by the number of bricks laid per day. Or story points. This type of mindset simply shouldnt be part of the industry.


Really interesting view. I think treating the developers as construction workers would be great. But that would mean we'd have standard approaches, that would be regulated by a peak body. Wonky shit would get called out by inspectors. People would have an apprentice style learning environment. Sounds fantastic.


And if there is failure in the 10 years following shipping, the company fixes it with no additional charge (this is a law around here).


You are not wrong tho, if looking at it from that angle. Lets just say we get the treatment without the benefits.


Sadly, it's the reality. I called this lacking of proactiveness.

As a software developer, you must be master of your toolings. Noone but you have that ability to improve you ! WHo else to blame then ?


Ya, like Elon Musk -- he really is a self-made man!


This is nonsense on stilts. I recently burned out hard, (I have been off for about 6 weeks) largely because I was made to spend hundreds of hours automating manual tasks performed by higher ups on an infrequent basis on top of my normal workload, despite the fact that it will literally take years of those automations being in production before there is a net gain in time or productivity for the company. Automation is sometimes worth it but often it is just a pointless time sink that people like to pretend boosts their productivity and which they can wave around to show how smart they are.


This is too simple. One can burn out either way: building automation most, if not all, days or keeping it manual. Burnout is too multi-facetted.


I've not seen any company which encourages automation lead to burnout.


I think the issue here is what you’re defining as automation. I worked at a managed services provider automating any task that could be automated for over a decade, there will always be more work than can be automated. It just changes too fast for that not to be true, especially when dealing with thousands of different line of business applications and edge cases which are constantly updating.


No, 100% no. Burnout is the internalization of the belief the work is endless, pointless, and certainly not worth your effort. Burnout is when one's investment is realized to be a failed commitment of one's time, one's energy, one's finite life.


I am pretty sure I burned out in 2017. It has been a slow crawl back to normalcy.

The real trouble is that there is no end to the demands that a business will make on a person. A business can't halt and wait for your burnout to subside. A business needs to push the next widget out - and if you can't help with that then someone else will.

This is directly at odds with recovery. There's never enough time to feel proud and connected to your work. Just the next task.


I've been coding professionally since '82 and am in the tail end of my 5th career burnout. The underlying issue is our industry is an ocean of poor communicators, who routinely ignore signals until a tsunami hits.


It is incorrect to suggest that lack of automation is the issue at hand. From where I stand, it's the pressure for deliverables and frequent oncall responsibilities that stress me out the most.


Show me one counterexample first.

I've joined a bunch of companies, and there' two kinds of companies to me: Lacking of automation and pushing with automation.

One example: CI/CD process where developer only cares about the code, not CI/CD configuration.


You're so disconnected from reality that I think you should simply stop. If not for your own credibility then because of empathy to people suffering or who have suffered from a burnout. You're just adding an insult to an injury.


It's correct. It's the reason i stop working for enterprise if possible. Because i know the truth. Noone cares about automation, and there's no reason you're the guy who do automation for free (with the risk of delaying your JIRA stories).

There's a reason to stay out of a mess.

There's no empathy for intentionally not releasing the burnout for teammates besides the selfish reason to keep your seat forever. It's the selfishness at best. And no, for my cultural reason, i have no reason to stay there to feed lazy assholes.


Whenever I've automated something, the time I've spent doing that thing manually becomes free to work on the 1000 other tasks in the backlog. Nobody is going to give you a week off even if you automate the work of 10 people. And you're not limited to repetitive tasks for burnout, intellectually stimulating work can drain you as well.


The place I currently work at and feel almost at the edge with regards to burnout has been automating everything for a year without any business value being delivered, because we don't have a product but we're building the "best" infrastructure. This is quite frankly a naive view that manual == burnout and automated != burnout.


Our built-in pattern-matching capability (very valuable in general) is not great with regards to people problems.

Programmers are humans. You can think of a human as a highly complex system. Our problems are not always "simple". Every time you see a short-phrase used to describe a solution for human problems, be very skeptical. Your phrase was "Burnout is the result of lacking of automation", but there are many others like "Just ignore what others say" or "Stop feeling sad". A highly complex system often requires nuanced and complex solutions. Short phrases simply don't have enough bytes.

And that is for a single human. If we are talking about a big collective ("all programmers" instead of a single programmer) the short-phrase solution is even more inappropriate.


The default sentiment is: This is not a mathematical theorem. All upon your interpretation. Focus on the "mostly correctness" instead. You don't want to disprove anything here because the statement is of course by anyway not a mathematical theorem.


I like how SRE has a word for it. https://sre.google/sre-book/eliminating-toil/


For me, it's the automation that's causing the burnout. It's overly complex, always buggy or deficient in some way and makes the overall system way more complex that it would be otherwise.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: