Back to overview

Stop Being a Junior

May 30th, 2023 — 9 min read

Man in middle of wheat field
Man in middle of wheat field

Are you a Junior developer? If you answered yes: How do you know? Is it because your title is "Junior Developer?" Is it because your co-workers get all the more interesting work and you're stuck with the more boring repetitive tasks and simple bugs? Or do you just not feel like you've not "done your time" yet to drop the "junior" moniker?

Whatever the case may be, I want to tell you to stop being a junior. Stop it now. I've talked to lots of people who start their conversation with me by saying "I'm just getting started" or "I'm just a junior" to which I reply "that's great! Welcome to the software development world" only to find out they've been working as a software developer for over a year and a half already. This surprises me. And it happens so much that I decided to write this blog post about how to get yourself out of this eternal-junior situation and start making major positive movement in your career.

Tech is fast

First of all I think it's important to establish this first:

There's absolutely no time limit on how long you have to be a developer before you are no longer a junior.

Any number on that you may have heard is wrong.

One of the things I love about this industry is the pace it moves: fast. With emerging technologies all the time and improvements to existing technology, it really doesn't take much time for a developer staying on top of these advancements in their area of interest to reach a level of familiarity that rivals those with decades of experience.

I think of it like this. Imagine there's a river with a steady current. Riding on a tube down the river is like developing experience in software development. Instead of everyone starting at the beginning of the river, they start where everyone else is. It doesn't take long once you jump in to keep up with everyone else on the river, regardless of how long they've been doing it. Yes, you'll be lacking in experience upstream, but that doesn't change the experience you're having now. It's an imperfect analogy, I know, but I think it's instructive.

Now of course, there's a lot to be said for people with decades of experience, and while most of it is positive, not all of it is! People with years of experience are more likely to be able to learn new things faster because often new things resemble old things (though not always!! "unlearning" is definitely a thing too). Experienced developers are also more likely to be able to identify problems in code long before they are problems because they've seen how things play out in the real world and they understand constraints better.

That said, experienced engineers are also more likely to be hesitant to try newer tools and technologies and instead be "set in their ways." This can lead to them missing out on really terrific advancements in the ecosystem and tools. Experienced developers are also likely to miss important new features in languages and tools because they're just used to doing things a certain way.

Anyway, my point is that because of the pace at which the software developer industry moves is so fast:

Staying on top of a few chosen technologies allows anyone to become an expert in them rather quickly.

And if that person can temper their enthusiasm with a realistic understanding of the impact of their lack of experience just a bit, they can make an enormously powerful impact to the company (if they're allowed to).

My own experience

I went to college and had internships while I was in school. This gave me awesome exposure to the field before I was officially looking for a full-time job. So by the time I graduated, I had already been working as a part-time software developer for a year and a half.

When I graduated from BYU and joined as a full-time engineer, I had trouble shaking off the "junior" moniker. Even though all my experience up to that point had been part-time work while I was still in school, I felt like I knew my team's area of the codebase as well as anyone else and it didn't feel right to me that I still got the lower priority tasks.

I saw some really big architectural level tasks going to the more experienced engineers and I wanted a piece of that. However, since I converted from student to full-time employee and everyone knew me as the student, I always felt like people saw me as "the intern".

Maybe I could have been a little more assertive about my goals and hopes, but I just decided that the only way for me to get more responsibilities was to go to a new company where people had never seen me as "the intern" and would instead see me as a regular co-worker.

So that's what I did. Just four months after converting to full-time, I was recruited away to my next company where I was given a massive pay bump (over 50% increase) and 20% of my time was devoted to architecture. It was phenomenal. Nobody ever saw me as a junior again. In fact, I was just a step below architect in a quarter-billion dollar organization only 4 months after graduating from university.

And that played out extremely well for them. When I joined the company, they were wanting to do a major migration of their frontend tooling. I was instrumental in designing the migration path and it was a smashing success.

Read my whole story in 2010s Decade in Review.

How to stop being a junior

Instead of thinking about how to stop being one thing, think about how to start being something else.

What do senior developers do in your company? Do that instead of the things junior developers do. That's it.

Naturally the company likely trusts the seniors with more than they trust you and you don't want to overstep, but volunteer to participate in the more complicated tasks. Even if it's just "hey, can I come sit in on that meeting?" Take notes for yourself of anything you're unfamiliar with and ask about those things later. In future meetings you'll be able to contribute more and more with the knowledge you start to accumulate. Study things out a bit after the meeting and make suggestions.

Beware of being over-bearing. Even though you can accumulate a lot of modern knowledge really fast, you should be sure to acknowledge that your experience limits the usefulness of that knowledge. So be respectful of your co-workers. But find the people who are willing to sit down with you and answer your questions to help fill in the gaps in your experience as you rapidly accumulate knowledge.

Use that fast-paced technology to your advantage and learn about what's new and improved that developers at your company can take advantage of today. Then teach those concepts in "brown bag" lunch meetings (meetings where everyone brings a lunch and someone presents something often held weekly). If your company doesn't have brown bag lunch meetings scheduled, get them scheduled and present at them.

Volunteer to speak at local meetups. A meetup talk is responsible for both my job change I talked about earlier as well as me getting invited to join Egghead.io as an instructor. Propose to speak at conferences.

Talk about what you've accomplished to demonstrate you really are contributing at a level beyond their expectations of a junior. Make them think to themselves "huh, this dev is only a junior and they did that? Maybe they're not really a junior after all."

Make sure your manager understands your goals and intentions as a developer. If you're hoping to ask for a promotion in the meeting where your manager tells you about whether you get a pay raise, you're asking way too late. They should know your goals much earlier than that and you can ask them what they expect you to be able to do to get to that level.

Try it 'til it fits

I don't like the phrase "fake it 'til you make it," but the sentiment is here as well. The idea is you operate on the level of what you want to be as well as you possibly can, and eventually it'll start feeling like you really are at that level.

I felt like I had to leave the company I was with to get up to the level I wanted to be. I probably could have managed it with the company I was already with if I had been more patient. I probably would have done that had I not been actively recruited out. That said, sometimes if you just can't shake the "junior" off your title, you may consider looking for another opportunity.

Conclusion

I hope with this article to not diminish the amount of work it takes to gain experience and make impact in this industry. It's a lot of work. However, my primary goal is to help inspire some folks to set their sights higher. You're capable of more than you think. I promise.

You don't have to be a junior anymore. It's time for an upgrade.

Good luck!

Kent C. Dodds
Written by Kent C. Dodds

Kent C. Dodds is a JavaScript software engineer and teacher. Kent's taught hundreds of thousands of people how to make the world a better place with quality software development tools and practices. He lives with his wife and four kids in Utah.

Learn more about Kent

If you found this article helpful.

You will love these ones as well.