Stuck in Your Software Engineering Career? The Honest Diagnosis

Stuck rarely looks dramatic. It looks like showing up every day, doing solid work, collecting a "meets expectations" review for the third year running, and watching someone two years behind you get the senior title first. It looks like being the person everyone pings when the deploy breaks at 2am and never being in the room when promotion decisions actually get made. One engineer on Hacker News described it this way: technically a senior engineer, but still operating the way they did as a junior, executing tickets instead of setting direction. Another software developer, ten years into the job, wrote something close to: senior for a decade, and nobody has ever explained what staff would even require.

Some of you survived a round of layoffs and came out the other side relieved, only to realize six months later that surviving and advancing are not the same thing. You kept your job. Your career stayed exactly where it was. And some of you are the strongest engineer on the team, the one everyone quietly relies on, which is precisely the trap, because being the go-to person and being the promoted person turn out to be two different things, and almost nobody tells you that until you ask directly.

The diagnosis I give almost every engineer who comes to me feeling stuck is the same one, and it surprises most of them: you are not behind on technical skill. In years of coaching, the engineers who feel stuck are rarely the weakest coders on the team. Often they're the strongest. What's usually missing is a plan, plus visibility to the people who actually decide what happens to your career. Ability was rarely the problem to begin with.

You're also not alone, and there's real data behind that. A Glassdoor survey of 3,400 professionals, published in October 2024, found that 73% of tech workers report feeling stuck in their current roles. These are people who kept their jobs and kept meeting expectations, and still felt stuck. That number matters because it reframes the whole problem. This is a structural pattern in how career growth works in tech, and most engineers run into it somewhere along the way. It has very little to do with individual effort.

Think about what actually gets you promoted at most companies. It's rarely "did great technical work quietly." It's closer to "did great technical work that the right five people know about, at the right time, framed the right way." Nobody teaches you that in a CS program. Nobody puts it in the onboarding docs. You're expected to pick it up by watching who gets promoted around you, which is a slow, unreliable way to learn a skill that shapes your income for the next decade.

Three patterns show up over and over, and they compound.

The first is the go-to-person trap. You become so reliable at your current level that leaving it feels risky, both to you and to your manager. You're the one who understands the legacy billing system. You're the one who gets pulled into every incident call. That reliability is real value, but it's value at your current level, not evidence you're ready for the next one. Managers have a quiet incentive to keep their best senior engineer exactly where they are, since promoting you means losing the person who makes their own job easiest. Nobody says this out loud. It shows up anyway, in delayed promotion conversations and vague feedback like "not quite yet, keep doing what you're doing."

The second is that promotion processes reward visibility over raw output. Getting to staff engineer or principal is mostly about scope, cross-team influence, and the system design decisions other people can point to and credit you for, not about writing more code. Our guide on how to become a staff engineer goes deep on what that scope shift looks like in practice, but the short version holds: the work has to be visible outside your immediate team, and most engineers never build that visibility on purpose.

The third is manager churn, and it's the one nobody warns you about. I've talked to engineers with consistently strong performance ratings who went through five different managers in four years, and every new manager restarted the promotion conversation from zero. Nobody had context on the case already built. Nobody remembered the project from eighteen months ago that proved readiness. Career progress ended up depending on a person who might leave the company before the next review cycle, which is a rough position to be in no matter how good the work is.

These three patterns rarely show up alone. A go-to-person who's also good at their job but invisible outside the team, working under a manager who rotates out every year, is a near-perfect setup for staying at the same level for a very long time. None of it requires anyone acting in bad faith. It's just how the incentives line up when nobody is deliberately managing them on your behalf.

The first honest path is staying where you are and getting promoted, but doing it deliberately instead of hoping someone eventually notices. This works when your company genuinely has a track to the next level, even a slow one, and when you haven't already burned trust with leadership.

Start by getting specific about what "ready" means at your company. Talk to your manager directly about what staff engineer looks like there and what's missing from your case right now, then write the answer down. Most engineers never ask this question directly and guess instead, which wastes years. Build toward the answer on purpose. Decide whether you want to stay an IC or move toward management, then take responsibility for the cross-team project nobody wants because it's messy and political, since that's exactly the kind of work that builds the influence promotion committees look for. Document your impact in terms leadership actually cares about, not just what you shipped. Our piece on how to get promoted as a software engineer walks through the specific mechanics of building that case.

If you've tried this alone for a year and gone nowhere, a software engineer career coach earns its cost here specifically because they see the blind spots you can't. They've watched hundreds of promotion cases succeed and fail, and they usually know within one conversation whether the problem is scope, communication, or a manager who was never going to advocate for you regardless of what you did.

Put a rough timeline on this path before you start. Give it two full review cycles with clear, written milestones after your "what's missing" conversation. If you hit those milestones and still don't move, that's real information, not a reason to keep grinding for another year on faith. Treat the internal path like an experiment with an end date, not an open-ended commitment. For the tactical week-by-week version of that experiment, our guide on overcoming career stagnation as a software developer lays out the plan.

The second path is the one most engineers reach for first: leave, and negotiate a title and level bump into the new offer. Sometimes that's the right call. And sometimes you don't need to leave the company at all. You can switch teams internally and reset the story with a manager who has no history with you. It tends to work fastest when your current company has a genuine ceiling, when the internal promotion process is political in a way you can't fix, or when you've already had the "what's missing" conversation and the answer was vague or dishonest.

