The first two or three years of a software engineering career are a period of rapid, visible growth. You go from not knowing how to write production code to shipping features, reviewing others’ code, and handling real systems. The progress is tangible and motivating.

Then it slows down. For a lot of engineers, it stops entirely - not because they became less capable, but because they stopped doing the things that produce growth.

The Comfort Trap

The growth in your early years came from constant discomfort. Everything was hard. Every week you were encountering problems you had not seen before, techniques you did not know, systems that were completely new.

Around year 2-3, most of that discomfort disappears. You know your tech stack well. You understand your team’s codebase. You can handle most of what comes at you. The work becomes… comfortable.

Comfort is the enemy of growth. When work is easy, you are executing on existing skills rather than building new ones. The neural pathways that felt uncomfortable while learning are now efficient habits. Efficient habits do not produce growth.

The Four Failure Modes

Failure mode 1: Domain lock-in. You became the expert in one area and that is all you work on. Three years in, you know the payments service better than anyone. But you have never touched the recommendations engine, never worked on infrastructure, never dealt with the data pipeline. Your expertise is deep but narrow - and narrow experts hit ceilings.

Failure mode 2: Scope lock-in. You are still doing the same type of work you were doing two years ago. Implementing features, fixing bugs, reviewing PRs. You are better at it than you were, but the type of work has not changed. Promotions require different work, not just better execution of the same work.

Failure mode 3: Learning without applying. You are reading books, watching courses, attending conferences. But the learning stays theoretical. If you cannot point to something you built or changed because of what you learned, the learning is not producing growth.

Failure mode 4: Waiting for opportunities. Waiting for someone to give you a stretch assignment, put you on the exciting project, or promote you into a role with more scope. Growth at senior+ levels is almost always self-directed. Nobody is going to hand it to you.

The Technical Debt in Your Skills

The technology you learned when you started your career is aging. JavaScript frameworks evolve rapidly. Infrastructure tools change. New paradigms emerge - serverless, edge computing, AI-integrated development.

If you have been working in the same stack for 3 years without deliberately expanding, you have accumulated technical debt in your skills. You are not less skilled than you were - the baseline just moved.

This does not mean chasing every new framework. It means being intentional about what you learn and staying current in areas that matter for where you want to go.

What Active Growth Actually Looks Like

Growth does not require a new job or a different role. It requires doing different types of work within whatever context you are in.

Expand technically: Take on the part of the codebase you have been avoiding. Volunteer for the infrastructure work, the security review, the database migration. Work that is outside your comfort zone is where growth happens.

Expand your scope: Stop waiting for problems to be assigned to you. Identify problems and propose solutions. This is the behavioral change that moves you from mid-level to senior.

Get external feedback: Your colleagues are used to you. They see your work with the assumption that it is “normal Chirag output.” External feedback - from open source contributions, conference talks, writing, or communities - gives you a less filtered signal.

Teach what you know: When you can explain a concept clearly enough that a less experienced person understands it, you deepen your own understanding. Teaching reveals the gaps in your knowledge that comfortable expertise hides.

Work with people better than you: The fastest way to grow is to spend time with people who are further along. Find a mentor, join a team with engineers whose work you admire, or contribute to open source projects where more experienced engineers review your code.

The Feedback You Are Not Getting

Most engineers in years 3-5 are not getting honest, direct feedback on what they should do differently. Performance reviews give generic positives. Day-to-day work rarely generates specific developmental feedback.

You need to seek this out actively:

  • Ask your manager specifically: “What is the one thing I should work on that would have the biggest impact on my career growth?”
  • Ask senior engineers whose judgment you respect: “What do you see in how I work that I should be more aware of?”
  • Look honestly at the work you have done in the past 6 months: is it different from what you were doing 6 months before that? If not, what does that tell you?

The Ambition Check

Some engineers reach year 3-5 and discover that they are actually content. They do not want to become senior or staff engineers. They want to be highly competent at their current level, have reasonable hours, and live a full life outside work.

This is a valid choice. It is worth being explicit about it rather than assuming you want growth and then acting in ways that contradict it.

If you do want growth, the question is not “why am I not growing?” - it is “what specific things am I doing differently this quarter than last quarter?” If the answer is nothing, you have identified the problem.

Bottom Line

Growth stalls after year 3 because the automatic discomfort that drove early growth is gone. To keep growing, you have to deliberately create discomfort: expand into unfamiliar areas of the codebase, take on scope beyond your assigned tasks, teach others, seek external feedback, and spend time with people who are better than you. The engineers who keep growing do so because they take deliberate ownership of their development. Everyone else coasts.