Choosing Yourself Without Guilt: A Lesson I Learned the Hard Way as a Developer
Source: Dev.to
Introduction
I used to think good developers said yes to everything—quick fixes that weren’t quick, saying no felt irresponsible, and choosing myself felt selfish. Burnout, missed deadlines, and a quiet loss of motivation forced me to confront an uncomfortable truth.
The Backstory (Why This Matters)
- I believed I’d learn faster, be respected more, and eventually feel confident.
- So I overcommitted constantly: extra tickets, extra context switching, extra emotional labor.
The Core Idea
Choosing yourself isn’t about doing less work.
- We don’t run servers at 100 % CPU forever.
- We add rate limits to protect systems.
- We design for failure, not perfection.
When it comes to ourselves, the same principles apply.
Implementation: What “Choosing Yourself” Looked Like in Practice
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 saying, “Sure, I can handle that too,” I said, “I can help, but not today. I’m at capacity.” It felt awkward, but nothing broke.
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” to focus on fewer, higher‑impact items.
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, and trusted others more.
The team didn’t collapse; it became healthier.
What Went Wrong (Lessons Learned)
- My motivation vanished.
- Learning felt heavy.
- Even “easy” tasks were exhausting.
I realized guilt is often a lagging indicator—like logs you only check after an outage.
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.
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
What if my team expects constant availability?
Set clear expectations, negotiate realistic on‑call or response windows, and communicate the impact of constant interruptions on overall productivity.
Final Thoughts
Choosing yourself doesn’t mean you care less about your team. It’s okay to do the same for yourself.