From Junior to Senior Developer 🚀: Navigating the Fog in Between

In the early days of my career as a developer, I believed that senior developers were simply those who excelled at writing a lot of code. I thought that the more code you wrote, the more you would start to own systems and leave your mark (visible through Gitlens, of course 😎), eventually becoming one of the elites. However, I didn't realize that I needed to move beyond coding as the ultimate goal and start focusing on problem-solving as the real work. Writing code became second nature to me, and my time began to be utilised by others for discussions like "How should I start coding this feature?" or "Is there a way to optimize this component?"

The Early Years: Clear Roads and Visible Progress

As a junior developer, or during your initial 1-3 years, expectations are simple and clear:

• Write working code ⌨️
  • Finish tickets. Fix bugs. Ship features. Make things work. Success is measured by whether the feature functions as expected, tests pass, and bugs are resolved. You’re encouraged to focus on correctness, learning how systems fit together without being burdened by long-term consequences just yet.
• Follow patterns 🧩
  • In majority of the cases - you are expected to follow what was asked of you without asking for your opinion. This isn’t about limiting creativity—it’s about learning consistency. By working within predefined structures, you absorb best practices implicitly and reduce the risk of introducing instability into the system.
• Ask questions 🙋🏻
  • You’ll often hear advice like “ask smart questions”. But early on, it’s more important to ask questions—period. Ask about anything you don’t understand, and don’t be discouraged if the first answer you get isn’t helpful or motivating. Over time, you’ll find the right people, the right context, or the right resources. Curiosity is encouraged, and uncertainty is expected. You’re given space to clarify, explore, and learn without the pressure of having all the answers.
• Improve your fundamentals 👀
  • The early phase is heavily focused on strengthening core skills: language basics, frameworks, debugging, and tooling. Month by month, things that once felt confusing start to feel intuitive, reinforcing a strong and motivating sense of progress.

Feedback is concrete.

Mistakes are expected.

Growth is visible and measurable.

You can feel yourself improving 📈—and others can see it too.

Where the Fog Begins 🧐

The confusion would rather start very silently. You won’t be treated like a junior and won’t be called a senior either 🤷🏻‍♂️. On the surface things would look fine and would be going fine like —- you’ll be shipping code faster, you’ll be closing tickets faster and contributions would look significant but, something would still feel off.

First big hit might come to you when the yearly promotion would not be as you expected it. You’ll realise bigger decisions are being made without you. Feedback also comes in a vague tone: “Take more ownership”, “Think bigger”, “Show more impact”

You start asking yourself uncomfortable questions:

• What am I missing?
• Why does growth feel harder now?
• Am I falling behind?

The truth is that the rules have changed—but no one announces it.

Output vs Judgment 🌨️

The truth is simple, but rarely stated explicitly: the rules have changed indeed.

At junior levels, growth is measured by output.

You’re rewarded for writing code, completing tasks, and following direction.

At senior levels, growth is measured by judgment.

How you make decisions when things aren’t clearly defined matters more than how fast you execute.

That transition—from output to judgment—is where most engineers feel lost.

A Clarifying Truth 🌄

But this phase isn’t about working harder.

It’s about learning to operate without a map.

You’re being tested on how you handle uncertainty, not how many tickets you close. And that’s uncomfortable—especially if your entire career so far has rewarded clear instructions and measurable output.

That’s why the road feels foggy.

Not because you’re doing something wrong—

but because you’re being asked to grow in a way that’s harder to see.

Accept this ambiguity - Feel proud of what you have accomplished - and Be ready to surpass it

---

Navigating the Fog: What Holds Engineers Back—and What Actually Helps

Most engineers don’t get stuck because they lack skill.

They get stuck because breaking this monotony is not easy. You’ll feel overwhelmed by others and would think that they know better or might be doing better than you. But, remember this is a phase and it will pass.

In the foggy phase, some common traps that might make it harder:

