DEV Community: Yash Goswami

The Hero Developer Must Die: My Journey from Midnight Savior to Team Builder

Yash Goswami — Fri, 04 Apr 2025 04:59:22 +0000

For years, I was that developer. You know the one. The midnight cowboy who rides in when production is burning, slams Red Bulls, and hammers at the keyboard until dawn breaks and the system is magically working again.

I was the hero. The savior. The fucking idiot who created a toxic culture while slowly destroying my own health and sanity.

This is the story of why that hero developer had to die.

The Glory Days of Fire Fighting

There’s an addictive rush to being the hero. I’m not going to pretend there isn’t.

When Slack is blowing up with “SITE DOWN” alerts, when the CEO is texting the CTO, when revenue is bleeding by the minute—being the person who can make it all better is a powerful drug.

For years, I lived for that adrenaline. You know what I’m talking about if you’ve ever been there:

That rush when you’re the last one standing in a war room call, and everyone’s watching you work your magic
The silent glory of committing a fix at 3 AM while the rest of the team sleeps
The way people look at you the next day, with that mixture of awe and relief
The Slack messages thanking you for “saving our asses again”
The praise was intoxicating. “We don’t know what we’d do without you.” “Nobody else understands the system like you do.” “You’re a lifesaver.”

I wore my sleep deprivation and chronic stress like badges of honor.

The Beginning of the End

The problem with playing the hero is that it’s ultimately a losing game. Eventually, something breaks that even you can’t fix—at least not quickly. For me, it was an outage that lasted 36 hours and cost the company a seven-figure sum.

Despite barely sleeping for two days straight, despite my heroic efforts, the system stayed broken longer than ever before.

And in the post-mortem, an uncomfortable truth emerged:

My heroics had actually made the system more fragile, not less.

How? In ways that might sound painfully familiar to many of us:

Knowledge silos become the norm. Nobody else fully understands critical parts of the system because the hero built them in isolation during late-night coding sessions.

Processes get bypassed. Emergency fixes often skip code reviews, tests, and documentation, introducing subtle bugs that trigger future outages.

Unhealthy dependencies form. Teams stop investing in proper monitoring, alerting, and self-healing systems because, hey, why bother when you have a hero who will fix it?

The abnormal becomes normal. Production issues that should be treated as serious system failures become just “Tuesday night, waiting for the hero to fix it.”

The realization hit me like a freight train: I wasn’t the solution. I was part of the problem.

The Painful Transition

Giving up the hero role was harder than I expected. My identity was wrapped up in being the savior, and letting go meant confronting some uncomfortable truths:

Maybe I liked being the only one who could fix things. Maybe that made me feel irreplaceable.

Maybe I didn’t trust my teammates enough to let them handle critical issues.

Maybe I was addicted to the praise and recognition that came with saving the day.

Changing this pattern meant more than just altering my work habits. It meant confronting my own ego and insecurities.

It meant being willing to be just a member of the team—not its savior.

Building a Team That Doesn’t Need Heroes

The transformation didn’t happen overnight, but over the next year, I shifted my focus from being the hero to building a team where heroes were unnecessary:

Eliminating Knowledge Silos

My first task was making myself replaceable. That meant:

Documenting every dark corner of the systems I’d built
Pairing with different team members to share context
Intentionally taking vacations where I was completely unreachable
The hardest part? Watching others struggle with problems I could have solved in minutes. But letting them figure it out, even if it took longer, was the only way to build a resilient team.

Building Safety Nets

Instead of being the safety net myself, I redirected my energy to building actual safety nets:

Comprehensive monitoring and alerting
Automated recovery procedures
Feature flags and kill switches for every new capability
Rigorous testing, including chaos engineering
These systems might not have the glamour of the midnight hero, but they prevent disasters instead of merely responding to them.

Creating a Blameless Culture

The hero mentality thrives on the narrative of “everything was broken until I fixed it.” I had to help foster a different narrative:

Focusing on system failures, not personal failures
Treating every incident as a learning opportunity
Celebrating prevention, not just cure
Recognizing that the most impressive engineers aren’t those who fix things—they’re those who build things that don’t break

Embracing Boring Solutions

Heroes love complexity. It gives them the chance to show off their brilliance. I had to learn to embrace boring, reliable solutions instead:

Standard patterns over clever innovations
Well-understood technologies over bleeding-edge tools
Small, incremental changes over massive rewrites
Predictable performance over occasional brilliance
Life After Heroics

It’s been two years since my last middle-of-the-night emergency fix. Here’s what changed:

Our systems are more reliable than ever. We’ve reduced critical incidents by 78%, and when they do happen, they’re resolved faster—usually during business hours.

The team is stronger. Knowledge is distributed, everyone participates in on-call rotations, and no single person is irreplaceable.

We ship more features. When you’re not constantly fighting fires, you have time to build new things.

I sleep through the night. My stress levels have plummeted, and I no longer have the constant anxiety of waiting for the next alert.

We’re a healthier organization. New team members can onboard faster, processes are documented, and we can scale without everything breaking.

Most importantly, the new engineers don’t have to become heroes to feel valued. Their contribution is measured by the value they add, not the disasters they avert.

Should All Hero Developers Die?

I’m not saying there’s never a time and place for heroics. When a genuine black swan event occurs—something truly unpredictable and catastrophic—having someone willing to go above and beyond can be invaluable.

But those should be rare exceptions, not the default mode of operation.

If you find yourself playing the hero regularly, it’s a red flag. Not about your abilities or dedication, but about the health of your systems and your team.

The Ultimate Legacy

The irony is that my greatest contribution wasn’t any of those midnight fixes that earned me so much praise. It was the work I did to make myself unnecessary—to build systems and teams that don’t need heroes.

The hero developer had to die so that a more resilient team could live.

And honestly? I don’t miss that asshole one bit.

Fear AI Replacement? You're Already Replaceable

Yash Goswami — Fri, 28 Mar 2025 05:34:29 +0000

If you think you're going to be replaced by AI, then you're definitely going to be replaced by AI.

Let me tell you why your fear of AI is a self-fulfilling prophecy. This isn't another bullshit think-piece about "AI coming for our jobs" or whatever the LinkedIn influencers are fear-mongering about this week. This is about something far more fundamental: your fucking mindset.

The minute you start believing AI is going to replace you, you've already lost the plot.

The Self-Replacement Cycle I'm Seeing Everywhere

I spent way too much time on tech forums last month watching people have full-blown existential crises after playing with ChatGPT for an hour. These are the same folks posting things like "programming is dead" and "we'll all be looking for new careers within two years" while accumulating thousands of doomer upvotes.

Know what these geniuses did next? They signed up for a $20/month ChatGPT subscription and started SECRETLY USING IT TO DO THEIR ENTIRE FUCKING JOBS.

Let that sink in. These people are so convinced AI will replace them that they're PAYING MONEY to make it happen faster. They're literally outsourcing their thinking to an AI, then copying and pasting the results while collecting a paycheck.

The irony is so thick you could build a fucking bridge out of it.

The Two Types of Developers in the AI Age

I'm seeing a clear split forming in our industry:

The "I'm Fucked" crowd: These people are convinced they're obsolete. They're paralyzed by fear, watching AI demos and thinking "well, time to learn plumbing." They treat AI like it's their replacement rather than a tool.
The "This Is Just Another Tool" crowd: These people see AI for what it is—powerful, but just another tool in their arsenal. They're figuring out how to leverage it to eliminate boring parts of their work while enhancing their unique human skills.

Guess which group is ACTUALLY at risk of being replaced?

Here's the uncomfortable truth: if you can be replaced by an AI prompt, you were already replaceable. You just didn't know it yet.

The Technical Reality Check Everyone Needs

Let's cut through the bullshit and talk about what AI can and can't actually do right now:

What AI Can Do:

Write boilerplate code that follows clear patterns
Debug simple issues when given enough context
Generate content that sounds good but might be factually garbage
Summarize information it's been trained on
Make your shitty documentation slightly less shitty

What AI Can't Do:

Understand the true business need behind a technical requirement
Innovate genuinely novel solutions to complex problems
Write reliable, production-ready code for complex systems without human oversight
Have actual domain expertise (it just fakes it convincingly)
Know what the fuck it's actually talking about half the time

The biggest misconception I see is people thinking AI "understands" code. It doesn't. It's predicting what code should look like based on patterns it's seen. It's a super-powered autocomplete, not a replacement for understanding.

The Self-Replacement Trap

Here's where it gets really fucked up. The people most afraid of AI are often the ones actively training it to replace them. How?

