What is a Senior Developer?

Howdy, Upstarts!

On most occasions, the people who ask me this question are usually my Software Developers, looking for ways to learn and grow. As startup CTOs, we need to be able to answer this question when our engineers ask us, so let’s take some time and dig into this topic!

That Anual Review

When I first began building startups, there was one time of the year that I found particularly difficult: Performance Reviews.

At the end of each year, Organizational Leaders, including everyone from team leads to the CTO, should take some time to review the performance of not only the organization as a whole but also each team member of their engineering organization.

In larger enterprises, this process is incredibly rigid (read: inflexible) and usually occurs around the end of each calendar year. The process involves a self-reported analysis of each team members’ performance as well as various levels of feedback from peers or managers. This qualitative polling data is then aggregated and used to generate a report of the performance of each team member, and this report is then used to determine salary raises, promotions, and levels of seniority.

When I was a junior developer and working my first job out of school, I always found writing these assessments to be a hassle. Although, I understood the importance of these assessments for my future career. However, it was not until I started building startups and leading software engineering organizations, that I truly understood how much of a hassle these Performance Reviews can be.

If you think doing one Performance Review takes a lot of time and energy, then extrapolate that to doing fifty Performance Reviews!

Because I am a very hands-on engineering leader, I always felt that I should take the time to assess the performance of my software developers personally. (Remember: providing a connection to the Development Leadership is a great way to build a Sense of Belonging.)

So, one of the questions that my developers asked my time and time again was:

What should I do to become a Senior Software Developer?

As a Technology Leader, I love it when my software developers ask me this question for two reasons. First, it shows that my software developers are excited to learn and improve. I love working with people who love their work! Second, it is the type of question that appears simple and yet is much more complicated than it appears on the surface.

As thoughtful engineering leaders, one of our primary responsibilities is to oversee the paths and careers of our software developers that work hard for our startups; therefore, I take every question asked by my software developers as an important question. To answer this question, startup CTOs should possess a really firm understanding of how to build software engineering organizations, and this question requires us to be able to articulate the definition of senior software developers.

To give my software developers a career roadmap during the Performance Reviews, I needed to create a robust framework of understanding to the qualifications of a senior software developer.

Defining the Difference

As I said before, when I was a younger Technology Leader, I was conducting upwards of fifty Professional Reviews at a time, which is a massive number. For smaller teams, it is feasible to create career paths and to provide one-on-one mentoring in an ad-hoc manner. However, when your Engineering Organization grows to be larger than ten people, this becomes infeasible if you want to continue to provide High-Quality Feedback to your software developers. If you do not feel the need to provide High-Quality Feedback, then I suppose that you can stop reading this article and go ahead and unsubscribe and accept that you and I can never be friends.

So to scale my Engineering Organization, I needed to create processes and checklists, identify performance metrics, and define key terms. With these tools, I could create a standardized handbook for assessing the performance of my software developers and I could ensure that my software developers received quality feedback and opportunities for improvement from me and my middle managers.

As a result, I identified that one of the most important questions for a Technology Leader is:

What is the difference between a Junior and Senior Developer?

My goal for answering this question is to provide any junior developer who works on my team enough guidance to improve their skills and to reach the next stage of their career, regardless of their current level.

I came to my answers for these questions from the two positions: first, from the position of a Technology Organization Builder; and second, from the position of an Engineering Mentor. As a Technology Organization Builder, I needed to create salary brackets, I needed to manage expectations, and I needed to forecast budgets and organization needs. As an Engineering Mentor, I wanted to give my junior developers the next answer and direction as I possibly could.

Three Pillars of Seniority

I created a framework of understanding to provide robust definitions and expectations for each experience level within my Engineering Organization.

I built this framework of understanding around three areas of expertise or Three Pillars of Seniority:

• Communication

• Solution Structure

• Development Velocity

Without further ado, let’s dig into each of these topics.

Communication

For every skill of discipline, one of the best distinctions I can make between an apprentice and a master is their ability to teach or explain the core concepts of their discipline.

In modern academia, there are three levels of education: a Bachelor’s Degree, a Master’s Degree, and a Ph.D. Degree. Each of these Degrees has specific implications and indicates an increasing level of mastery in a discipline. For our purposes, we will focus on the difference between a Bachelor’s Degree and a Master’s Degree. In the classical definition, a Bachelor’s Degree indicates that a person is qualified to be employed. On the other hand, a Master’s Degree indicates that a person is qualified to teach a discipline.

It is like the adage: To truly master a subject, you must teach it.

This implies that you can measure the proficiency level of a software developer from how well they can explain their work in different formats: meetings, presentations, papers, mentoring junior developers, or conversations with people outside of your Engineering Organization. All of these provide examples of how well your software developer can communicate their ideas and how well your software developer can listen to and understand the needs of others.

This means that a senior software developer is significantly better at communicating the concepts of the technology with which he is working.

Solution Structure

One of the hardest skills for any skill or discipline is the level of organization that someone applies to their solution for any problem.

The organization is important for any problem, but even more so for highly complex problems, which most Software Development Problems are. There are many benefits to organizing a solution to a problem. These benefits include being able to prioritize additional work, being able to rapidly build new solutions from your existing work, being able to quickly navigate the problem, and being able to efficiently onboard and educate new team members. These principles apply to every type of problem.

Even beyond this simple level of organization is creating a framework of understanding around the problem. Because most challenges that face engineering organizations are going to be highly-complex, we must be able to find ways to break apart these complex problems into sets of smaller, more manageable problems. This is the classic strategy of divide and conquer.

So the way that a software developer structure their solution includes many different components that span the gap between being able to organize their code, being able to clearly name their variables, and being able to simplify complex problems.

That means that a senior developer has a significantly higher level of structure for his solutions.

Development Velocity

And of course, the last and arguably the most important area of expertise is the Development Velocity of a software developer.

Although the term Development Velocity is common in Software Development, I have always applied a slight twist of this definition, which you can read here. We are talking about something much more subtle than how fast a software developer writes code.

In the context of Software Development, Velocity incorporates not only how fast a software developer can write code, but also how much time is spent fixing and maintaining that code. So if a software developer writes code very quickly, but he writes bad code, then they will need to spend additional time fixing bugs and maintaining features. Because this software developer must spend more time on this code, then they will have a lower Development Velocity. It is not only about being fast but also about being good.

You can think of velocity as how much progress was made in a certain amount of time.

So, a senior developer will have a significantly higher Development Velocity.

The Three Pillars Support Your Organization

To provide a career roadmap for my software developers, I needed robust definitions for both a Junior and senior developer. To articulate this definition, I created three areas of discipline or Three Pillars of Engineering Seniority. These pillars are communication, solution structure, and development velocity. With these three Pillars in hand, I could develop metrics and challenges to guide my software developers to improve themselves and to strengthen their abilities.

Try to apply these Three Pillars to your meaning of senior software developer, and see how well their performance measures up to your expectations!