The Software Engineer Life Hack to Prevent Burnout
Burnout is the silent productivity killer for software engineers, and functions rather like a stealth memory leak. It goes unnoticed until everything grinds to a halt.
Between endless Slack pings, hunting down bugs and an 8:30 standup “because the team wanted it, and you’re more productive” combine to burn out engineers, unless you learn one critical skill. The skill of setting boundaries.
What Are Boundaries, Anyway?
Boundaries are the rate limiters for your life, and work to stop work being everything for you.
A boundary can separate “I’ll just fix this one last bug” from “It’s 3 AM, and I haven’t eaten dinner yet but this must be done at all costs”. Elon Musk doesn’t burn out because he chooses to work long hours and when he needs a day off can easily take one (and he can work from home and abroad as he chooses). The software engineers under him seldom have freedom to choose which JIRA ticket to attempt first, let alone their start time.
The problem is that software engineers (me included) are often terrible at setting them. Companies use the fact that most software engineers are conscientious types to squeeze the most development out of them possible. The fact is not all problems are ours to fix as software developers, and not all tasks need to be completed yesterday.
Life Hacks: Software Engineers Edition
When you’re out of office, you should be out of office. I know that sounds rather basic, but here we go.
When you’re out of office, you’re out of office. That means you don’t respond to emails, you don’t check Slack, and you definitely don’t hop on an impromptu Zoom call because someone said it’ll “only take five minutes.” (Spoiler: it never does).
And here’s the deal. Set your out of office message for vacations, and don’t work in your own unpaid time. For bonus points note that you don’t have to wait for vacation to use an out of office message. You can use the out-of-office reply during work hours to carve out uninterrupted time for deep work. It’s a polite way to say, “I’m busy solving real problems; please come back later” and give yourself breathing space for actually getting your work done.
It’s one boundary that’s easy to set, and you’ll see management and leadership doing the same so you will be in good company.
My Experience
Once a senior developer without any management responsibility wanted me log in during a personal day to learn about a third-party software solution for our onboarding process. My response? “The reservation for my Mother’s birthday lunch can’t be moved, genuinely”. I’m still annoyed that someone tried to make me give up my personal day for a sales pitch though.
Burnout Is Everyone’s Problem
Let me tell you, no one’s going to hand you a gold medal for answering emails at midnight. No one’s going to promote you for being the person who’s always “on.” If anything, they’ll expect it. Boundaries aren’t just a nice-to-have; they’re essential for long-term success.
By avoiding burnout you are actually helping your whole team.
How to Set Boundaries Without Making Everyone Hate You
There’s a danger here. Nobody wants to be seen as “that developer” who shirks their job and gets as little work done as possible. Setting your boundaries should not mean less work, it should mean predictability for outcomes and honesty about what is possible.
So, to prevent everyone from hating you, do the following,
Be Transparent
Let your team know you’re setting boundaries for productivity, not because you hate them. Most people will respect your honesty, as long as they don’t feel like you’re just dodging work.
Set Expectations Early
If you’re not available after 6 PM or on weekends, make it clear. A quick, “I’ll handle this first thing tomorrow” can work wonders and make it clear you can’t be bullied into work.
Use Tools to Your Advantage
Schedule emails to go out during working hours. Use Slack’s “Do Not Disturb” mode liberally. Automate the hell out of anything repetitive.
Don’t Feel Guilty
This one’s hard. Engineers are often conscientious people-pleasers who want to deliver at all costs. But remember, you’re no good to anyone if you’re burned out and barely functional.
Conclusion
The next time you’re tempted to send just one more Slack message or answer one more JIRA ticket after hours, think about this: would you rather spend your evening debugging someone else’s poorly written code or living your actual life? If you don’t have one of those, you should probably be using your time to learn a new framework or language rather than doing grunt work for no money.
Asking to be paid for the work we do isn’t a problem and represents a clear setting of boundaries that is appreciated in most companies.