When you:

Use AI to generate code you don't understand
Take AI's word as gospel without verifying
Let AI make key design decisions for you
Stop exercising your own problem-solving muscles

...you're literally practicing being replaced. You're training yourself to be the middleman between the AI and the computer. And middlemen are the first to get cut out.

It's like paying a guy to dig your own grave and then being surprised when someone pushes you in.

How NOT to Be Replaced by AI

So if you don't want to be replaced, here's what you need to do:

1. Understand what you're building at a deeper level than the AI

ChatGPT can write a React component. But does it understand why that component exists in your business context? Does it know your users' actual needs? Can it make judgment calls about tradeoffs specific to your situation?

No, but YOU can. This is your edge. Double down on it.

2. Master the things AI sucks at

System design across multiple domains: AI can help with individual components but struggles with big-picture architecture that spans different technical and business domains.
Explaining technical concepts to non-technical people: AI can generate explanations, but they're often generic and miss the specific angle needed for YOUR stakeholders.
Critical thinking about implementation details: AI will happily generate code that looks plausible but will fall over in production in subtle ways.
Human collaboration and negotiation: AI can't sit in a room with competing stakeholders and help negotiate a technical approach that balances everyone's needs.

3. Make AI YOUR bitch, not the other way around

The devs who will thrive aren't the ones running from AI—they're the ones getting exponentially more productive with it.

Use AI to:

Draft the boring parts of your code so you can focus on the interesting problems
Explore different approaches quickly before committing to one
Help you understand unfamiliar codebases or technologies
Generate test cases you might not have thought of

But always, ALWAYS maintain final judgment and ownership. The moment you abdicate understanding, you're volunteering for replacement.

The Mediocre Middle Is Where the Danger Lies

Let's be brutally honest: there's a large segment of our industry that:

Copies Stack Overflow without understanding the code
Implements requirements without questioning them
Has been getting by through pattern matching rather than deep understanding

These are the people who should be worried. Not because "AI is coming for their jobs," but because they've been doing replacement-level work all along. AI just makes it more obvious.

Think about it: if your entire contribution is implementing straightforward requirements in a predictable way, why wouldn't a company eventually cut you out?

The Counterintuitive Conclusion

Here's the mindfuck conclusion I've come to: the more afraid you are of AI replacing you, the more likely it is to happen.

Fear leads to:

Paralysis instead of adaptation
Resistance instead of leveraging
Outsourcing your thinking instead of enhancing it

Being "AI-proof" isn't about competing with AI at what it does well. That's a losing battle. It's about excelling at what AI CAN'T do—the creativity, judgment, human connection, and deep understanding that makes us uniquely valuable.

So if you're reading this and thinking, "Fuck, AI is going to take my job"—then yeah, it probably will.

But if you're thinking, "How can I use this to solve problems in ways that weren't possible before?"—then you'll be the one building and directing these AI systems, not being replaced by them.

The choice, as always, is yours. But stop being a whiny little bitch about it either way.

Choose wisely.

This post was originally published on yash.link. If you enjoyed this rant, check out more of my unfiltered thoughts on programming, technology, and the occasional existential crisis about building CPUs in TypeScript's type system.

Working > Perfect: How I Stopped Being a Perfectionist Developer

Yash Goswami — Sun, 23 Mar 2025 06:12:31 +0000

Ever spent hours perfecting code that was already working fine? You're not alone. This is the story of how I transformed from a perfectionist who blocked progress to a pragmatic developer who ships value. My journey wasn't easy, but the lessons changed not just my code, but my entire approach to software development.

I used to be the developer who'd spend three weeks refactoring a codebase nobody asked me to touch. The one who'd argue for hours about whether we should use camelCase or snake_case for database columns. The one who'd stay up until 4 AM fixing a bug that affected exactly zero users.

I was, in other words, a perfectionist dickhead.

The Symptoms of Developer Perfectionism

My code reviews were feared. I'd leave 50+ comments on a simple PR, mostly about spacing, variable names, or whether a function was "elegant" enough. My own PRs were massive refactors that touched 100+ files to "improve the architecture."

The symptoms were everywhere:

I'd rewrite working code repeatedly just to make it "cleaner"
I'd rabbit-hole on edge cases affecting a 0.001% of users
I'd oppose shipping any feature with known minor bugs
I'd use phrases like "this isn't production ready" about code that had been running in production for months
I was the bottleneck. The blocker. The "well, actually" guy.