Chasing more tickets instead of taking ownership 🏃🏻

It’s easy to stay busy by closing tickets back-to-back. On the surface, it looks productive. But senior growth isn’t about how many tasks you complete—it’s about how much responsibility you own.

For example, finishing five small tickets feels good, but owning a single feature end-to-end—clarifying requirements, coordinating with others, handling edge cases, and supporting it post-release—creates far more trust. Ownership means caring about what happens after the code is merged, not just before.

Avoiding ambiguity instead of leaning into it and accepting it. This means you might be overthinking. 😒

Ambiguity can feel uncomfortable, especially when you’re used to clear instructions. Many engineers respond by overthinking, delaying decisions, or waiting for more clarity to arrive.

In reality, senior engineers are expected to operate inside uncertainty. When requirements are unclear or incomplete, the expectation isn’t to freeze—it’s to ask better questions, propose assumptions, and move things forward. Leaning into ambiguity doesn’t mean guessing wildly. It means being comfortable saying:

• “Based on what we know so far, here’s what I suggest.”
• “I’ve seen this approach work in a similar situation—could we try a small experiment?”
• “I came across a data-backed approach to improving performance using atomic design and TypeScript. I put together a small POC—happy to walk through it.”

This is how senior engineers create momentum.

Not by having perfect information—but by helping the team make progress despite imperfect information.

Your questions and opinions should shed light to a path - doesn’t matter if it is one step at a time.

Waiting to be told what to do instead of proactively clarifying 😏

Some engineers hesitate to speak up because they assume they should already know the answer—or fear asking what they think might be a “stupid question.” Others assume silence means agreement.

This often leads to misalignment. Senior engineers reduce confusion by proactively clarifying early: confirming assumptions, restating understanding, and asking questions before problems surface. Asking questions isn’t a sign of weakness—it’s a sign that you care about getting things right before they go wrong.

Measuring growth by effort rather than impact 💪🏻

Working long hours or solving technically complex problems doesn’t automatically translate to seniority. What matters is whether your work creates clarity and momentum for others.

For example, solving a complex bug is valuable—but explaining the root cause to the team, documenting the fix, or suggesting ways to prevent it in the future multiplies that value. Being visible doesn’t mean being loud; it means communicating your reasoning, sharing your perspective, and listening to others in return.

Impact is about what changes because you were there.

What worked in the early years—staying busy and writing more code—doesn’t cut through the fog anymore.

The shift forward doesn’t require a title change. It requires a mindset change.

Small adjustments make a disproportionate difference:

• Start asking why, not just how
• Document decisions and trade-offs, not just outcomes
• Think through failure cases and rollback paths
• Communicate early, even when things aren’t fully clear
• Own outcomes, not just assigned tasks

These behaviours quietly build trust.

And trust is usually what promotions are based on—long before they’re discussed.

---

Seniority, Reframed — and my thoughts 🚀

First of all, everyone goes through this phase—and it’s not limited to work. In life, we often find ourselves on unclear paths where progress feels invisible and direction isn’t obvious. I’ll leave it to you to reflect on when this started for you, or whether you’re going through it right now. If nothing else, I hope this article makes the road feel a little clearer.

My takeaway on what defines a senior developer is simple. Senior developers are the ones who:

• Reduce chaos for others
• Bring clarity when things are unclear
• Help the system—and the team—move forward

This kind of impact is hard to measure.

And that’s exactly why the journey from junior to senior feels foggy in the first place.

If this phase feels familiar, you’re not alone.

This is the part of the journey where growth becomes internal before it becomes visible again. The fog doesn’t mean you’re lost—it means you’re learning how to move without a map.

And that’s exactly what senior engineers do.

If you’re navigating this phase right now, I’d genuinely love to hear about it.

Feel free to share your experience or thoughts in the comments—chances are, someone else reading this is feeling the same way.

Lastly, here's some Yoda wisdom! Cheers 🍻