Introduction
I used to think good developers said yes to everything.
Yes to late-night deploys.
Yes to “quick” fixes that weren’t quick.
Yes to helping everyone else—even when my own work was falling apart.
Saying no felt irresponsible. Choosing myself felt selfish.
It took burnout, missed deadlines, and a quiet loss of motivation to realize something uncomfortable:
I was optimizing for everyone except myself.
The Backstory (Why This Matters)
Early in my career, I believed effort was the main currency in tech.
If I worked harder:
I’d learn faster
I’d be respected more
I’d eventually feel confident
So I overcommitted. Constantly.
Extra tickets. Extra context switching. Extra emotional labor.
From the outside, it looked like growth.
From the inside, it felt like slowly draining a battery that never fully recharged.
The worst part?
I felt guilty even thinking about stepping back.
The Core Idea
Choosing yourself isn’t about doing less work.
It’s about doing sustainable work.
In engineering, we instinctively understand this:
We don’t run servers at 100% CPU forever
We add rate limits to protect systems
We design for failure, not perfection
But when it comes to ourselves?
We ignore every principle we apply to production systems.
Implementation: What “Choosing Yourself” Looked Like in Practice
This wasn’t a dramatic career pivot.
It was a series of small, uncomfortable changes.
- Setting Boundaries Like You Set API Contracts I started treating my time like an interface.
Clear expectations
Explicit limits
No hidden side effects
Instead of:
“Sure, I can handle that too.”
I said:
“I can help, but not today. I’m at capacity.”
It felt awkward. Nothing broke.
The system adjusted.
- Reducing Context Switching (On Purpose) I noticed I was:
Helping multiple teams
Juggling unrelated tasks
Never finishing deep work
So I limited my “open threads.”
Just like limiting concurrent requests, my focus improved almost immediately.
- Stopping the Hero Mentality I didn’t need to be the person who always saved the day. Being indispensable is a fragile architecture. I documented more. Delegated more. Trusted others more. The team didn’t collapse. It got healthier.
What Went Wrong (Lessons Learned)
I waited too long.
By the time I acknowledged burnout:
My motivation was gone
Learning felt heavy
Even “easy” tasks felt exhausting
I learned that guilt is often a lagging indicator like logs you only check after an outage.
If you wait until things break, recovery is slower.
Best Practices (Developer Edition)
Treat your energy like a limited resource
Add “timeouts” to work that drains you
Review your commitments like technical debt
Optimize for long-term throughput, not short-term output
Sustainable developers write better code.
Burned-out ones just write more of it.
Common Pitfalls
Confusing availability with value
Thinking rest must be “earned”
Believing saying no makes you replaceable
Waiting for permission to protect your time
None of these scale.
Community Discussion
I’m curious:
What’s the hardest boundary you’ve had to set as a developer?
Have you ever confused burnout with “just needing to work harder”?
What helped you choose yourself without regret?
Drop your experience in the comments this is one of those topics we don’t talk about enough.
FAQ
Is choosing yourself bad for your career?
No. Chronic burnout is far worse for your career than healthy boundaries.
What if my team expects constant availability?
That’s a system problem, not a personal failure. Systems can be redesigned.
Does this apply to junior developers?
Especially to juniors. Learning is faster when you’re rested and focused.
Final Thoughts
Choosing yourself doesn’t mean you care less about your team.
It means you care enough to show up whole—not exhausted, resentful, or running on fumes.
In tech, we design systems to last.
It’s okay to do the same for yourself.
Top comments (0)