The math is straightforward. You often get paid market rate as a new senior or staff hire, because companies are more willing to approve that than to promote someone internally to that level, purely because of how compensation bands and budget approvals work. An external move can compress two years of internal grinding into one negotiation. The risk is that a level jump on paper doesn't always match a level jump in ability, and landing at a company where you're in over your head can set you back further than staying put. Before you jump, get honest with yourself about whether you actually have staff-level experience or just staff-level frustration. Our overview of the software engineer career path is a useful gut check for where you actually stand before you start interviewing at the next level up.

The third path is the one almost nobody tells stuck engineers about, and it's the one I'd bet on if I were starting over today. Instead of waiting to be noticed internally, or gambling everything on a single external interview loop, you build a reputation outside your company so opportunities start finding you instead of the other way around.

This matters more now than it did five years ago, and the reason is straightforward. AI has made writing code faster and, in a lot of cases, cheaper. That's already changing what companies pay for. When raw coding output gets commoditized, the engineers who keep landing the best offers, the best projects, and the fastest promotions are the ones people already know by name. Not famous, just known, in a specific niche, by the people who make hiring and promotion decisions.

The mechanism is simple, even though it takes a mindset shift and consistency to work. Publish something. A technical write-up on a problem you actually solved. A talk at a local meetup. A well-maintained open-source contribution. An honest post about a mistake you made and what fixing it taught you. You don't need to become an influencer or post every day for this to work. Being findable and specific about what you're known for is enough. When a recruiter or a hiring manager searches for "senior engineer, distributed systems, fintech," you want your name to be one they've already come across somewhere.

I built my own career this way. Simple Programmer started as a blog nobody read for the first year. It eventually led to a business generating millions in revenue, and more relevant to you, it meant opportunities started arriving before I went looking for them. Building a reputation gets you a name that opens the door before you've even applied, and that's worth more over a full career than any single negotiation.

Getting started here doesn't require a grand plan. Specialize. Pick one thing you actually know well, an area of expertise narrow enough that you could explain it in one sentence at a meetup. Write it up once. Post it somewhere people in that niche actually look, whether that's a company engineering blog, a personal site, or a focused LinkedIn post instead of a generic one. Do it again the next month. Ninety days of that, done consistently, does more for how findable you are than a resume rewrite ever will, because a resume only works when someone already has a reason to read it.

Waiting another year and hoping things change on their own is the most common mistake, and the most expensive one, because "another year" has a way of turning into three or four before you look up. If nothing about your situation has changed, waiting longer won't change the outcome either.

Silently grinding harder is the second mistake. Working more hours or taking on more tickets without changing the visibility problem just leaves you more exhausted at the same level. It feels like progress simply because you're tired. Exhaustion and advancement are different things, and only one of them helps your career.

Rage-quitting without a plan is the third. Leaving out of frustration, with no target role, no updated resume, and no real sense of what comes next, tends to land you somewhere different but not better. A bad exit is still a decision, so make it on purpose.

These are the questions I hear most from engineers working through exactly this situation.

Is it normal to feel stuck as a software engineer?

Yes, and it's far more common than most engineers realize. A Glassdoor survey of 3,400 professionals, published in October 2024, found that 73% of tech workers report feeling stuck in their current roles, even while employed and performing well. Feeling stuck is a signal about your plan and your visibility, not a verdict on your ability.

How long is too long to go without a promotion?

There's no universal number, but two full review cycles without a clear, specific explanation of what's missing from your case is a reasonable point to get concerned. If your manager can't answer "what exactly is standing between me and the next level" with specifics, that's the real warning sign, regardless of how many years have passed.

Should I switch companies to get promoted faster?

Sometimes, and it depends on why you're stuck. If your current company has a genuine ceiling, a political promotion process you can't fix, or a manager who's given you vague, non-actionable feedback more than once, leaving for a level jump often moves faster than waiting internally. If you haven't yet asked directly what's missing from your case, do that first. Leaving without that conversation means you never find out whether the internal path was actually blocked.

Is software engineering worth staying in if I feel stuck?

Feeling stuck is a career-strategy problem, not evidence the field itself is wrong for you. The engineers who leave the profession over stagnation and the engineers who fix the same stagnation through a deliberate plan usually had the same underlying skill level. The difference was strategy, not aptitude. Diagnose the actual cause before deciding the field is the problem.

What's the fastest way to get unstuck as a software engineer?

Start with a direct conversation: ask your manager exactly what's missing from your case for the next level, and get a specific answer in writing or in notes. From there, pick a path deliberately, whether that's building visibility internally, interviewing externally for a level jump, or building a public reputation so opportunities start coming to you. The fastest results come from picking one path and working it consistently, not from trying all three at once.

Is feeling stuck the same as being bad at my job?

No. In coaching engineers through this exact situation, the ones who feel stuck are frequently the strongest performers on their team, not the weakest. Being reliable and being promoted are different things, and companies rarely explain that distinction unless you ask directly.

Every engineer I've coached out of feeling stuck went through the same sequence. They got honest about their current role, picked which of the three paths they were actually on, stopped waiting for permission, and started doing something visible, whether that meant building a promotion case, interviewing externally, or publishing their work. None of them got unstuck by working harder in silence. That approach has never had much of a track record.

If path three resonates, the free Rockstar Engineer Blueprint is a 5-day email course that walks through exactly how to become the developer your industry already knows by name, so the best jobs, raises, and offers come to you instead of the other way around. It covers the five mistakes that keep good engineers invisible, and how to avoid every one of them.

You've already put in years building technical skill nobody questions. The plateau you're feeling is solvable, and it starts with picking one of the three paths above and actually working it.