The trick is to stay out of product meetings and not actually care how cool and interesting and useful the product can or will be. Only give feedback to your inner circle (manager, peers) when asked about it. Most importantly, enjoy the tasks assigned to you however dull or basic they may be after you mastered them. Be proud of your work.
EDIT: These are things to do together if you have no agency at a company to change it. If you need help getting agency, work with your manager to get data to back up your arguments.
I've found some combination of agency, upside, and interesting problems to solve are the recipe for not burning out.
Not working for a jerk manager / at a company with bad culture helps, but is not sufficient. I've burned out in a "nice culture" company faster than a "cutthroat culture" company because the nice guys didn't allow much agency.
> I could never enjoy tasks assigned to me when they're dull and basic things I've mastered.
If you do need more interesting work and can’t shift teams then find a new job. You will eventually find yourself needing to do the same again after you’ve mastered the new challenge. Keep it up and you will run out of leaps. However if you want to exist in a place for a while you need to accept that not every project, task, idea will be exciting work. Once you accept this, it also opens up doorways with what else you can do with your time. Since you have a mastered skill set, these menial tasks should not be weighing you down to free yourself from the drudgery of work.
> As for being proud of my work... well I'm always proud of my work. I still burned out. I don't want to even touch the things I'm proud of.
You should always be critical of past mistakes and look to correct but you should always put your best effort forward. That is what pride in work means. You shouldn’t have to admire every piece of work you deliver as a masterpiece, which is what I assume you mean by wanting to touch it. You should always carry a positive mindset about your work and not treat each success and failure in your life as some sort of definitive legacy. Invite in and operate under best intentions.
A lot of my advice is about how it works in harmony, not some quick instant burnout solution. Resting is important as well (breaks, vacations).
Anecdotally I was recently hired at a company that is in dire straights. This weighed on me heavily for the first six months, eventually they shrunk my team. However I cannot afford to get burned out. So the only options are to extract as much of the burden from me by being a cog in a bullshit factory or find a new job in a psychotic job market.
This is good advice, work is not a one size fits all solution for self actualization. Most workers just want to fill their requirements and do something meaningful to them with the rest of their time.
I especially like your point about enjoying the fruits of mastery of a task.
They replied to the one that told them their magic advice didn’t actually help them (and they still burned out) with some variety of “That had nothing to do with my advice, you just did it wrong.”
I didn’t say they did it wrong. The commenter tossed out two pieces of my advice as not relevant and I wanted to reinforce that all the advice was linked. Not a pick-3 three, toss two situation. What is not cool is having some sort of animosity or negative reaction because I chose to reinforce the ideas.
Someone who is not willing to listen or reconsider will easily be susceptible to burn out again. Especially to advice only intended to help not criticize.
I was just thinking the other day that all of the code I've written for companies is now dead and gone. I wrote some really elegant, interesting stuff at a few companies and now it's only a memory in my head.
Amen to this. Of the biggest frustrations I've had in my career, at the top of the list is working with engineers who do not take pride in their craft. I'm amazed at the number of people that just dial it in or make minimal effort. Perhaps some of these people are burned-out, but surely not all.
My goal was to get whatever I was working on not just "done", but "done-done". To a state where, if I walked away, it could live on in a working manner and be easily maintained by someone else. That meant having good test coverage, up-to-date documentation, instructions on how to get started with the repo, notes on dependencies, etc. Sometimes that someone else is future me, six months or six years later.
I experienced burnout early in my career, in the dot-com era, and it became especially acute when then the bubble burst. All those long hours (mostly) for naught.
The best times were at companies where everyone was all-in and we each had each-others back. Rare, but amazing when it happens. These were all at startups.
I've gradually come to a similar conclusion. The only antidote is to make sure the work you're most proud of are all open source. It's most likely going to be code you wrote in your spare time.
My GitHub has a few pieces of code that I'm really proud of. And some companies actually ask for code I'm proud of as part of the interview process, so I have that ready and it helps.
That’s okay, the only person that cares about your legacy of code is you. Be proud that you’re capable of the work, not that you have a commit history when no one is asking for that.
Worth remembering we write code to create human value. Somewhere, in some way, your elegant code actually ran and did a thing that led some number of humans to be enabled or understand or somehow be affected by it.
Personally, I find this aspect of the work somewhat profound.
My graveyard of projects and dreams stretches out behind me and I feel saddened to know that these articles representing portions of my life never achieved what I had hoped for them.
However, I've come to view my work like a mandala or some representation of our mortality itself; our works and our lives are temporary.
We can make the most of the brief moment that we have – whether that be through work or through parenting or through base jumping – whatever that may be for each of us, or we can choose to do nothing with that moment, knowing that it's ephemeral and will be gone soon anyway.
I choose to try making each day's the best code I have ever written; I want it to be "beautiful" and maintainable in spite of knowing that it will be refactored, deleted or decommissioned at some point.
My oldest code still in production is 20 years old.
Work for non tech companies if you want it to last. Some industrial code is even older - my company has just removed some devices that requires a floppy disk to update
It’s ironic that the absolute shittiest code I’ve ever written right when I came out of university, has been and still is powering a bunch of company websites for 15 years.
"enjoy the tasks assigned to you however dull or basic they may be after you mastered them. Be proud of your work."
Ohhh, this is freakin hard to me. Bunch of users are complaining about feature not working properly in our Enterprise product, but it's not impactful enough to fix, because those users are not going to complain to their CEO/COO about broken feature in our product, because they themselves might be labeled as COMPLAINER and eventually kicked out.
What's impactful? Of course new shiny AI-powered green button, it's so amazing, project created by a super talented story teller engineer and who is good at selling it to leadership. Does it impact metrics? Yes, of course, those metrics are also crafted specifically for that feature. (more time user spends on that page, more impactful. Is it? maybe users are confused or can't find what they're looking for? Can you tell it to leadership? Ohh they approved this metric and project, are you against VP+ leadership's decisions?)
And we wonder, why do we have double digit customer churn rate.
If this is hard then you’re ignoring the rest of my comment for one sentence. These need to happen together as each piece supports the other one. Stop caring about what your companies crappy product could be if you have no agency to change it.
Sure, I’m not saying being involved isn’t a great way to live your working life. However not being involved is a great way to avoid burnout by reducing stress factors.
That's funny I usually think the opposite. I derive no satisfaction from writing software for dubious ends. Understanding product value and/or helping to determine priorities makes things feel more tangible. Maybe better to say that you should find your own happy place.
The problem is you can control the first but not the latter. You can control doing quality technical work. You cant really control whether what you do has much value (the market decides that, not you)
This is so hard! It leads to poor products/the loudest voice wins. Rarely is there a coherent long-term vision. Even at the benefit of the single participant/employee
I would argue you’re still caring too much. If you can abstract your care into another project either at the company or in your personal time the crappy product won’t matter. If you have to speak against someone, get data to back yourself up. Or get the loud mouth hooked on data and solve it that way.
Not caring combined with low effort is one of the systems. Not caring with good effort is not. Be proud of your work and you won’t become disassociated.
Not caring doesn’t mean checking-out it means being satisfied with your paycheck and not needing more than the limitations if your job.
EDIT: These are things to do together if you have no agency at a company to change it. If you need help getting agency, work with your manager to get data to back up your arguments.