Journey

The Wake-Up Call

I failed a system design interview badly. I could code well, but when asked to design a large-scale system, I fumbled. I realized I’d been building systems without deeply understanding why they were designed that way.

My Approach

Studied real architectures. Read engineering blogs from companies like Uber, Netflix, Stripe. Understanding how real systems evolved was more valuable than theoretical knowledge.

Practiced deliberately. Found a study group and practiced designing systems weekly. Getting feedback from others revealed blind spots.

Started documenting. Began writing design documents for my own projects, even small ones. The discipline of writing clarified my thinking.

Asked “why” more. When encountering architectural decisions at work, I dug into the reasoning. Every system has trade-offs worth understanding.

The Shift

System design went from my weakest area to one of my strongest. More importantly, I now approach problems differently:

• I think about scale and evolution from the start
• I consider operational concerns alongside features
• I document decisions so future engineers understand the context
• I recognize that there’s rarely one “right” answer—only trade-offs

This skill has been invaluable as I’ve taken on more technical leadership responsibilities.

The Signs I Ignored

Looking back, the signs were obvious:

• Dreading work I used to enjoy
• Constant exhaustion despite sleeping
• Cynicism about projects and people
• Difficulty concentrating
• Physical symptoms (headaches, tension)

I kept pushing through, thinking it would pass. It didn’t.

The Breaking Point

I made a significant error in a code review—something I would have caught easily before. That’s when I realized something was seriously wrong.

Recovery

Recovery wasn’t quick or linear:

I took time off. Actually disconnected, not “working from vacation.”

I set boundaries. No more late nights as the default. Sustainable pace became non-negotiable.

I said no more often. Not every opportunity needs to be seized. Some need to be declined.

I rediscovered hobbies. Coding stopped being my only identity.

What I Tell Others

Burnout isn’t a badge of honor. It’s a signal that something is broken—in the environment, the expectations, or the boundaries.

Sustainable careers are marathons, not sprints. I’m still learning to pace myself, but I’m much better at recognizing the warning signs now.

The Fear

I’d avoided public speaking my entire career. The thought of standing in front of hundreds of people made me physically anxious.

But I had a story worth telling—our microservices migration had hard-won lessons that could help others avoid our mistakes.

Preparation

I spent three months preparing:

• Wrote and rewrote the talk multiple times
• Practiced in front of colleagues
• Recorded myself and watched (painfully) to improve
• Prepared for questions I hoped nobody would ask

The Day

The first five minutes were terrifying. My voice shook, my hands trembled.

Then something shifted. I saw people nodding, taking notes. They were engaged. The fear transformed into energy.

What Changed

The talk led to:

• Conversations with engineers facing similar challenges
• An invitation to write a blog post for a popular engineering blog
• Confidence to share ideas more broadly

Public speaking is still uncomfortable, but I’ve learned that growth happens outside the comfort zone. I’ve given several talks since, and each one gets a little easier.

The Challenge

The transition was harder than I expected. I was used to being valued for my code output, but as a lead, my impact comes from:

• Making good architectural decisions
• Unblocking team members
• Reviewing code and providing feedback
• Communicating with stakeholders
• Planning and prioritizing work

Key Learnings

Write Less Code: My job is to enable the team to write great code, not to write all the code myself. This was a hard mental shift.

Document Decisions: Architecture decisions need to be documented and communicated clearly. I started writing ADRs (Architecture Decision Records) for major decisions.

Invest in People: Spending time mentoring junior engineers has a multiplier effect. Their growth is my growth.

Say No: Protecting the team from scope creep and unrealistic deadlines is part of the job.

Growth Areas

I’m still learning how to:

• Balance technical work with leadership responsibilities
• Give constructive feedback effectively
• Navigate organizational politics
• Advocate for the team’s needs

Leadership is a continuous learning journey, not a destination.

Why I Started

I remembered how lost I felt as a junior engineer. Good mentors accelerated my growth tremendously, and I wanted to pay it forward.

What I Learned About Teaching

Explaining reveals gaps. When I couldn’t explain something clearly, it meant I didn’t understand it well enough myself.

Everyone learns differently. Some people need to see code, others need diagrams, others need to talk through problems verbally.

Ask, don’t tell. Guiding someone to discover the answer themselves is more effective than just giving them the solution.

Celebrate small wins. Progress isn’t always visible day-to-day, but looking back over months shows tremendous growth.

The Multiplier Effect

One of my mentees is now mentoring others. Seeing the knowledge and practices spread through the organization has been incredibly fulfilling.

Mentoring isn’t just about helping others—it’s made me a better engineer and communicator too.

The Catalyst

A production incident where our microservices got into an inconsistent state made me realize I didn’t understand distributed systems well enough. I was building distributed systems without understanding the fundamental challenges.

What I Studied

• Martin Kleppmann’s “Designing Data-Intensive Applications”
• Raft consensus algorithm paper
• Various distributed systems papers from MIT 6.824
• Built a toy distributed key-value store to understand the concepts hands-on

Impact

This deep dive transformed how I approach system design. I now think carefully about:

• Consistency vs availability trade-offs
• Failure modes and partial failures
• Idempotency and retry logic
• Event ordering and causality

These concepts have been invaluable in every distributed system I’ve worked on since.

What Happened

I deployed a change that looked safe—a small optimization to a database query. It passed code review, passed tests, and worked fine in staging.

In production, under real load, it caused a cascade of failures that took down the checkout flow for 45 minutes during peak hours.

The Aftermath

The blameless postmortem revealed several gaps:

• Our staging environment didn’t reflect production load patterns
• The query worked fine for small datasets but degraded exponentially
• We lacked proper circuit breakers
• Our alerting was too slow

How It Changed Me

This incident fundamentally changed how I approach code:

I think about failure modes first. What happens when this fails? What’s the blast radius?

I test with realistic data. Small test datasets hide performance problems.

I deploy incrementally. Feature flags and gradual rollouts are non-negotiable.

I invest in observability. If you can’t see it, you can’t fix it.

The incident was painful, but I’m grateful for the lessons. I’ve prevented similar issues many times since by applying what I learned that day.

The Story

I was using a library at work and found a confusing section in the documentation. Instead of just complaining, I decided to fix it myself.

The PR was tiny—maybe 20 lines of markdown—but the process taught me:

• How to read and follow contribution guidelines
• The importance of clear commit messages
• How maintainers think about changes
• The value of good documentation

What Surprised Me

The maintainers were incredibly welcoming. They thanked me for the contribution and gave constructive feedback. This positive experience encouraged me to contribute more.

Since then, I’ve contributed to several projects and even maintain a small library myself. Open source has been one of the best ways to learn from experienced developers.

What I Learned

This was a humbling experience. My code worked perfectly in development, but production revealed issues I hadn’t considered:

• Database connection pooling and timeouts
• Proper error handling and logging
• Monitoring and alerting
• Graceful shutdown and zero-downtime deploys

The first production incident (a memory leak) was stressful but taught me more than months of tutorials ever could.