There's a verse from the Bhagavad Gita that's been rattling around in my head since a senior engineer quoted it to me during a particularly brutal sprint retro:
"You have a right to your work, but never to the fruits of your work." — Bhagavad Gita 2.47
I nodded politely at the time and went back to obsessing over whether our feature launch would hit its adoption targets. It took another six months of burnout-adjacent behavior before that verse actually landed.
Here's the thing nobody tells junior developers: the code is the easy part. The part that actually wrecks people is staying emotionally hostage to what happens after the code ships.
The Deploy That Broke Something in Me (Not the Server)
A few years back, I spent three weeks building a recommendation engine I was genuinely proud of. Clean architecture, solid test coverage, actually clever caching logic. It shipped on a Thursday. By the following Monday, product had pivoted the entire feature direction, and my carefully built engine got quietly archived.
Nobody was cruel about it. Nobody even really acknowledged it happened. The business moved on, as businesses do.
I didn't move on nearly as fast. I spent weeks low-key resentful, treating the archived feature like proof that my effort didn't matter. Looking back, that reaction says a lot more about where I was placing my sense of worth than it does about the actual situation.
Where Developers Quietly Outsource Their Self-Worth
We don't usually notice we're doing this until it hurts. A few places it sneaks in:
- PR approval speed — treating a fast, glowing review as validation and a slow, critical one as a verdict on your competence
- Feature adoption numbers — measuring your engineering skill by a metric that's actually controlled by marketing, pricing, and timing
- Sprint velocity — turning a planning estimate into a referendum on your worth as a developer
- Production incidents — spiraling into "I'm a bad engineer" after a bug that three other people also missed in review
None of these things are meaningless. They're just not supposed to carry the entire weight of your self-worth, and somewhere along the way, a lot of us let them.
What makes this especially sneaky in software is how quantifiable everything is. Most professions don't hand you a dashboard tracking your worth in real time. We do. Story points burn down. PR merge counts show up on your GitHub profile like a public scoreboard. Sentry alerts ping the moment something you touched breaks. It's not that developers are uniquely insecure — it's that our entire toolchain is basically engineered to make outcome-attachment the path of least resistance.
The Burnout Pattern Nobody Names Correctly
Most burnout conversations in tech focus on hours worked, which is real, but it's only half the story. The other half is this exact fusion — effort and outcome collapsed into one thing, so that every dip in a metric feels like a personal verdict rather than one data point among thousands of variables.
I've watched genuinely talented engineers spiral after a single bad quarter of OKRs, not because their code got worse, but because they'd quietly wired their entire sense of competence to a number a product manager set based on a market forecast they had zero input into. The burnout wasn't really about workload. It was about carrying weight that was never supposed to be theirs to carry.
What "Do the Work, Release the Result" Actually Means on a Sprint Board
This isn't a call to stop caring about outcomes. Krishna isn't telling Arjuna to phone it in. He's drawing a line between two things that get fused together by default: the effort you put in, and the results that follow it, which depend on a hundred variables you don't control.
Translated into a standup:
- Write the cleanest code you're capable of — that part is fully yours
- Think through the edge cases, write the tests, document the weird parts — also fully yours
- Whether leadership funds the next phase, whether users adopt it, whether a reorg shelves the whole project — none of that is yours, no matter how good the code was
Separating those two categories doesn't lower your standards. If anything, it raises them, because you're no longer performing quality for an audience. You're doing it because that's the actual job in front of you.
There's a practical side effect here too: engineers who've actually internalized this tend to write better code review comments, not worse ones. When your ego isn't riding on being right, you can say "I think this approach has a problem" without it turning into a status contest. The detachment doesn't make you a less rigorous engineer. It makes you a less defensive one, which, in most codebases, is the far bigger productivity unlock.
The Uncomfortable Lesson AI Keeps Teaching Me
Watching a language model generate a response is a weirdly good case study in this. It processes the input, produces its best output given what it has, and then it's done. No sulking if the response gets discarded. No anxiety about whether the user liked it. No checking back later to see if the output "performed well."
I'm not suggesting developers should aim to feel nothing about their work — that would just be a different kind of broken. But there's something worth noticing in a system that does the task fully, then genuinely lets go of what happens next, instead of the task and the outcome getting tangled into one anxious knot.
A Few Real Scenarios Worth Sitting With
- You caught a subtle race condition in review that would've caused a nasty production bug. Nobody throws a parade for bugs that never happened. Doesn't matter. That's real engineering, seen or not.
- You wrote a migration script that ran flawlessly at 3 AM with zero downtime. If it goes unnoticed because nothing broke, that silence is the actual reward, even if it doesn't feel like one.
- You pushed back on a rushed deadline and got overruled anyway. You did the responsible thing. What leadership decides to do with that input isn't a reflection of whether you were right.
In each case, the work was complete and sound. What happened next belonged to forces way outside any single developer's hands.
You mentored a junior dev through a hard concept over three pairing sessions, and they left the company two months later for a better offer. The mentoring still happened. The growth still landed somewhere, even if it wasn't visible on your team's roadmap anymore.
Notice the pattern across all of these: the quality of the effort and the shape of the outcome are almost completely uncorrelated. Good work sometimes gets buried. Mediocre work sometimes gets lucky timing and looks brilliant in retrospect. Tying your sense of competence to outcomes means your self-assessment is basically riding on noise.
Practices That Actually Help (Not Just Sound Nice)
- Write a one-line "why" before every PR, separate from the ticket description — a personal note on why this work mattered to you, independent of how it gets received
- Close your laptop after merging, instead of refreshing the deployment dashboard every ten minutes waiting for validation
- Keep a private log of hard problems you solved well, regardless of whether anyone else noticed — this becomes your actual record, not the org's recognition system
- When a project gets shelved, write down what you learned technically, then let the emotional attachment go with the project itself
- Separate "this didn't ship" from "I failed" — most cancelled projects die from business reasons that have nothing to do with code quality
None of these fix the industry's obsession with metrics and outcomes. They just stop you from quietly absorbing that obsession as your personal identity.
The Actual Takeaway
The Gita's line isn't really about being spiritual at your desk. It's a pretty blunt piece of risk management for your own mental health: stop investing your peace of mind in things a pull request approval, a stakeholder's mood, or a company's quarterly priorities can yank away from you at any moment.
Do the work well. Ship it with care. Then let it go, the way you'd let go of a package once it's actually out for delivery — not because you stopped caring what happens to it, but because obsessively tracking it doesn't change where it ends up.
Your commit history is the proof of your effort. What the business decides to do with that effort was never fully yours to control in the first place — and once that actually sinks in, it gets a lot easier to keep shipping good work without it quietly wearing you down.
Top comments (0)