I don't feel that burnt out is coming from the coding, it's coming from the business side of things. When you're not aligned with the same goals or expected quality of work it'll slowly chip away at your mental fortitude.

Finding balance isn't something that is taught in school, in courses or in the professional setting. At least it hasn't been in my experiences.

It's taken me burning out and slowly and still recovering to find a balance I'm comfortable with. I code on weekends for fun sometimes but the project has to light that fire of inspiration otherwise it's just not worth it anymore.

That has been my experience post burnout anyway. If you're becoming cynical of your job role, or people you work with take a step back and check yourself for signs of burnout.. Change jobs and effort levels and find something you align with more.

One of the factors of burning out is a lack of control over the pipeline, that is over the contents, speed, and quality of what flows in and out.

So the weekend coding is an example of the opposite - having control over the choices, owning your time and inspiration.

Well, some degree of OCD likely is another factor in the burnout and the weekend coding just manifests this OCD.

Managing the high degree of complexity while being constrained by time by itself has a huge toll in the burning out.

Let's see... 14 days on call every 3 months. 3 releases a week. All the normal review work. PRs, design, etc. SCRUM meetings. Meetings before the meetings. Crazy deadlines which were arbitrarily given by someone in another group. Being up late to make changes because the business deems it too risky to do it during regular business hours. Endless performance testing, e2e testing which always generates defects that arent really defects but still need 30m of my time. Upgrade this or that to the latest. version because xyz no longer supports what you have. Endless security vulnerabilities that need to be upgraded. Pipelines that need to be upgraded or fixed just to get a release. Failing tests which need to be investigated. Hundreds of configuration points which control process flows. Never ending lower environment problems. RTO. Constant fear of being laid off.

Definitely no way anyone could be burnt out.

I actually want to work on my own projects during the weekends if I can. That somehow brings me happiness compared to what I work on at work, which is bogged down by external issues. My personal projects I have no one to report status updates to, no one to tell me "I'm doing it wrong" no customers to support, freedom to mess up. Lol

Such a great list. Thanks for writing.

I full agree these things matter us. These endless paper cuts tatter us as we go.

Still I think the real suffering is less about these little indignities, & more a cosmic sense that the business doesn't get it, doesn't see the real work, doesn't care. It doesn't seem like businesses fundamentally believe in us, our craft, or our talents. Performance review even when going great tends to recognizes us only in blunt vague generalizations.

As craftsmen we all too often feel alone & separated from the org when we are doing are best acts. Hard finicky stuff pulled together by hook, crook, and a couple dashes of wit. Finding excellent libraries and tools to offload hard aspects of the task.

The company can then be merry that they've built a great product, hopefully. But it feels like camaraderie - through good times & bad! - would come from sharing such incredible work & time, but the organization doesn't fully see. The faint distributed sensory network of the discorporal org miss the best parts of truth our code wroughts out.

Yeah, the burnout isn't usually coming from the coding (though it may be in some cases), it's from all the pointless bullshit that gets in the way of said coding. In every job I've gotten burnout from I've wanted to keep coding, and I would be happier if I could actually get to do so. But then either the business side got in the way, a dependency on another team got in the way, etc. So the frustrations just mounted up and up, and the feeling of hopelessness set in.

Yes! I’ll add on—endless requests from the suits to account for every task in a way that fits into one of their stupid (and usually new) buckets. Random 11th hour emergencies from poorly-vetted implementations. Having to fight leads and PMs of other teams to take ownership of or be flexible about _anything_. Tasks that are more about optics and saving face than about making anything better. Architects who “don’t write code anymore” but expect to be able to dictate how others approach the craft.

> Architects who “don’t write code anymore” but expect to be able to dictate how others approach the craft.

They are called staff engineers now. Highly paid, but can't save the services when on-call.

Wow, you very accurately explained my life, except i'm on call even more than that.

And I think somehow you understated the security patching.

What drives me crazy is I'm always behind, and when my manager asks me to do something, I'm always having to argue for higher priority things that are beyond obvious.

But if it's not his top priority, I get to feel bad by repeatedly getting asked in multiple meetings about whatever his highest priority topic is.

That's what drives me nuts. It feels like my managers way to get me to do things is to waste so much of my time, that I end up giving in just to not have any more of my time wasted.

>Wow, you very accurately explained my life, except i'm on call even more than that.

I'm sorry, it has to be one of my least favorite things about this career. Nothing worse than getting calls off-hours when it's only you. Feeling marooned is never a good thing. I am currently hoping my phone doesn't buzz today! Hope it's quiet for your sake!!! I don't deal in anything lifesaving or absolutely critical, but it sure does feel like it while you're on call.

>And I think somehow you understated the security patching.

