DEV Community: Zainab

Choosing Yourself Without Guilt: A Lesson I Learned the Hard Way as a Developer

Zainab — Sun, 28 Dec 2025 19:55:31 +0000

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.

Not Everything Is Late.

Zainab — Sun, 28 Dec 2025 19:32:39 +0000

Introduction

A few years ago, I caught myself thinking:

“If I were better, I’d already know this.”

I was stuck debugging something I believed I should have understood by then —
at least according to Twitter timelines, GitHub stars, and people my age shipping projects that looked far more impressive than my own.

Nothing was actually wrong.

But I had convinced myself I was late.

If you’ve ever felt behind in tech

behind your peers, behind a roadmap, or behind the industry itself
this article is for you.

Why This Feeling Is So Common in Tech

The tech industry has an unhealthy obsession with speed.

We celebrate stories like:

“Self-taught developer in 6 months”

“Junior to Senior in 2 years”

“Built this startup over a weekend”

But what we rarely see is what sits behind those stories:

Years of context

Failed experiments

Restarts and detours

Quiet learning curves

Slow, unglamorous work

This is the part that actually builds skill.

As developers, we absorb these stories and turn them into expectations.
When our own journey doesn’t match, we assume we’re behind.

That’s where the “I’m late” feeling comes from.

The Core Idea

Not everything is late.

You’re just measuring your progress using someone else’s clock.

In engineering, timing is contextual:

Different backgrounds

Different access to mentors

Different learning speeds

Different life responsibilities

Yet we often treat growth like a race with one correct finish line.

That’s not how real-world engineering works.

Reframing Progress as a Developer
Progress Is Rarely Linear

Real growth looks like this:

Long plateaus

Sudden breakthroughs

Revisiting the same concepts again and again

You might feel stuck for weeks
then suddenly everything clicks during one debugging session.

That’s not failure.
That’s understanding compounding.

Skills Have Hidden Dependencies

You don’t “learn Docker” in isolation.

You also learn:

Linux fundamentals

Networking basics

CI/CD workflows

How systems fail under pressure

When progress feels slow, it’s usually because you’re building
foundations you can’t see yet.

Production Changes Your Perspective

Tutorials feel fast.
Production feels slow.

Why?

Because real systems introduce:

Trade-offs

Constraints

Legacy decisions

Human and organizational factors

That slowness isn’t weakness.
It’s maturity.

What I Got Wrong Early On

Looking back, my biggest mistakes were clear:

Equating speed with competence

Comparing visible outputs instead of invisible context

Underestimating how long deep understanding takes

The result wasn’t growth.

It was:

Stress

Burnout

Constant self-doubt

Everything changed when I stopped asking:

“Why am I late?”

And started asking:

“What am I learning right now?”

Healthier Ways to Measure Growth
Focus on Capability, Not Speed

Instead of asking:

“How fast am I learning?”

Ask:

“What problems can I solve today that I couldn’t solve before?”

Track Your Learning

Write down:

Bugs you fixed

Concepts that finally clicked

Mistakes you won’t repeat

Progress disappears quickly if you don’t record it.

Choose Consistency Over Urgency

Ten minutes a day beats panic-driven learning bursts.

Consistency compounds quietly.

Common Traps Developers Fall Into

Comparing your chapter 3 to someone else’s chapter 20

Assuming senior engineers “just know things”

Believing there’s a universal tech timeline

Treating pauses as failure instead of recovery

Let’s Talk

I’d love to hear from you:

When was the last time you felt behind?

What helped you realize you weren’t actually late?

Share in the comments
your story might help someone who’s struggling silently today.

Final Thoughts

Tech doesn’t reward speed alone.

It rewards:

Judgment

Patience

Pattern recognition

The ability to keep learning

You’re not late.

You’re building something meant to last longer than a viral timeline
and that takes time.

And that’s okay.