I think one big factor in this is that as a developer, you don't (normally) have slow periods. A lot of other occupations will have their stressful high-tempo periods, but then they have the lower-tempo periods in between. But in software engineering there's no end to the constant demand of more features and more bug fixes. There's no slow time, no low-tempo periods.
Humans are just not made to always work at flank speed, but I feel like that's the expectation within the software industry, and I can easily see that leading to burnout.
Perversely, because the industry creates this pressure, low-tempo periods that are employer-specific cause anxiety and paranoia. This is even more true right now as large companies continue to announce layoffs.
Is boreout actually a problem unless you're expected to be imprisoned in an office every day and maybe, even worse, expected to look like you're "working" even if there's not much to do? In a remote or hybrid working culture, periods of lightweight work should just be regarded as more leisure time for you. Embrace the opportunity for some self-care!
I agree, though I can see this being hard for many. Even when technically resting, knowing you are technically in working hours is often enough to prevent real leisure.
> Every company I've worked at has had a busy season and a not-so-busy season.
And yet, more than enough companies plan their staffing for "can barely hold it together in not-so-busy season and expect overtime in busy season". That looks good for the beancounters, but is hell for the staff.
> Plus I still take vacations.
The US doesn't have mandatory PTO requirement. Europe does, but it still is nowhere near a level that would actually allow people to have enough free time to enjoy life.
I think this depends a lot on the nature of one’s work. Examples of busy periods:
- externally driven work (eg some obligation to a client; some change to an api that is relied on)
- intern season / spending time bringing someone new up to speed / when someone leaves a team
Quiet periods:
- the opposite of the above
- times when the business focus is on reliability (eg I think Facebook have a big hiatus on changes to the site during the run up to Christmas as it’s the most profitable time of the year for them).
> - times when the business focus is on reliability (eg I think Facebook have a big hiatus on changes to the site during the run up to Christmas as it’s the most profitable time of the year for them).
I work at Amazon and have been subjected to two versions of those periods (because I switched teams): one was every year around Black Friday and Christmas, and the other one was when a new big show releases on PrimeVideo (like LOTR).
Those periods are the total opposite of quiet.
You still have to work on normal deliverables, except you can't push them on your pipelines (not even beta) and on top of that you have to either support last minute critical demands for ad-hoc work, and then you have to work around the extremely strict deployment windows to actually release that ad-hoc crap to prod.
I have started deployments at 9AM and finished at 11PM routinely during those times because there's a single day where the pipelines are open and you have to complete your deployment before the next day.
I hated this at Amazon. The rest of the year we’d all be so pleased by our frequent deployments. Then for half of Q4 we’d be in code freeze but would be pressured to pile up feature work to go out in Q1. At least weblabs made feature flags easy.
Oh really, I actually find the slow periods of development work the hardest. Like when you start to suffer boreout when there's not much to do. It's kind of a burnout because the energy isn't there to go seek out busy work.
We could blame Agile for guaranteeing you never have a second to yourself to do anything you think is needful or interesting or fun, but just forever trudge ahead fighting fires and fiddling with format and reworking code for broken libraries you should really be fixing...
We could go on and on. But I'm too tired and ... burnt out to continue.
If you’re building large new features on a product then I really recommend Shape Up’s model. Long period of driving the build followed by an explicit cool off period. They recommend 6 weeks of build followed by 2 weeks to cool off, but we’re such a small team that we halved this and found it worked way better - it’s four weeks which is an easier transition from two week sprints imo.
It gives time to just polish off those little rough edges that build up over time and gives developers a lull in which to work on low stress 9-4.30 kind of work.
My team has an operational excellence day per sprint where we have to work on tech debt.
Except that day is not counted in sprint planning so we don't have points allocated to it, we have meetings during that day and are also expected to perform our normal duty such as helping customers onboard, and 95% of our tech debt tasks would take more than a day to fix anyway.
The result is that we have 10% of our time supposedly assigned to tech debt, but in 11 months in that team I have only worked on tech debt once during those days.
I took a job where I was told engineers could work periodically on improving open source projects relevant to our work. In the two years I was there, I was given exactly zero time to work on such things.
I think these kinds of arrangements are dangled as a carrot in front of engineers, while the person doing the dangling knows full well that they are selling a lie. Now, such an offer is a red flag in my eyes, unless I hear a credible story firsthand from every engineer that interviews me.
Next time I am offered such a carrot, I basically will need to see it put into writing before I believe a word of it. I suspect you have learned a similar lesson from your own experience.
And it's not like a day every now and then is enough to tackle the hairy issues that have been festering for years and are a pain point in your everyday work. Past bad architectural decisions embedded in the codebase for years won't be solved by taking a day to clean up every week, it requires focused work to pull strings around, experiment and start a solution that will be rolled out over months.
I hate the view that allocating a fixed percentage of time every X week(s) instead of allocating proper time as a project to fix issues affecting the productivity of the whole team/engineering org is doing something. It's just another source of frustration.
I think there might be something here. I've written about it and I wonder whether the current interpretation of Agile is just another manifestation of our can-do, 'get-ahead', 'achievement society'- - which is perhaps the ultimate cause of burnout. As someone who has tried to promote agile mindsets within organisations, it's deeply concerning.
You need to introduce firebreak sprints. Take a week off every fourth sprint (or whatever) and give devs the freedom to build whatever they think will need doing to make the system better overall. You’ll get a bunch of preventative maintenance that you knew needed doing but never found time to do, but you’ll also get the occasional mad idea that turns out to have big benefits.
Higher interests or not the pressure to deliver value and growth every quarter has always been present. In tech especially as we're seen as a hypergrowth model and not growing quickly every quarter is a sign of failure to the expectations of the market™.
I've been working in this industry for 18 years, in different countries with different central banks rates and macroeconomics conditions, it's always been the exact same.
I've been in orgs in which developers are considered grunts and no one listens to their feedback. It's not that they aren't important, it's that the PMs/managers/whatever know better.
I see firebreak sprints as a symptom of an org not valuing engineer feedback. "Let the grunts blow off some steam or they'll get disgruntled and leave."
because sprints don’t allow the idle time that’s often needed to come up with such ideas. I could probably work for a year on “oh I’ve been meaning to look into that” tasks that have no clear outcome
A friend of mine is a retired doctor, and told me that he studied music theory during down-time at the ER. Also, shopkeepers and anybody else who depends on walk-in customers or has intermittent demand.
> Also, shopkeepers and anybody else who depends on walk-in customers or has intermittent demand.
Until you have a boss demanding to do cleanup or whatever during low-demand times because they're too beancouter-ish to hire staff dedicated to keep up appearance.
Jobs that require creativity should allow for free time, to let inspiration come to you rather than try to summon it. I think programming is one of those jobs. And if you are always coding, always against a schedule, it's easy to burn out because you went against the essence of your work.
Most programming jobs are as creative as brick laying. So yeah there is some wiggle room to put your own style but you are just implementing CRUD(in it's different complexities and variations) and integrating APIs.
in brick laying your brain can wander and think about other things, listen to the music and imagine you are living in perfect world without any problems at home. Your hands will be tired, but your brain can take a rest
in most programming jobs, even though you are doing CRUD, your brain should direct you into specific direction (open file.js, put after if (x > 0) block and so on), which tires your brain.
consulting firms have "bench" periods where consultants are expected to learn new things and train themselves up. some take that time to work on side projects; others learn entirely new things
I, too, think this has a lot to do with it. Developer sprints help, but I don't think they come often enough. Also, I think there should be a day between sprints to decompress and do some non-creative work.
I work at a company where employees get to choose three-weeks sabbatical (or paid equivalent) after reaching 7 years of tenure. Of those I know who took the sabbatical, a good proportion of maybe 20% to 30% come back off their break and promptly hand in their resignation.
Talking to my former manager who did this, he said that he never realized just how burnt out he was until he had some time on his hands at home. I think some folks just exist in a fog of burn-out and don't really notice it until they get a chance to stand back and evaluate their situation.
Another reason why people quit right after taking a sabbatical is because people willing to quit several months before the 7 years mark will postpone their decision.
This whole situation you're in is the very reason why everyone burns out. Three weeks is the kind of vacations I take yearly, whether there's a planned release at that date, or anything else. And so do all my coworkers.
America's dogshit work ethic and disrespect for workers is killing you.
Which country? US for sure. It wasn’t until my 5 year mark with my current company that I hit 4 weeks of combined PTO/sick leave. And due to a company policy, they didn’t match my prior vacation amount when I joined.
And per HR, our vacation policy is better than industry average.
I've been programming for 53 years and have never been burnt out from the act of actually building software. In fact it's been the opposite for me. Every time I've ever had a significant challenge, alone or in a small competent team, to get something built quickly and right, I've savored that challenge. The times I've sat up all night long coding are some of my fondest memories. I remember with startling accuracy every time we struggled getting something to work, got it figured out, and danced. I remember every white board, direct message, even every slice of pizza in the trenches.
I've even commented here on HN many times that I've never been burnt out coding and never will be. I'd be the last one out of here to turn off the lights when everyone else was burnt out.
But now I am most certainly burnt out, not from building software, but from being incarcerated in dysfunctional I.T. hell.
For OP and the posers who think they understand the mindset of serious software developers, here's what really burns us out:
- the same stupid meeting every morning where nothing is raised or closed and no non-programmer has a clue
- taking direction from the same clueless bosses who have never accomplished anything but treat us like their children
- the new technology or philosophy du jour that does everything but address the root of any problem
- management that absolutely cannot grok fundamentals like cause/effect, critical path, detail/issue, urgent/important, diminishing returns, etc.
- continuous leadership bombardment of idiocy and stuff we know can't work
- management's complete failure to solicit or accept feedback from those of us who actually know
- nothing written down and no one remembering anything
- confusion by almost everyone about the difference between activity and achievement
- no written business requirements, technical specs, or test plans, but instead, some new untested methodology
- leaders who don't understand the difference between steak and sizzle
- continuous business failures because of poor leadership, not technology (and they keep doing it!)
- I could go on and on, but I wouldn't get anything done today and be just like my boss.
I'd love to see an OP that addresses any of all of these things I've been suffering from for years, instead of a headline with a precise metric on a misunderstood premise.
I'll suffer all day today and then to get rid of the corporate stink, build something cool for myself later tonight. That's not personal burn out, it's industry burn down.
I largely agree but I would like to add that much software we developers work on today works against developer satisfaction.
Bizarre architecture choices based on trends, tedious build steps, complex development setups with hours spent on configuration, etc.
Software development has become a time sink into things that has nothing to do with the actual task at hand.
This annoys me somewhat more than a clueless manager, who can be forgiven for not understanding software development, because these software architectural problems is something we developers created, willingly.
All these programmers agreeing to IMO the worst culprit to programmer burnout. I still struggle understanding who these people are and why they support this cult. Every excellent programmer I've ever worked with just laughs at this.
My homegrown conspiracy theory is that Agile was invented by project managers that wanted to constantly change project goals.
Broken pleb developer - Why are why yet again changing project goals? We already changed them last week after a long meeting.
Carefree Manager - It is Agile to adapt!
Core of Agile makes sort of sense, that you continuously involve the client and iterate thru the project to create a product that meet client demands. However that also assumes that you are working with clients that are competent, in the real world most clients are clueless. Now you have a clueless client and a clueless manager running the project to the torment of the developers.
In my own experience after working at different management positions (team lead, scrum master, senior developer, project manager, technical project lead, architect etc) is that the vast majority of developers, me included, are uninterested in project management, they just want to code. Thus when I run projects I run it as a dictatorship instead of a democracy (scrum) and give the developers the tasks that fit them based on their skill level. This requires some skill in understanding your developers needs, 1) that they feel that they make a difference, 2) that they have some freedom on how to solve each task, but within the constraints of the architecture and project. It usually works best for everyone involved.
If there are some developers that do enjoy project management (often they are knee deep into scrum theory and such) I handle them separately from the rest of the team and do some project management with them only. No reason to involve the entire team just because a single developer enjoy retrospect meetings. If there any valuable conclusions (rarely) you can introduce it to the rest of the team afterwards anyway.
Scrum and such theories assumes that every developer are equally engaged in the project, in reality that never happens because we have different personalities, different skill level and different priorities, thus making a developer to "freely" pick a task from a board of tasks is just nonsense. We all know in advance who will do what, it is just a charade. Same goes for planning tasks, if you have no idea how to implement a task you can't really help with planning it either.
The common timeboxed two week scrum iteration is probably one of the most common reasons why developers feel stress.
Morning meetings must have an agenda, a chairman and be timeboxed, otherwise it is a waste of time. Personally I find that asking what everyone is doing is a bit unnecessary, most people don't care and wont listen anyways. It tends to be better to use that meeting to inform what is happening next in the project.
Common among developers is that they are a bit socially inept, however many of the scrum ideas force them to into socially awkward situations, I view that as bad company policy.
Clients needs to be handled individually on case by case basis, you can't run an entire project management style based on the assumption that clients know what they are doing. Most clients will accept your decisions if you present them confidently, they view it as they pay a professional so solve their problem, similar how you would hire a carpenter.
I really wanna hear more from people like you about how to survive and thrive for so long in tech.
What kind of work do you do?
What are your tips for a good and long tech career?
I mostly write applications for large enterprises and SMBs. Stuff most people think is boring but is really cool and runs the world: order processing, supply chain, operations, ecommerce, etc. I try to stick to relatively simple and effective technologies, but that's becoming harder and increasingly complex.
What had worked best for me (in descending importance):
1. LOVE building. If you're not getting satisfaction at work, build something for yourself at night. It's my rush.
2. Become excellent at what you do. Think Steve Martin, "Be so good they can't ignore you."
3. Volume. Build. Build. Build. I still think this is the best way to learn and get good.
4. Keep learning. The best way: building something, then learning what you need to build it, not the other way around (class, book -> then build).
5. Understand the people side and the tech side are very different. Embrace both, but differently.
6. Build something that builds something. The nested learning is magnitudes more effective.
7. At some point do a startup. Even if it fails, you will be much better.
8. If it stops being fun, do something else. (I've always stayed a programmer, but if I couldn't keep it fun, I would have become a bartender, or a writer, or something).
[5] is super key. That's what gets you to Staff+ and what gets you paid a lot of money (in real dollars, and especially in equity).
[7] assists you in getting to [5], but if you want something quicker, try consulting or pre-sales. You'll definitely need to build, but 60-80% of the work is driving people that you don't manage towards an outcome or selling people on an outcome (that, ideally, your stuff helps them achieve).
I'm currently on sick leave with burnout, for 9 months already... For public health care the waiting lists are at least half a year. Although my employer 'tried' to employ a private psychologist, this has been useless thus far. This is because my situation is more complex than a regular burnout, a standard psychologist for burnout refuses to treat me. My employer says they cannot do anything besides that. So I'm currently at a stand still.
This is my second burnout in 4 years with this employer and I think employers should do more about these situations and resolutions.
Usually, at the point of real "burnout" there is no fix except leaving for a different setting for awhile. While I often infer Plumbing is a cleaner trade than the tech sector, there are real consequences associated with some toxic corporate cultures. ;) I usually recommend self-evaluation though Ikigai as part of long-term career planning.
'Ikigai starts with the awareness of four key pillars:
> Usually, at the point of real "burnout" there is no fix except leaving for a different setting for awhile.
Still being with my employer causes some real pressure. They don't want to help to fix my issues, while still expecting me to come back to work. I need to get out of this situation.
> While I often infer Plumbing is a cleaner trade than the tech sector [...]
The thing is though, I love software development. I have wanted to be a software developer when I was 4. And I'm almost 34 now. But I really hate the politics and drama. I just want to create, be creative and be a team leader. I know I can do that and I'm good at it. But I just have to find the right match.
I didn't know about Ikigai, but I've printed out a copy for on my whiteboard and I love reflection, so thank you.
> I just want to create, be creative and be a team leader
Being a team leader isn't great if you are vulnerable to stress. I've never led a team but from how I see it their job is generally higher stress. You need to be technically hands on which isn't easy, and on top of that deal with any unexpected issues that arise, and yeah ... manage the people on your team. I honestly don't really know why everyone wants the job. Yeah it looks nice on a resume I guess..anyway I digress.
Its the executive levels that perhaps get the good life but than you really leave development.
> Being a team leader isn't great if you are vulnerable to stress.
I think there are differences in being vulnerable to stress. I really perform under pressure. Especially with difficult technical challenges. I'm also the kind of person that can be a locomotive in a team, pulling them forward. I did that in the past and would love to do that again. But I crack when I'm threatened on a personal level. For instance my job security. Or when team members don't want to work in a team anymore, but management still wants them there. Although that's hard on the whole team.
Thanks for the insight though, greatly appreciated. And to be honest, I don't really mind my resume. It's nothing special now either.
If you've entered the "burned out" phase, it'll be very often high anxiety, low energy, sleep problems (either very short nights, or very long nights, coupled with large naps and somnolence through the day), feeling angry or depressed, feelings of dread. You stop enjoying what you used to enjoy, and it's basically easily confused for "just depression" (which should also be treated) Your body just lets go of all non brain functions and focuses on your mind. And your mind is feeling like shit, empty and useless.
If you're at the "right at the edge of it" phase, it's rather obsessional focus, trying to please everything and everyone, high feelings of responsibility and duty (even if nothing will happen if you're gone), stress (both the "good kind", the one that everyone believes is perfectly normal to have when you have something important to do, except all you're doing is making a shitty CRUD app right now, and the bad kind, where going to the office fills you with dread), not enjoying what you used to enjoy but saying "it's okay, it's just temporary" when you've not touched that backlog of games in 6 months.
I didn't enjoy anything anymore. I didn't enjoy movies, activities, programming or hobbies. I also slept a lot, like 10+ hours a day. I would just fall asleep while sitting on the couch watching something with the wife. And I just felt like I was empty.
> Are you still feeling this way or are you feeling better now?
To be honest, I am feeling even worse than the first day I called in sick. I haven't had any noteworthy mental health help in the 9 months. Like I said in another comment, my employer denies that he is (co-)responsible for my situation. So they just don't really help me out. And without my own funds this seems neigh impossible because of waiting lists.
My first burnout at this job was caused by exceeding my stress levels for a very long period of time, more than a year. I asked my supervisor to assist me with this. And he kept promising change, but it didn't materialize. It also didn't help that I was the only team member that was working on a separate location. When I return to work, I started looking for another job, but a company restructuring happened, which brought me new challenges. This change made me abandon job hunting.
Fast forward to about a year ago and I had the opposite problem now. Work had just dried up and I wasn't doing anything for longer periods of time. Causing somewhat of a bore-out. Also I was required to justify my time, which was becoming impossible. Causing anxiousness. Again I pointed this out to my supervisor and was job hunting for months. But both, again, didn't materialize in time.
I have an added problem that I can only travel by train or bike, while most IT employers nearby are only accessible by car. And I really would like to work on site with a team. At least for half the time.
Now I would like to start with another employer, but I still feel extremely empty and anxious. Sorry, English isn't my first language and this has a lot of emotions coming through with it. That's why maybe some sentences seem a bit off.
My employer didn't have enough (challenging) work for me anymore. According to my employer I had to find my work in the organization myself. Which IMHO is a load of BS. This had be going on for close to a year, and before I realized it, it was too late. Although I have mentioned this every sprint retrospective and with every performance review, nothing was done about it.
Whenever you see a headline like this, one of the first questions you should ask is: "compared to what?" For this number to be relevant at all, it needs context - among the general population, how what percentage suffer from burnout?
In this case, answering that you feel any amount of burnout (including "To a small extent") to the prompt "I feel burnt out from work" means you suffer from burnout. In fact, the distribution from most burnt out to zero was: 21%, 34%, 28%, 17% - a relatively even distribution. An alternate headline (that's less exciting) is: 45% of software developers barely suffer burnout. That's almost a coinflip.
I'd be shocked if this doesn't just mirror the general population.
83% is so high that you don't really need to compare it to anything. It basically means almost all devs are burned out.
In fact its so high I'm not sure this study makes sense. Its higher than people with real stress like physicians, policemen and firefighters.
Yes I've seen burn out here and there and even experienced it myself in one toxic workplace, but 83%? I don't know what went wrong with the study but this just contradicts my life experience by a huge margin.
>Its higher than people with real stress like physicians, policemen and firefighters.
The thing is with most non-office professions like that, especially those involving physical instead of cognitive work, it's much easier to disconnect and relax mentally after work than with software engineering where even once you're done for the day you can end up mentally ruminating about critical bugs or issues throughout the evening, especially if you have a lot of responsibility and you know people/business is counting on you.
> it's much easier to disconnect and relax mentally after work than with software engineering
Each profession brings its own challenges but I'm skeptical tech workers experience more stress than lawyers or accountants.
And when we talk about physicians, nurses or policemen there's no way in mind we experience more stress than those guys. You're thinking about a critical bug which I respect. Those guys sometimes ruminate about matters of life and death. Their jobs are extremely difficult and burn out causing. A "critical bug" for them could be that they misdiagnosed someone and severely compromised their health...I don't really envy their jobs.
>> Its higher than people with real stress like physicians, policemen and firefighters.
> The thing is with most non-office professions like that, especially those involving physical instead of cognitive work, it's much easier to disconnect and
relax mentally after work
I wouldn't say being a physician, police or firefighter is non-cognitive work. What you say might apply to some other professions, though. But the mentioned professions definitely see stuff that will haunt you and stay with you, and won't let you disconnect.
I'm not so sure you can easily de-stress as a policeman. When you're involved in a high-stress or even high-risk situations on a daily basis (say, people shouting at you or cursing at you in a threatening manner), this is absolutely something that stays within your body for the remainder of the day or more. There's a reason so many cops drink in the evenings to be able to "unwind".
Would police officers ruminate about mistakes they may have made during a shift? My suspicion is 'generally not', and if that's true, maybe they should?
But police - and most physicians, etc - don't have a WFH option. More and more tech folks working from home don't have an automatic 'mode switch' when you leave and come back. I know it's been talked about to death, but some separation between 'non-work life' and 'work life' is easier when there's a physical separation.
> Would police officers ruminate about mistakes they may have made during a shift?
Hmm why wouldn't they, they seem to be made of the same DNA as you and me. They want to make good impression on their boss, colleagues etc (the politics and who gets ahead bullshit seems to be very high in their field) and are also exposed to very high stress situations - solving murder cases or patrolling the streets doesn't sound too chill to me.
Most cop shows depict them as a bunch of alcoholics with failed marriages ... I don't know how accurate that is but it wouldn't surprise me.
There may be a bigger pressure to 'switch off'? dunno - I'm not a police officer. But there is a different work environment, and being 'at home'... you can replay issues in your head, but to what end? You can't go back and make any changes, compared to dev/code work, where you can be thinking about something and ... just go make a change (iow, 'keep working').
My neighbor was a firefighter for 20 years, and from his telling, that's what triggered his alcoholism. Drink a few to relax, later drinking to forget what you've had to witness - death/destruction/tragedy on a regular basis. I would not be at all surprised if alcoholism (or similar substance abuse) was not higher in professions like police than the regular population.
>For this number to be relevant at all, it needs context - among the general population, how what percentage suffer from burnout?
It doesn't have to have a perfectly described population context. If you had a metric that established 60% of all developers had issue X and 60% of the general population also had issue X, it doesn't minimize the significance of issue X. It's still an issue, in this case preventable, and it still effects a relatively large number of people, so let's focus on that.
Context is certainly useful though because if the issue is more widespread (or found isolated with high correlation), it helps us better understand the cause of the issue vs looking at some subset of the population and trying to guess the cause to fix it. If it's the population at large, maybe Agile or knowledge work isn't the cause of burnout, maybe it's something else. But we should still identify the issue and try to fix it.
Yeah, exactly my thought. How could you think that if the sentiment in the general population is that anywhere between 50-85% are feeling burnt out that it's ok because comparatively a group is not suffering more than the other. It's just much worse that the whole population is feeling this bad about work. It shouldn't be this way!
Not so sure about that. Because people are generally biased to not recognize burnout symptoms in themselves (at least not until they've already been burned out once), these numbers seem shockingly high.
A significant portion of the burnout problem is down to insufficient recovery.
Sleep is important. Nutrition is important. Physical activity is important. Having out-of-office social interactions is important. Non-computer hobbies are important.
This is in part personality and habits. You can have the greatest job in the world, if at the end of the day you go home and keep working on something else until you drop from exhaustion, that's not great. That may be fun, but it's not permitting the necessary recovery. I unfortunately think that is somewhat common in the tech world.
Of course working conditions affect the amount of recovery that is possible. If you're working 10 hour shifts and have a 2 hour commute, then crash in the couch too tired to do anything, eat leftover pizza, and then get 5 hours of sleep before it's back in the wheel again, then it's just a matter of when it all comes crumbling down. You can live like that until you can't.
Physical activity is so important I'm surprised companies generally don't actively encourage employees to exercise. Instead they stock the kitchens with sodas and junk food.
I wouldn't make exercise mandatory but I'd try to encourage everyone to a 40 minute workout in the middle of the day a few times a week. Sure, not all companies are equipped for that but many are.
The thing is most people are too tired before or after work and during the weekends. If we can get them to move a bit during the day it will work. And people will be healthier, less burned out and more productive.
I agree.
The expectation is silly, the workers will produce more despite the lost hour I'm certain of it.
Why don't these Mckinsey guys freaking try it already.
I'd say, from my armchair theory, there are a lot of factors that lead to burnout and most all of them I think stem from some underlying pressure to work more. It may he some culturally seeded external pressure of your peers or workplace saying you need to continually push the bar, it may be your own internal goals that create such conditions, but I think it almost always stems from setting and then continously trying to attain unrealistic goals in work.
If you can set realistic goals in realistic time increments that create a situation you can attain with a reasonable work life balance, you no longer need to push 10 hour days, you can take the evening off and relax. You don't need to take your evening and spend it learning some new tech or prepping for interviews to make your need career step.
The issue is that while the pressure can be internal, much of it is becoming external and out of people's control. The way interviews have shifted in the past 20 years is a pretty obvious case of this in my opinion, the bar has been pushed higher and higher due to external pressure pushing the bar up through competition. Many workplaces adopt ridiculous slave driving time management techniques that push people beyond comfortable levels, continously. For those who want to grow you do need to push your boundaries but even then, you need to do so realistically and not continously--people need time to stagnate and be comfortable before they grow a bit.
People sometimes get bored at a job because it's not challenging, they feel they aren't growing, the tech is old, whatever but I've rarely heard anyone complain in these situations that they feel burnt out. They may feel bored or stagnant but I find those situations far more bareable than burnout conditions.
My opinion is that burnout stems largely from Taylorism gone off the rails focusing on pushing human efficiency beyond its breaking point without caring about the humans involved. Technology is pretty bad because tech is a very efficiency focused industry with lots of creative engineers ready to figure out a new way to optimize every aspect they can without often without considering side effects. I don't think it's isolated to tech by any means but I think tech is uniquely positioned to create abusive pressuring situations more than many sectors.
When I worked as a contractor for VMWare, previously Pivotal Labs, we learned then taught a burnout proof way for teams to code.
As a developer, i suffered burnout all the time. I would get too emotionally vested into the code and work late to finish it. With Pivotal Labs, we coded in pairs, and it was considered rude to work on code outside of your pair. This plus other techniques like putting strong emphasis on emotional safety created an environment where burnout just disappeared.
Hasn't been my experience. I get mentally exhausted after just 2-3 hours of pair programming, and tend to be borderline useless the rest of the day.
Having to communicate the entire time your thought process, not really being able to just take the wheel and investigate things quietly for a few minutes, and if you're letting them drive, getting them to go to the right spots in the code and modify the right things (especially if english is their second language) not easily being able to get up and walk away from the computer if you need to ruminate on something for a moment...yeah, just fries my brain.
Still need to do it at my work, since I'm managing junior developers right now that just don't see some of these things without pair programming, but it's exhausting.
Part of that is the coaching junior developers that need extra handholding, but I've found it almost as tiring even amongst peers of equal skill, if it happens for an extended period of time.
Interesting. We did hear complaints like this from folks starting out. What I have noticed is that when working with Pivotal veterans, those with a few years under their belt, they tended to have long endurance for pairing. They also picked up tricks along the way to keep the pair engaged and allow for investigation.
Maybe its like furniture movers... it takes time to build up that endurance and mastery to get to the point where it is possible to do for 3 - 4 hours at a time. Pivotal was also strict with taking 15 minute breaks... one in the AM around 10:30am and the other in the afternoon around 3pm.... but each pair can decide on their own.
When I was a team lead in pairing teams, I did allow (and encouraged solo time), but the code written during solo would be consider spike code... code to learn and try stuff out. Ultimately to make it into prod code, it had to go through a pair.
Worked at places were some people would regularly tip over and recover in a infirmary. People die for companys. And it is not talked about.
Also good diagnosis tools, the model train projects. Somebody - in power, working on something small, controllable, with a end in sight. Can be anything, a website, a shop, anything as long as it is not the project that burned them out.
Go to any traditionally enviable career, such as the media careers of animation, VFX, and video gaming, and you will find soul crushing exploitation as the industry standard. Been there, each of those three industries, at the dominating top companies and the treatment of developers by management and the developers themselves is factually criminal, but a frog in boiling water sees no boiling water. I believe it is simple immaturity: I rarely meet an actual adult, most people are simply old children with the personalities to match.
I don't believe that the claim "83% of developers suffer from burnout" is true or even close to the truth, and I note that this is published by a company that provides "Insights from your Git data to help you experiment faster, ship reliably and prevent burnout."... So everyone's is of course burnt out and really need Haystack ;)
This survey was based on 258 developers responding from the UK. I don't recommend making sweeping generalizable claims about all developers in the world from it.
I wonder if the economic situation affects burnout. Managers push more to keep their jobs and protect their team. Individual team members push more of themselves to be seen as more productive. You only get productivity pushing yourself to a point .. after that is the redline zone and burnout.
This fear effect is compounded as you hear stories of bullweather employers doing hiring freezes (aka. AWS). I think we have a problem right now in tech .. too many people have been laid off to be absorbed in the same high-tech jobs. People will need to trade downwards, go to grad school, whatever. Not sure if I am missing some bright streaks of light in the cloud.
It seems a bit self inflicted to me. Managers where I work expect you to correct them if your workload is too much. But people are just hyper ambitious and/or anxious to do that so they under estimate the work and end up working overtime to deliver what they promised. Over time it becomes the norm among developers. I'm guilty of this as well. Like last night I had to help a new developer, I explicitly said that we could have a meeting the next day if he wanted, I told him not to feel pressured, but he insisted it was fine so we ended up working together late at night to get his environment set up.
The workplace is an inherently biased and unbalanced environment for a worker, and anyone about you is a potential threat. The company can afford to have you gone, you usually can't afford to be gone. So, when asked by a representative of said company's authority and power over you if everything is fine, you are very likely to say it's all good, even if it isn't, especially if you live in a country where being fired is easy. Your decisions as a manager can have me fired if you have a bad impression of me, or if something you repeat to your superiors itches them the wrong way.
In the same way, as a new developer, the impressions of more senior ones are a massive factor in whether or not you stay for more than 6 months. Not recognizing this inherent power imbalance is foolish.
As the other comment said, if you're managing someone, then _cut that shit quick_. Developer works super fast and finishes 1 week worth of work in a day ? Don't give them more work. What was assigned initially is done. Prevent them from giving more. But to avoid boring them, encourage them to take on more personal tasks, some general cleanups that they might have wanted, that is less of a duty to the employer and more of a pleasant head scratcher to them.
> like last night I had to help a new developer, I explicitly said that we could have a meeting the next day if he wanted, I told him not to feel pressured, but he insisted it was fine so we ended up working together late at night to get his environment set up
Its most likely he wanted to leave a positive impression. We're in a bad economy, people want to hold onto their jobs .. and the "easiest" way to appear like a good worker is doing long hours.
Its up to you and your team to cut that shit immediately otherwise you will all work all the time.
I've burned out a few times, each time the only way to recover was a new job.
The first time was ~4 years ago. Company I worked at did agile but required you hit 10 points a week. If you didn't you were pipped. On top of that the only way you could really hit the points was to work ~60 - 70 hour weeks. You were not allowed to consider how long implementing a ticket would take when scoring a ticket only how hard it was. This led to strife when scoring tickets. When covid first hit and the world was insane and my kids had to do home schooling (I have been remote for ~5 years) I hit 8 points the first couple sprints. I was pipped. Things like this, many 90+ hour weeks, debugging and fixing data in production, and being asked to lie to clients fried me. I burned out, would sit there staring at a screen for 8 hours and get like 30 minutes of work done.
After that my next job was immediately 90 hour weeks for 2 months. Not just me, dozens of people. I had coworkers weeping during standup on many occasions. Luckily I was contract so I got paid OT. Most of my coworkers did not. After a ~4 months of insane hours I just said screw it and refused to work more than 45. Everyone just dealt with it but they had to work more hours, I felt bad. Same job, next project we had no one to write requirements. so I had to do that which is not my skillset plus code. A year in, I burned out, would sit there staring at a screen for 8 hours and get like 30 minutes of work done. I lasted for another 6 months before quitting. Funny thing was even burned out I was getting more work done than most and they freaked out when I quit.
This current job I am a tech lead. It started off pretty good and I still dont work OT but my scrum master did nothing for the first 6 months so it all fell on me. He got fired but they are not backfilling him so its all on me. On top of that I have to manage developers including writing tickets for them, and manage up. Which means I lose 2 days a week essentially writing reports for leadership and doing busy work. I have come to hate standups. I don't think I am burned out here yet but I feel it coming on. I really need to take a vacation. Not a go somewhere with the kids one, just a stay home for 2 weeks and destress one.
Interestingly this all started when I started working in agile shops. Its just constant pressure, always a race.
Can't you decrease those to 2 times a week then? No scrum master and you are the lead? If management enforces 5 just do three async in chat or whatever.
> Interestingly this all started when I started working in agile shops. Its just constant pressure, always a race.
Agile's killer feuture is the great opportunity to micromanage and force a never ending sense of urgency.
To me a good symptom is to ask any software developer that has been into it for only a couple of years if they see themselves doing this same thing all their live and make some statistics.
Yes, it happens to many other professionals but software developers too.
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)
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.
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.
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.
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.
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.
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.
I am sceptical that burnout has become very en vogue.
I also think this why immigrants are eating locals' breakfast (so to speak). I do a lot of hiring & (very anecdotally of course) burnout is almost exclusively a topic of developed countries' software engineers. So much so, that I don't like hiring them (DACH region/Austria/Germany lately). And yes; I believe work life balance is important.
Low wages and poor social mobility makes you unable to care about your mental wellbeing, how surprising.
Yes, burnout is a rich country problem, because you otherwise kill yourself at the task because you can't afford not to. Give Vietnam western european wages and within 10 years, burnout will also be a talked about problem. Just because you don't have time to look at something doesn't mean it doesn't exist.
Burnout is a big issue. I think it is the main cause for high performing employees leaving companies (I read that somewhere - sorry I cannot find the reference).
A lot companies recognize this problem but I really do not know what is the best solution. I know that companies have policy that you are required to take your vacations every year. But that might not be helping in all cases.
Humans are just not made to always work at flank speed, but I feel like that's the expectation within the software industry, and I can easily see that leading to burnout.