The Breaking Point

It took two specific incidents to wake me up.

First, I spent an entire month rewriting a user authentication system that was "architecturally problematic" but had been working flawlessly for two years.

I was so proud of my elegant new solution with clean abstractions, perfect separation of concerns, and comprehensive test coverage.

One week after deployment, we rolled back to the old "problematic" system because my elegant solution couldn't handle our user load.

I'd sacrificed working for perfect, and ended up with neither.

Second, a junior dev shipped a feature in a day that I had been "designing" for three weeks. His code was messy. It had TODOs. It wasn't perfectly typed. It didn't follow all our conventions.

But you know what? It fucking worked. Users loved it. And while I was still drawing UML diagrams, he was shipping value.

The Realization: Working > Perfect

That's when it hit me: a working solution now is infinitely more valuable than a perfect solution someday.

Most of our sacred "best practices" aren't universal truths - they're just preferences wrapped in dogma.

The reality of software development isn't about writing perfect code; it's about delivering value to users.

Users don't give a shit about your elegant abstractions or your perfect file structure.

They care if your software solves their problems.

How I Changed

The change wasn't instant, but I started forcing myself to follow some new principles:

1. Embrace "Good Enough"

I adopted the 80/20 rule: get something to 80% quality with 20% of the effort, then ship it. If users actually care about the remaining 20% of edge cases, they'll let you know.

// Old me:
function processUser(user: User): Result {
  // 300 lines of code handling every possible edge case
  // including what happens during a solar eclipse
  // if the user is crossing the international date line
}

// New me:
function processUser(user: User): Result {
  if (!user) return { success: false };
  // 20 lines that handle the common cases
  // TODO: Handle edge cases if they ever become problems
  return result;
}

2. Fix It When It Breaks, Not Before

I stopped trying to anticipate every possible failure mode. Instead, I built monitoring, learned to write good error messages, and accepted that some problems only become clear in production.

I realized I was terrible at predicting which parts of the code would be problematic. The areas I obsessed over usually worked fine; the bugs came from places I never expected.

3. Let Go of Code Ownership

My code isn't my baby. It's just code. If someone wants to change it, great! That means I don't have to maintain it anymore.

I had to learn this one the hard way when someone completely rewrote a module (price management module in Delivery system) I'd spent months "perfecting." My first reaction was defensive anger. My second reaction was relief when I realized his solution was simpler and now he was the one who'd be maintaining it.

4. Allow Others to Succeed Their Way

Not everyone writes code like me, thinks like me, or approaches problems like me. And thank fuck for that.

I've learned more from reading "imperfect" code that solved problems in ways I wouldn't have considered than I ever learned from people who code exactly like me.

5. Deadlines Are Features, Not Bugs

I used to see deadlines as the enemy of quality. Now I see them as forcing functions for prioritization.

A deadline makes you ask: "What actually matters here?" Often, the answer is surprising. Those 12 refactorings I wanted to do? Turns out 11 of them didn't matter to users at all.

Has Quality Suffered?

Here's the thing that shocked me: when I stopped being a perfectionist, the overall quality of our product improved.

Why? Because we shipped more features. We fixed more actual bugs (instead of theoretical ones). We spent time on things users cared about instead of things I cared about.

Our error rates went down. User satisfaction went up. Development velocity increased.

Turns out "done and deployed" beats "perfect but still in PR review" every fucking time.

Sometimes Perfect Is Still Necessary

There are still areas where being meticulous matters enormously:

Security - One mistake can compromise everything
Data integrity - Losing or corrupting user data is unforgivable
Core infrastructure - The foundation needs to be solid
But even here, I've learned to focus my perfectionism narrowly on what actually matters rather than trying to make everything perfect.

The Hardest Lesson: Progress > Perfection

The hardest pill to swallow was that progress matters more than perfection. Continuous small improvements beat the grand redesign almost every time.

I used to think my perfectionism was a badge of honor - proof that I cared more than other developers. Now I recognize it was often just ego, fear of criticism, or avoidance of the messy reality of shipping software.

These days, my proudest moments aren't when I write perfect code. They're when I deliver something that makes users' lives better, even if the implementation makes me wince a little.

Because in the end, working beats perfect. Every. Single. Time.