[NEW] Basic gets a boost: Announcing major upgrades to our free AI code assistant
Home / Blog /
How to upgrade from being an intermediate developer to a senior veteran
//

How to upgrade from being an intermediate developer to a senior veteran

//
Tabnine Team /
5 minutes /
July 16, 2020

There’s more to being a senior developer than just the number of years you’ve got under your belt. Just because you’ve been writing a particular language for a certain amount of time, it doesn’t default you into a true senior veteran. Age and length of time might contribute, but it’s not the final factor.

So what does it take to be a senior developer? What exactly do you need to know? Or is there some secret sauce that you need to dip into for qualifying as a senior veteran of code?

The difference between juniors and intermediate developers

The difference between junior and intermediate developers is not that large. A junior might have just recently graduated or managed to finally get their foot into the door. It might be their first proper development job, building real software with other developers who know more than them.

It only takes a few intense projects to qualify as an intermediate developer. It might be within six months to a couple of years, but the act of moving up the organizational ranks – either through promotion or job change – is very easy.

And this is where many developers tend to get stuck. They’ve defaulted into the intermediate role because of job experience – but at what point is it considered enough to be a senior developer?

when a senior developer solves a problem

It’s to do with how you think

An intermediate developer can construct proficient code. A senior developer knows how to architecture it.

If you think about the difference between the bricklayers and the architect, intermediate developers often perform tasks that follows a particular structure or plan. Senior developers tend to move between the code and, using their expansive knowledge, connect the right dots.

While intermediate developers can construct blueprints and plans of their own, senior developers tend to focus on patterns and future implications.

They’re forward-thinking in their approaches, and have experienced the fine line between factoring in all the potential outcomes vs. the demands required to be delivered.

And it doesn’t take them long to make a decision.

The dots that they have at their disposal are wide in topics and areas, ranging from a myriad of stories, articles and many things they read and consume. They are constant learners and consumers of knowledge, and know how to apply them in the right moments. Their learning may be structured and linear for certain aspects, but a lot of the learn is deconstructed and ad-hoc.

The ad-hoc nature of knowledge acquisition gives them an edge over their intermediate counterpart. How? because the senior developer have more dots to join to form a better and more cohesive picture of the technical requirements, pinpoint potential weaknesses and architecture in strength and robustness.

You’re always going to be a junior at something

The idea of the senior developer is a bit of myth in itself. While the title is good for management and pay scales, as we move through the different languages, releases, packages, updates and upgrades – the scope of being a developer can never truly be defined.

This means that you can’t possibly put a developer on a scale of how much mastery they’ve got over a particular sphere or area of their chosen language. At some point, other languages and technologies will find its way into the senior developer’s peripheries.

Regardless of knowledge depth, breadth and experience – you’re always going to be a junior at something.

The senior veteran of code acknowledges this. They understand that they may be a senior in one specific area of code development, but it doesn’t automatically give them seniority in everything. This is often a misconception that many juniors and entrants into the industry have.

Juniors tend to make judgements based on the number of years rather than the intensity and depth of a particular project – or series of projects. That’s why agile projects tend to upgrade a developer’s professional development faster than other forms of project management.

When you’re working in an agile environment, you’re forced to learn quickly and apply your learnings.

junior developer vs senior developer

Expose yourself to experience

Experiencing a lot of projects in succession doesn’t exempt you from the depth factor. Depth of knowledge runs beyond the ability to create code. It also includes the ability to create code in that succinctly beautiful.

What does beautiful code look like?

This one is debatable. But if you think about it this way – anyone can write code. But to write code that works, has the ability to withstand changes, remain stable after core and package upgrades, among many other things – that takes skills and foresight.

Gaining this skill might be in the form of previously encountering errors, bad architecture and finding solutions to them. Not everything is a greenfield kind of project and a senior veteran of code is often marked by the past code of others – some good, some bad, some in the form of nightmarish code that smells so bad that it’s beyond salvageable.

This is a facet of coding that only senior veterans of code experiences in large volume. It’s part of the job. it is also something that not many non-technical interviews pick up on. They may look at other markers such as years or length of tenure instead.

They do this because it is the same markers often used in other areas of the business world. However, potential future fellow team members can sense a developer’s seniority based on how they interact with others and the way they analyze code.

So how exactly do you upgrade yourself from intermediate to senior developer?

A junior developer is often preoccupied with perfect code. An intermediate developer tend to focus on the idea of ‘clean code’. A senior developer will go down the path of balanced and working code. Balance comes in the form of weighing up the needs of the business and the needs of the system, and finding the right solution to bridge both worlds into the same universe.

To get to the final stage, here are few things that can help get you there.

  • focus on the ideas: things like patterns, architectural style, modes of thinking, and design systems.
  • focus on the business niche: understand how things work from a consumer perspective, how data is expected to grow in size, format, and form, understand the potential trajectories that can impact on the current structures in place.
  • practice helping others: a developer’s knowledge about a certain topic is often displayed through their ability to help those more junior than them. Practice helping others, solving the kinks and quirks encountered by your teammates that you’ve experienced before, look at how you can improve your mutual code together. This will also help increase your communication skills and make you a better team member.
  • learn beyond your domain: other languages, frameworks and technologies may have ideas that are not addressed in your current area of expertize. Accept your junior-ness in other areas and work on understanding things from the perspective of different technology. You might be able to apply what you already know to the new language or framework – but don’t let that cloud you from their way of thinking. It’s easy to fall wayside and think you know everything. But the other language, technology, framework or library was created to solve a problem. Find out what that problem is and see how the technology solves it.

Being a senior developer is more than just the code. It’s about the depth and understanding of the code presented. It’s also about the ability to see into the future, with an educated guess of how things will fall apart and withstand changes.

Change is one of the main reasons why code becomes brittle and needs maintenance. But change is necessary and part of every business. A senior developer understands this. They embrace it with open arms and accept that they will also need to grow their techniques toolkit, adapt, and continuously learn in order to remain on top of the change.