By March 6, 2020

Why You Shouldn’t Label Yourself as a Junior Developer

The term “junior developer” is ubiquitous—you see it used everywhere, from job listings to company rosters. Perhaps using the designation “junior developer” allows teams and companies to organize their tasks, allocate times, and assign responsibilities.

But just because (almost) everyone does it, it doesn’t mean you should too.

At least not unless you are working in Fintech or Big Tech earning six figures, normally in the U.S. If you are lucky enough to reach one of those positions, I take my hat off to you, and I wish you the best of luck and success.

If, however, you don’t fall into this category, then you really shouldn’t label yourself as a junior developer.

Otherwise, you risk devaluing your abilities and the value you bring to the market. Moreover, it could affect your mindset—you will think less of yourself, you will believe that you are unqualified and need hand-holding, and you will only give yourself permission to focus on your personal contributions.

The good news is, it doesn’t have to be like that! As I’ll show you in this post, you can be less experienced without being “the junior developer.”

All Developers … Develop: Experience Is Relative

Before I show you how you can effectively relabel yourself and let go of the “junior developer” designation, here’s an important piece of wisdom.

All developers … develop; we all grow and improve, all the time—or we ought to!

In other words, it doesn’t matter whether you’re less experienced or more experienced than some other developer. Experience is relative, after all, and to some extent, an arbitrary concept.

It’s of course true that, for instance, onboarding times can be different from role to role, given how difficult a given technology is or how many in-house proprietary processes are in play.

As a less experienced developer, you can expect to get up to speed within 1-3 months of joining a team to start to deliver independent value.

In these cases, you’ll normally have an experienced/senior developer show you the ropes. They teach you patterns and techniques and slowly ease you into the role. They’ll also likely provide code reviews and let you know if there is a simpler approach to solve a problem. Initially, you’ll be given easier tasks to complete.

On the other hand, a senior developer taking control of a company’s tech will have a longer onboarding to gain a full understanding of an entire stack and infrastructure. In this case, the senior could deliver client value extremely quickly when joining a role, but the actual onboarding could be staggered when problems occur.

The fact is everyone grows and adapts. Everyone makes mistakes. Everyone learns.

It doesn’t matter who you are or your skill level if you see something that could help your team speak up.

These moments of insight, kindness, and initiative will be noted.

So, How Do You Relabel Yourself?

“I’m a less experienced developer, and I want real-world experience. How should I proceed? I don’t want to deceive my future team.”

Good question. Let me now answer it.

Instead of thinking you’re a “junior” developer, think in terms of investment resource cost to get you to a state where you consistently deliver value.

To break this down, think in terms of salary, which is isolated from the other costs of employment.

  • A senior developer could receive £50,000.
  • A less experienced developer could receive £30,000.

At the high end, if a senior spends 20% (eight hours a week) of their time supporting you, the cost of employing you increases to £40,000 due to lost productivity increases, which could be an equivalent of one day a week lost of value delivered in a company.

Lost productivity scales proportionally into value production, especially for paying clients. A developer is paid as they produce more value than their cost; developers are value creators. Your taking up £10k of additional resource cost could equal £50-100k in lost business value over one year.

This is the fundamental business stigma of the perception of junior developers, especially for small startup companies with little cash flow. In many cases, the investment is not worth the risk, especially if individuals haven’t proved to be driven and self-starters.

Your goal as a young developer is to reduce the amount of additional resource cost required for you to become successful within the company.

By extension, if you can understand how you learned and you can communicate the process to others, you will be extremely valuable when you enter a future senior role, mentoring other new developers.

If you can get your head around this fact, you’ll be golden.

Software development is a business. There aren’t handouts here, as you have an expectation to deliver.

Building Your Knowledge, Showing Evidence, and Asking for Ownership

Focus on building deep T-shaped skills specifically within a technology that you are passionate about. Go as deep as you can, and try as many facets as possible.

When I started my career, I focused purely on Android development and learned everything I could within that ecosystem.

There is a common complaint that is frequently noted by the usual:

“Why do all junior roles I see require work experience when I’m trying to find a role to give me some experience.”

This is combated by a single strategy: Make your own projects, release them as open-source, and share with the world.

If you are short on project ideas, speak to your friends and family around you. Maybe they are using an app or service that you could duplicate and then enhance to fit their needs.

When you gain more experience and responsibility, your previously learned expertise will extend into other technologies.

When you are interviewed for a position, focus on these items:

  • Evidence of your work, what you learned, and whom you potentially helped.
  • That you are seeking ownership of your portion of your codebase, and that you want to help others grow.
  • Mention that you have ambitions to learn and grow within the company and help as many team members as possible.

Frame the narrative of the conversation in this order:

  1. I am competent at what I do, this is the evidence.
  2. I will help the company reduce costs by taking the burden away from others.
  3. I have the right attitude, I am loyal, and generally speaking, hiring me will lower risk.

Ownership, in the eyes of the business, means that you naturally require little or no help from your peers in order to produce and deliver. This also comes with an expectation that the portion of the stack will be handled by you, meaning that this is one less item that needs to be dealt with.

It’s About Unique Value

What you’ll learn with interviews goes beyond technical or basic soft skills. It is a kind of dance where each party uses influence to set the initial tone of the relationship. From your point of view, it is about being prepared and understanding your unique value proposition.

Hiring is hard. Code is a commodity, and I believe there are many people who fit this mold and want to prove themselves to employers. Finding someone who can communicate this, though, is rare.

If you can communicate your unique value to the gatekeepers of the business, can give them confidence that you know what needs to get done, and can generally be self-sufficient, you’ll make it.

You’ll be a fully-fledged Junior Software Developer.

About the author

Matthew Smithies

Matt has worked his entire career as a remote software engineer with contributions to 20+ startups, his blog World Class Remote focuses on helping software developers navigate and cope with remote life. He is the Lead Developer for Coursematch an EdTech startup and you can connect with him through LinkedIn.