March 24, 2021

Stop it. The myth of the senior developer.

Stop it. The myth of the senior developer.

The truth is after some deep thought and contemplation, I’ve come to the conclusion that there’s no such thing as a senior developer.

Why? Because the idea of being a senior developer is highly subjective.

The Subjectivity of Seniority

Where you stand on the scale of seniority really depends on where you are: your company, the people, and the content you surround yourself with. Among complete beginners, you may appear like a senior dev because you simply know more than them.

If you’ve been working at a particular company for a long time, seniority might come about due to internal knowledge and not actual skill.

Some places even go by the number of years rather than one’s ability to create and think.

The idea of a senior developer is subjective because the person assessing you on the other side might not know any better. They might have the title of a senior developer, but their true depth and breadth of knowledge and ability to synthesize might be questionable.

Sometimes, it’s not their fault. They might have just grown to the size of their pond. Their scope of work might not offer them the scope they need to grow. Or their workplace just isn’t in that kind of position or environment to foster such growth.

It happens.

And it happens a lot more than you’d realize. It happens so much that even we can fall prey to this issue.

So how do you prevent yourself from being stuck in such a loop?

First, you need to learn to be the little fish once again.

What You Should Be Focusing on Instead

You can read all the how to be a senior dev stories ad nauseam, but it won’t actually upgrade your skills.

You’re better off reading guides on how to improve a particular set of skills or roadmaps on how to become pro at a particular framework, library, or idea.

For example, here are few useful ones:

Bento.io also does decent learning-journey guides for free.

What you need to do is work along the paths or create your own, collecting knowledge points, revelations, and error familiarization. Most of the time, we just stop working when the code works — but what if you were to take it one step further?

What if you actually decided to take a look at your code with a fresh perspective after learning a new coding, design, or architectural pattern?

You’ll start to see the inefficiencies in your habits and styles.

Why is this more important than binging on motivation?

Because you’re actually training yourself to become a better developer. The issue with code is there will never be perfect code. As soon as you learn or recognize something new, as soon as there’s a change, and as soon as there’s a package update, new framework, or language feature release, your code will begin to age.

How T-Shaped Are You?

In the recruitment world, the concept of T-shape is often used to assess a potential candidate.

The horizontal part of the T represents the width of your knowledge — that is, how many other things do you know and understand beyond pure coding?

Do you understand how shopping carts work from a user perspective? Can you abstract out the popular user interface patterns and actions without the need for formal education? Do you know how financial and accounting principles work because the company might need you to create a connection to their accounting software?

The vertical part represents depth in a particular area. It’s this vertical line that companies and recruiters often look for, especially if they’ve got a senior dev opening available.

You can be at multiple depths across your entire horizontal bar, but what you really need to do is properly specialize in at least one thing. This thing you need to know and understand to a point where you can explain it to a ten year old and get them to understand it at a working proficiency without overly dumbing it down.

Why? Because ten year olds have the mental capacity to code nowadays — if the content is presented to them in a way that’s not overfilled with abstracted concepts.

It Takes More Than Just Writing About Senior Devs to Become One

There’s a general assumption that because I write a lot about code, I must certainly be a senior developer.

But the truth is, I’m not.

Sure. I can code. I can observe. I can think. But do I consider myself a senior dev? Probably not.

Why? Because there’s always someone out there better than I am, more knowledgeable than I am, and, most likely, more creative at coding than I am.

And it’s the acceptance of this reality that’s allowed me to learn something new. Reddit, for example, has a minefield of very vocal people who sit on both sides of the spectrum. Some are helpful in my learning and growth journey as a developer, some not so much.

Some comments extend and expand my knowledge. Others are just nonsensical personal attacks from an internet stranger.

To a lot of developers who are more advanced than me, I’m probably looked on as somewhat mediocre.

But I put my content out to the world anyway. If I’m right, someone learns from me. If I’m wrong, I learn from them. It’s all one big community — giving as much as it is taking.

Final Thoughts

The title of senior developer is a bit of a vanity metric and, in part, employed to get a higher paycheck.

Yes, there are some financial perks that come with being a senior developer, but if you’re new and starting out — that’s not what you should be aspiring toward.

Senior devs are expected to be highly proficient in what they do, thereby reducing the potential for bad architecture and inefficiencies.

Wherever you are right now in your career, that’s what you should be working toward instead. Proficiency comes in many grades, and the more you understand and know how to do something, the better you are at it — which leads to better negotiating power for the final paycheck.

It takes projects, experimentation, and a dash of creative thinking in order to be able to make something meaningful from scratch. So stop reading listicles on how to be a senior dev, how they think, and all the related things surrounding the topic. Instead, start learning the actual code and get creating.

You’ll make more progress in greater leaps that way and, ironically, get closer to that coveted senior-dev badge than ever before.