The Career Advice I Needed as a Developer but Never Got

Early in my career, advice was everywhere. Learn more. Move faster. Say yes. Make yourself indispensable. None of it was wrong, exactly. But almost all of it was optimized for one thing: survival.

Survival advice gets you through the first few years. It helps you earn trust, stay employed, and not embarrass yourself too badly. What it doesn't do is tell you how to actually grow. And there's a point, somewhere around year three or four, where survival mode stops being a strategy and starts being a ceiling.

These are the things I wish someone had told me before I hit mine.

Working Hard Is Not the Same as Growing

For most of my early career, I operated on a simple assumption: if I worked hard enough, the rest would take care of itself. So I did. I took on extra work, fixed things quickly, made myself useful. For a while it created real momentum.

Then it created a ceiling.

Hard work earns trust. That's genuinely valuable and I'm not dismissing it. But trust is not the same as growth, and output is not the same as judgment. At some point the thing that got you here stops being the thing that gets you further. The transition is gradual and nobody announces it, which means a lot of engineers spend years working harder at something that stopped compounding a long time ago.

Growth happens when your judgment improves, not just your throughput. Nobody told me that early on, and it would have saved me a few years of spinning.

Busyness Can Hide the Wrong Problems

Staying busy feels like forward motion. It also makes it very easy to avoid asking the questions that actually matter.

I was constantly active in my early career. Full calendar, full backlog, always something to fix or build or respond to. It felt productive. In retrospect, what it actually was was comfortable. Busyness kept me from noticing that I was solving the same kinds of problems over and over, getting faster at them but not broader.

The questions worth asking are uncomfortable ones: Am I being trusted with decisions I wasn't trusted with a year ago? Am I solving new kinds of problems or just more of the same ones? Is the work I'm doing changing what I'm capable of, or just keeping me occupied?

Staying busy is easy. Staying honest about whether the busyness is actually moving you forward is harder.

Learning Without Direction Is Not a Strategy

I was told to always be learning, so I was. New languages, new frameworks, new tools. I stayed current, picked up things before I needed them, and felt good about keeping pace with the industry.

What nobody told me was that learning needs context to matter.

A lot of what I absorbed early on had no real application. It made me feel productive without making me more capable in any way that translated to outcomes. The learning that actually moved things forward looked different: it came from following a problem all the way through its consequences, from understanding why a decision existed before trying to improve it, from finishing things carefully enough to see what worked and what didn't.

Starting new things feels like learning. Finishing things thoughtfully actually is.

Visibility Is Not the Same as Ego

This one took me the longest to internalize.

I assumed good work would speak for itself. Talking about what I was building or improving felt self-promotional, and self-promotion felt gross, so I kept quiet and figured the results would do the talking.

They didn't, not reliably anyway.

Silence doesn't signal humility. It signals absence. If the people making decisions about your career can't see your growth, they can't factor it in. Sharing what you're working on, asking questions that show how your thinking is developing, framing the impact of what you shipped — none of that is ego. It's just making your work legible to the people who need to see it.

The engineers who get overlooked aren't always the ones doing the least. They're often the ones who never learned to make their contributions visible.

Progress Feels Slower Right Before It Accelerates

Nobody warned me about this one, and it's the one I wish they had.

As you actually get better at the job, things start feeling harder, not easier. Decisions take longer because you can see more of the tradeoffs. Problems feel heavier because you understand the consequences. The confidence you had as a junior engineer, when you didn't know enough to know what you didn't know, quietly disappears.

It feels like regression. It isn't.

It's the shift from execution to judgment. From being fast to being right. From answering questions to asking better ones. That phase is uncomfortable because it's stretching parts of you that never got exercised before. The engineers who push through it come out the other side with something that doesn't expire. The ones who interpret the discomfort as failure often retreat back to what felt safe.

If things feel harder than they used to, that's worth paying attention to. It might mean you're further along than you think.

The Close

Most developer careers don't stall because people stop trying. They stall because people keep doing what worked early, long after it stopped helping. The habits that got you through the first few years, working hard, staying busy, learning broadly, and keeping your head down, are genuinely useful right up until they aren't.

The shift is subtle, and it doesn't announce itself. You just notice one day that the momentum you used to have isn't there anymore, and you can't figure out why because you're still doing everything you were doing before.

That's usually the signal. Not that something is wrong with you. That something needs to change in how you're approaching the work.

Good Developer. Stuck Career. is for engineers doing good work but can't figure out why it's not translating into momentum. If this post resonated, that's probably the right next read.