The Addiction of Being Essential: A Programmer’s Wake-Up Call
How My Need to Be Needed Nearly Burned Me Out and What I’m Doing About It
You know what’s been eating at me lately? This whole thing about needing to be everywhere, know everything, and somehow become the person everyone turns to when stuff hits hard. I’ve been coding for years now, and somewhere along the way, I picked up this habit that’s honestly getting out of hand.
It started small, like most things do. Someone would ask me to look at their code, and I’d check, suggest and fix it. Then another person would ping me about a deployment issue, and I’d sort that out too. Pretty soon, I became the go-to person for anything remotely technical in the office. Sounds great, right? Well, not really.
The problem is, I got hooked on being needed. There’s this rush you get when someone says, “Hey, can you jump on this call?” or “We really need your input on this.” Before I knew it, I was inserting myself into every project discussion, every technical meeting, every decision that remotely touched code. I told myself it was because I cared about quality, about making sure things were done right. But if I’m being honest, it was more about feeding this need to be indispensable.
Here’s the thing about programming, it’s not supposed to be a one-person show. Yet somehow, I’ve managed to create this situation where people expect me to be involved in everything. Production failures? They call me. Development issues? My teams buzzes.
I remember when I first started coding, I was just happy to write functions that worked. Now I’m sitting in meetings about projects I’m not even assigned to, just because I convinced myself that my perspective was crucial. The irony is, I probably am better than most people at this company when it comes to technical stuff. But that doesn’t mean I need to prove it every single day.
This whole dynamic has created something weird in my brain. I wake up thinking about what discussions I might miss if I’m not checking teams every ten minutes. I feel this anxiety when I see a thread I wasn’t tagged in, wondering if they’re making decisions without me. It’s ridiculous when I actually think about it. I mean, companies existed before I got here, and they’ll exist after I leave. Yet somehow I’ve convinced myself that everything will fall apart without my constant input.
The worst part is how this affects my actual coding. You know, the thing I’m supposed to be good at? I’ll be deep in a complex problem, really getting into the flow, when suddenly there’s another meeting I “should” attend. Another architectural discussion where my opinion is “valuable.” Another junior developer who needs guidance. Don’t get me wrong, mentoring is important, and being involved in architecture decisions matters. But when you’re doing it because you can’t stand the idea of not being involved, that’s when it becomes a problem.
I’ve started to notice this pattern in other developers too. The ones who seem to have their fingers in every pie, who always have an opinion about every technical decision, who somehow manage to be essential to every project. At first, I admired them. Now I’m wondering if they’re dealing with the same thing as I am, this compulsive needs to be needed.
What’s really getting to me is how this impacts the team. When you’re always the person with the answer, other people stop thinking for themselves. They start coming to you for things they could figure out on their own. You become a bottleneck without even realizing it. And then you complain about being overwhelmed while simultaneously making it impossible for anyone else to step up.
I’ve been trying to trace back when this started. Maybe it was when I got a remark on final review and suddenly felt like I had to prove something. Or maybe it was when I fixed that critical issue (sev 1) that saved the big issue from reoccurring, and everyone treated me like a hero for a week. There’s definitely something addictive about being the person who saves the day.
But here’s what I’m starting to realize that this behavior isn’t sustainable. I’m burning out, and I’m not even working on the most interesting problems anymore. Instead, I’m spreading myself thin across dozens of different issues, never really diving deep into any of them. My GitHub contributions look impressive, but most of them are small fixes, quick patches, or some document updates rather than meaningful features.
The other day, I tried an experiment. I deliberately didn’t check teams for three hours while I worked on a reading research paper. The anxiety was real. I kept thinking about all the discussions happening without me, all the decisions being made that I wasn’t part of. But you know what? Nothing fell apart. The world kept spinning. People figured things out on their own.
This whole situation has made me think about what I actually want from my career. Do I want to be the person who knows everything about everything, or do I want to be someone who can solve really hard problems? Do I want to be in every meeting, or do I want to build something that matters? The answer seems obvious, but changing these patterns is harder than it sounds.
I think part of the problem is that being essential feels like job security. If everyone depends on you, they can’t fire you, right? But that’s not really true. What actually happens is you become a single point of failure, and companies don’t like those. They want resilient teams, not irreplaceable individuals.
So I’m trying something different now. I’m picking my battles. I’m saying no to meetings that don’t directly impact my work. I’m letting other people solve problems they’re capable of solving. And honestly, it’s terrifying. But it’s also liberating. I’m starting to remember why I got into programming in the first place, not to be the center of attention, but to build things that work.
The industry is full of people who think they need to be involved in everything. But maybe the real skill is knowing when to step back, when to let others lead, and when to focus on what you’re actually supposed to be doing. Things are getting ridiculous, but maybe that’s exactly what needed to happen for me to realize it.



I feel this, as I know I’ve jumped into projects just so I can continue to be the go to person for a particular service. I can also think of two engineers that get treated as the “have you ran that thought by X person”. One thing that help me and others I work with came from S3s Principal Engineer role framework blog post. It allowed people to identify their “role” for a project or set of projects which helped modulate their involvement. It also defines that some roles can only leave the engineer with time for 1-2 projects, which I found helped relieved some of the anxiety. I hope the framework helps you as well: https://www.linkedin.com/pulse/principal-engineer-roles-framework-mai-lan-tomsen-bukovec-142df?utm_source=share&utm_medium=member_ios&utm_campaign=share_via
All the best with the shift, hope you get to solve all the hard problems you wish to!