Oh yes I do. 8+ critical CVEs on one microservice, you upgrade the libraries/dependencies with the CVEs just to find the new version has 2 other CVEs. Worse yet, you upgrade the dependency and it breaks other functionality (generally from internal dependencies that haven't been upgraded since they were created, LOL). To make matters worse, all of this is inherited and often we had nothing to do with the initial development. I get it, they need to be fixed so there aren't other bigger problems, but it's death by 1000 paper cuts.

>What drives me crazy is I'm always behind, and when my manager asks me to do something, I'm always having to argue for higher priority things that are beyond obvious.

I just wish they would give focus/time to preventing on-call/customer issues so we could all be more rested/fresh/prepared to handle all the changes in priority! Make things so we don't have to spend large amounts of time fixing them. Actually evaluate failure scenarios and address them. Being extremely intentional with our time as a team. I am currently dealing with EOY reviews and displaying my value so I don't have to potentially move for RTO (I despise being in an office and was so incredibly happy to find remote work). 6 years of working remote and suddenly it's a problem from leadership?! I struggle to find the energy to argue lately. Again, it's not even software development related! Weird times.

I haven't done any end of year work, or prepare for the new year work.

I've worked remotely for 16 years, and now they want me to RTO when I haven't worked in that office in 16 years, and literally no one I work with on any topic is there at that office. I work for a global team.

My team is gone home by the time the office opens...

If they make me go into the office alone, then I should stop having any meetings before my office time, which would mean I have zero meetings. No communication with anyone, alone in n office.

Let alone pending layoffs.

And yet, I have to continue to keep my service up and functional with features for my customers, while balancing everything else.

I'm not sure I've felt this down about my career in the entirety of it. What is the point right now?

Burnout doesn’t come from writing software in my experience. It comes from dealing with increasing amounts of bullshit in order to be able to build the right software. This isn’t a tech problem but a business one.

I wish they would link to the actual Jet Brians survey in the blog post which is far more interesting https://www.jetbrains.com/lp/devecosystem-2023/.

For me, "weekend coding" was actually important to avoid burnout and preserve the fun of coding I had decades ago as teenager.

In a "professional context" this can be quite challenging.

I think that software development moves in terms of tools, libraries and to a lesser extent, languages faster and more frequently than most professions. You're also largely expected to learn in your own time.

I've been at it since the mid 90s and the to spend 10-15 hours a week on my craft. From reading articles, looking at libraries to personal projects, it doesn't stop.

I don't expect everyone to do the same, but it does make a massive difference.

> You're also largely expected to learn in your own time.

Was easy when I didn't have kids. Not anymore.

Yeah it does get harder with kids. I am sometimes able to split the reading time in the clock, like when there's a half hour or less between meetings

Still prioritize workload, but the to need at least a half hour to get in the flow.

Most of the weekend coding is for learning stuff that is expected at work, but hardly given the time to learn, an escape to have fun with technologies that will never be allowed to deploy into production at work, and lately to keep the HR filters happy to be feed with some random Github content.

However only if there aren't more pressing matters from family and friends, which matter more than any line of code.

Is it actually common to get burned out on coding or technology work itself, or is it just that we get burned out on agile and other corporate BS?

Coding in my hobby projects alleviate burnout for me in much the same way mediation, or just relaxing with my family does. It's a way to switch focus to something soothing.

There are time when I'm too mentally exhausted to focus on coding at all, but most "burnout" is not that for me, but increasing feelings of resistance against working on something specific. Sure, it can sometimes rise to a level where it expands and you shut down and don't feel like doing much of anything, but to me those hobby projects feel like they help avoid that.

Hacking on game with my son, or my many "productivity" projects that aren't so much about my productivity as about bikeshedding my own tools because it's enjoyable has very different properties to a work project.

Nice and quick article. It's kind of clear that the problem is not coding. It's fun and creative.

For me it's clear that most challenging thing is managing egos, not naming variables. Egos decide procesess and rules with insufficient data. Some egos even like to decide with insufficient data and twist the measurements later to conform their views.

So: Self ego, managers egos, shareholders egos, and the infinite edges between these entities.

It's certainly harder than rust and monads :D

A new software guy recently told me that he was planning to read a textbook over the weekend so that he could be prepared for a technical discussion meeting during the week. My thoughts were 1) you must be really bad at time management and 2) you must be really bad at setting work-life boundaries. If I were in that situation, I'd be asking for a charge code from management.

It's hard not to tie your own identity up in how 'good' of a developer you are, especially when you're green. It can be incredibly motivating, too. That said, over the years I have found it easier to let go of a bit of that stress/anxiety of being 'bad' since realising that so little of the quality of my output is actually in my control. Sure, I write the code, but do I get final say in the design? In the issues I encounter along the way and how I accommodate them? Can I say "our in-house framework is dogshit and it's time to bin it"? Nope, I'm a cog, and once one mediocre piece of code leaves my machine off to generate Business Value TM, I'm simply required to repeat the process. Even keen software craftsmen can't really arrive at consensus on what quality code is in all scenarios, so how will a business do so when all they want is to generate profit, and quality code is often not a requirement to achieve that in the short term? There's just no incentive. I do my best because I derive some satisfaction from it, but the moment I hit resistance, I remind myself that I'd do it differently if I was given the choice, and I proceed with whatever garbage I need to do to get paid.

-- me, a part of the 70%

I burned out, quit my job, travelled a while and in the end fell in love with coding again. Coding doesn't burn out, boring coding does.

Coding and software development are an amazing outlet for creativity. Software developers have the potential to do truly amazing, fun, useful things.

I think that's why coding on the weekends is such a prevalent "problem". Of course, I don't think it's "the" problem at all.

Coding for yourself and coding for an employer are two completely different things.

They're so different most people looking over my shoulder couldn't tell the difference. I don't think "completely different" is an accurate description.

I'm sure this could be said for most people looking at something they have zero understanding in.

I couldn't tell the difference between workmen doing things on my street, but they very well may be "completely different".

Interesting article, now time for me to go do more coding on the weekend. :-)

"The fantastic element that explains the appeal of games to many developers is neither the fire-breathing monsters nor the milky-skinned, semi-clad sirens; it is the experience of carrying out a task from start to finish without any change in the user requirements."

I stopped hobby coding over 10 years ago. I don't want to even think about code on the weekends.

The hard part of my job comes when I’m not coding.