How to Tell If You’re Actually Growing as a Developer

Staying busy and actually growing are not the same thing, and it's surprisingly easy to confuse them.

You're shipping work. You're learning things. You're getting better at the tools you already use. It all feels like progress. But there's a difference between getting faster at familiar problems and developing the kind of judgment that changes what you're capable of. One keeps you employed. The other moves your career.

Here's how to tell which one is actually happening.

1. You handle ambiguity without freezing

Early in your career, unclear requirements feel like a blocker. You want precise specs, exact steps, someone to tell you what done looks like. That's not a character flaw, it's just where the skill level is. You don't yet have enough context to fill in the gaps yourself.

As you grow, ambiguity becomes less threatening. You might still dislike it, but you can move through it. You ask better questions to narrow the scope. You make reasonable assumptions and document them. You start something instead of waiting for perfect clarity that was never coming anyway.

That's not confidence in the motivational-poster sense. It's experience accumulating into a functional ability to operate under uncertainty. If you're unblocking yourself in situations that would have stopped you cold two years ago, that's real.

2. You're solving problems beyond the ticket

Early growth looks like completing tasks. You get the work, you do the work, you close the ticket. That's exactly what's expected and there's nothing wrong with it.

Later growth looks different. You start noticing the thing adjacent to the ticket. The pattern that's going to cause the same bug three more times. The assumption baked into the design that's going to be painful to unwind later. The edge case nobody put in the acceptance criteria but that's definitely going to happen in production.

You're not just responding to work anymore. You're shaping it. That shift is one of the clearest signals that your thinking has matured, and it's the kind of thing that makes senior engineers visibly more valuable than junior ones doing the same nominal work.

3. Your discomfort has changed shape

Growth doesn't eliminate discomfort. It changes what you're uncomfortable about.

Early discomfort is about not knowing things: not understanding the codebase, not knowing what to do next, not being sure your solution is right. That's normal and it fades with time.

Later discomfort is different. You feel stretched rather than lost. You're uncomfortable because the problem is genuinely hard, not because you lack the fundamentals to approach it. You're uneasy about a decision because you can see the tradeoffs clearly, not because you can't see them at all.

If the nature of your discomfort has shifted from "I don't know enough" to "this is actually complex," you're operating at a higher level than you were. It won't feel that way in the moment, but it's worth noticing.

4. Your feedback has shifted

Pay attention to what people push back on in code reviews and conversations. The nature of that feedback is one of the clearest external signals of where you actually are.

Early feedback is about correctness: syntax, style, whether the thing works, whether you handled the obvious cases. That's the baseline. As you grow, the feedback shifts. People stop questioning whether it works and start questioning whether it's the right approach. They push on tradeoffs, on long-term maintainability, on whether this decision will make future work easier or harder.

Getting feedback about approach and impact instead of syntax and style isn't more critical. It's more advanced. It means the people reviewing your work have stopped worrying about the basics and started treating you as someone who can engage with harder questions. If your reviews feel more like architectural conversations than correction sessions, that's a promotion in disguise.

5. You need less direction because you think better, not just because you know more

There's a version of needing less direction that's just familiarity. You've been at the company long enough to know the codebase, you've solved similar problems before, and you know who to ask. That's useful, but it's not growth; it's tenure.

Real growth looks different. You're asking fewer "what should I do" questions and more "does this approach make sense" questions. You can explain the trade-offs in a decision rather than just the solution. You're reasoning about the system, not just navigating it.

The distinction matters because familiarity with one codebase doesn't transfer. Better thinking does. If you'd be able to get up to speed faster at a new company than you could two years ago, not just because you know more syntax but because you think about problems differently, that's the kind of growth that compounds.

6. You're more honest about what you don't know

Counterintuitively, one of the clearest signs of growth is getting less certain about things, not more.

Early-career confidence tends to be loud because it's built on incomplete information. You don't yet know what you don't know, so everything feels more manageable than it is. As your mental model of how systems actually behave becomes more accurate, you start to see complexity that wasn't visible before. You hedge more carefully. You say "I need to think about that" more often. You're less likely to give a confident answer off the top of your head.

From the outside, that can look like insecurity. It isn't. It's calibration. The engineers who stay overconfident as they gain experience are the ones who create expensive surprises. Those who develop a healthy respect for complexity tend to make better calls over time and earn more trust as a result.

The Close

The honest version of this question, am I actually growing or just staying busy, is worth asking regularly. Not to torture yourself, but because the answer changes what you should do next.

If you're growing, keep going. The discomfort is the point.

If you're staying busy without making progress, that's worth knowing, too. It usually means you've optimized for comfort without realizing it, and the fix is deliberately taking on work that exposes you to new kinds of problems rather than faster versions of old ones.

Either way, knowing where you are is better than assuming.

Good Developer. Stuck Career. is for engineers doing good work who can't figure out why it isn't translating into momentum. If you're asking the question this post is asking, that's probably the right next read.