If you are exhausted but still shipping, read this first
Burnout in software engineering rarely looks like refusing to open your laptop. More often it is the senior dev who closes five Jira tickets while feeling nothing, the mid-level who dreads standup, or the bootcamp graduate who studies four hours every night until weekends disappear. At Toolliyo we coach engineers across .NET, React, and cloud tracks—and the same pattern repeats: skills grow, energy does not recover on its own.
This is not a generic wellness article. It is a recovery plan you can run for six weeks while still employed, with scripts, metrics, and realistic trade-offs. AI coding assistants appear where they genuinely reduce load—not as another obligation to master.
How to tell burnout apart from a bad sprint
A hard two-week release leaves you tired but proud. Burnout lingers past the milestone. Watch for these signals over four or more weeks:
- Cynicism about code quality — you merge shortcuts you would have fought six months ago.
- Emotional flatness — praise and blame land the same.
- Physical debt — sleep that does not refresh, headaches, gut issues without a clear medical cause (see a doctor anyway).
- Identity fusion — you cannot describe yourself without job title or GitHub streak.
One honest check: if you had four weeks of paid leave tomorrow, would you feel relief or panic? Panic alone is not burnout, but relief plus dread of returning often is.
Week 1: Stop the bleeding (non-negotiables)
Sleep floor
Pick a wake time you can hold five days a week. Work backward to a bedtime. No "catch up" on Sunday that wrecks Monday. Engineers treat uptime like SLOs but ignore their own. Track sleep for seven days in any app; you need a baseline, not perfection.
One boundary announcement
Send this to your manager or team lead—edit the tone, keep the structure:
I'm running hot and need to protect focus time for the next two weeks.
I'll be offline after 6:30pm local and not checking Slack until 9am.
Critical production issues still reach me via the on-call rotation.Most teams accept boundaries when tied to reliability, not "self-care." If your culture punishes this, that is data about the job, not about your weakness.
Cut one voluntary obligation
Side project, open-source PR marathon, extra certification, daily LeetCode—drop one for four weeks. Recovery needs slack in the system.
Week 2: Refactor your workload like a backlog
List everything you touch in a typical week: meetings, reviews, on-call, mentoring, coding, learning. Tag each: must, should, nice. Ask your lead which "should" items can move to next quarter. Real example from a .NET team we advised: a developer spent six hours weekly on ad-hoc Slack architecture questions. They turned it into a Thursday office hour and reclaimed two deep-work blocks. Velocity did not drop; interrupt load did.
Use AI thoughtfully: summarizing meeting notes or drafting test stubs can save an hour. Do not add "learn ten new AI tools" to an already full plate. One assistant, one workflow, measure time saved for two weeks.
Weeks 3–4: Rebuild energy, not hustle
Movement without gamification guilt
Twenty minutes of walking after lunch beats a abandoned gym membership. Consistency beats intensity for nervous systems fried by alert fatigue.
Social connection outside tech
One non-screen activity weekly: cooking with someone, sport, volunteer shift. Engineers isolate because every hobby becomes a repo. Let one thing stay unoptimized.
Micro-wins in code
Pick one small refactor or bug with clear done criteria. Finish it in a single session. Dopamine from completion helps when big roadmap items feel endless.
Week 5: Manager and team reset
Schedule a thirty-minute 1:1 framed as sustainability, not complaint. Bring three bullets: current capacity (%), top risk if load continues, one proposal (hire, descope, rotate on-call). Example proposal: "If we keep scope X, I need story Y removed or review load shared—here is a fair rotation."
If leadership responds with only "hang in there," document and escalate HR or internal mobility. Chronic unsustainable load is an organizational failure, not a personal defect.
Week 6: Design your sustainable baseline
Write a one-page personal operating manual:
- Maximum meeting hours per week you will accept.
- Learning budget: e.g., three hours on Toolliyo paths, not twelve.
- On-call recovery day after incidents.
- Signals that mean "slow down" before crash (irritability, skipping meals).
Share relevant parts with your partner or a peer accountability buddy—not for approval, for visibility.
When to get professional help
Therapy or coaching is appropriate if sleep, mood, or substance use shifts persist beyond six weeks despite workload changes. Many employers offer EAP sessions. Burnout overlaps with depression; treat physical and mental health seriously.
What not to do (popular bad advice)
- "Just take a vacation" — helpful as punctuation, useless if the job re-burns you in ten days.
- "Grind harder until promotion" — promotions rarely fix broken processes.
- "Replace sleep with AI productivity" — faster typing on four hours of sleep deepens the hole.
Returning to learning without reigniting burnout
When you are ready for courses again, cap at three focused sessions weekly on Toolliyo or similar platforms. Pick one path (.NET, React, Azure) until completion—not five parallel tabs. Progress compounds; overload does not.
Closing perspective
Your career is a decades-long system. Burnout is technical debt in the human layer: ignore it and every feature ships slower eventually. The recovery plan that works is boring—sleep, boundaries, descoped work, honest conversations, and patience. That boredom is how you get back to caring about code quality and teammates again. Start week one tonight: one boundary message, one dropped obligation, one sleep log. The rest can follow.