The software industry is known for many things, but “reaching consensus” doesn’t seem to be one of them. Software professionals can’t seem to agree on many issues, including what we call ourselves. As a leader in tech, I’m sure you’ve come across many different software engineering job titles during your career.
Software engineer, developer, and programmer are certainly the most common ones. However, there are more exotic titles out there, such as software artisan and even software gardener.
In this post, I’ll be your guide to the messy land of software engineering job titles. I’ll start by covering the difference between job titles, roles, and levels. Once that’s out of the way, I’ll proceed to explain why there’s such a difference in the first place. As you’ll see, there are good reasons for that.
Then, I’ll cover the actual different job titles you might see in software engineering. Before wrapping up, I share some tips on how you can choose the right job titles for your organization.
Let’s get started.
Job Titles, Roles, and Levels: Understanding the Difference
This post is about the specifics of software engineering job titles. Before we go there, though, we must discuss job titles in general, particularly how they differ from roles and levels.
Let’s start with job role. Simply put, the role indicates what the employee does in the organization, and it comes with expectations and responsibilities attached. The job role of an employee is intimately linked to their knowledge, skills, and experience.
I am a computer science major. So, I lack the skills, competence, and legal requirements to play the “accountant” role at an organization.
Now, let’s move on to job title. This refers to the name an organization decides to give to a particular role. So, two people playing the same role in two different organizations might have very different job titles—for instance, software developer and programmer.
Finally, jobs can vary in their levels. Levels, in short, can indicate more authority, technical competency, and experience—it’s usually a combination of those. Similar to titles, levels can—and do—vary a lot across organizations.
Qualifiers such as junior, senior, and principal are common. There are companies that prefer numbers—Software Engineer I to Software Engineer V, for instance—while others might use a combination of numbers and qualifiers.
Levels are often tied to compensation. Typically, going from, say, Programmer I to Programmer II entails more responsibility but also better pay.
Software Engineering Job Titles Vary a Lot. Why?
There are many reasons why the software engineering job title landscape is so messy. As you’ll see, most of them are actually good reasons.
For starters, our field is young and still changing rapidly. Unlike medicine or law, software development as a job is only a few decades old. We simply haven’t had the time, as older fields have had, to standardize on many issues.
Also, ours is an ever-evolving industry. New jobs are created all the time. Just think about the developments that occurred in the last two decades:
- The development and increasing adoption of cloud technologies
- The rise of DevOps
- Containerization
- The explosion of JavaScript frameworks, libraries, and tools
And these are just to name a few, but you get the gist. If we attempted to standardize software job titles, by the time we were finished, there would be a plethora of new jobs to categorize.
Finally, unlike in heavily regulated fields, you don’t typically need to have a specific bachelor’s degree or be affiliated with a council or other institution—at least in the countries I’m aware of. Discussing whether that’s a good or bad thing is certainly out of the scope of this post. Nonetheless, it’s a factor that contributes to the lack of standard job titles across the industry.
What Are the Different Positions in a Software Company?
We’re now on the same page in regard to job titles and how they differ from roles and levels. In addition, you now understand some of the reasons why there aren’t standard job titles in the software industry to begin with.
Let’s now start covering some of the actual job titles you might find in the wild.
Programmer vs. Software Engineer vs. Developer: Does It Matter?
When it comes to what people who write code call themselves—or are called by others—the most common terms you’ll find are programmer, software engineer, and software developer (or simply developer). Also, you might run into some less common ones, such as coder, or exotic ones, such as the already mentioned software artisan and software developer.
Here, let’s focus on a programmer, software engineer, and developer, simply because they’re the most common ones. Are these equivalent? Well, it’s incredibly easy to find people arguing that there is a semantical difference between the terms. You might read, for instance, that “programmer” refers to someone who’s more low-level oriented and works alone while “developer” would be someone with communication skills, who’s able to understand business requirements, works well in teams, and can work with a broader set of tools and systems.
Personally, I see “software engineer” and “developer” as indistinguishable. With “programmer,” though, I see a small semantic difference. To me, “software development/engineering” assumes a project, typically done by a team. On the other hand, “programming” is the “physical” act of writing a software program.
Here’s an example: If I’m working on a project with a team, I’m certainly developing software. If I’m creating a Python script to help me automate some tasks, I’m programming, but I don’t see that as “developing software.”
This is, of course, only my personal view. These terms are often used interchangeably, and in the grand scheme of things, I don’t think there’s any harm in doing that.
Junior, Senior, and Beyond
It’s common for organizations to add a qualifier to a job title to indicate the seniority of employees. Seniority itself is somewhat of a confusing term. Here, I use it in the sense of rank, to indicate a team member’s experience, knowledge, and responsibility. Junior and senior are among the most common ones, but you’ll often see staff and principal as well.
The actual meaning of these qualifiers, of course, varies among organizations.
As a general rule, junior refers to entry-level jobs. Junior software developers are individuals with little or no experience, usually fresh out of school. They often need close supervision, don’t have a high degree of autonomy, and aren’t expected to handle critical features by themselves.
As the team member acquires more experience and knowledge, they might advance through the ranks, acquiring more autonomy, responsibility, and also better pay.
The company Basecamp, for instance, uses the following titles:
- Junior Programmer
- Programmer
- Senior Programmer
- Lead Programmer
- Principal Programmer
Besides those qualifiers—or in lieu of them—organizations might also use numbers to indicate the seniority and rank of an employee.
Software Developer Job Titles: Pick the Right Ones For Your Organization
People with certain titles make more money, on average, than others. You can get such data from sites like Glassdoor.
Also, anecdotal evidence—such as conversations with friends—indicates that software engineers are the biggest earners. On the other hand, programmers and coders tend to earn less. When it comes to ranking, juniors earn less than the higher rankings, which is no surprise.
What to make of all of that when picking the titles for your organization?
- Maximize earning possibility. Calling your team members “engineer” rather than “developer” or “programmer” doesn’t hurt you in any way. So, do that, so they have the chance of earning more if or when they leave your company. Consider it a free perk.
- Consider the importance of variety in skills set and experience. Most often than not, you don’t want a team with only seniors in it. Make sure you design a career track that accounts for the need for less experienced as well as more experienced engineers.
- Pay the same salary to everyone at the same level/title. That might or might not be a legal requirement, depending on where you are. But it certainly is the right thing to do.
- Define the expectations and responsibilities of each title/level in a way that’s clear and unambiguous. Communicate that description to HR, your recruiters, or whoever is responsible for managing job posts and the like.
Besides the guidelines above, remember to start simple. If your organization is new, there’s no need to overcomplicate things.
Start with three simple levels (for instance, junior software engineer, software engineer, and senior software engineer). Define job descriptions, responsibilities, pay, and perks for those levels. You might also need a team lead or tech lead, but that should suffice.
Then, add new titles as the need arises—such as needing to further distinguish a senior engineer who’s done an outstanding job.
Of course, your mileage certainly might vary. If you want to learn more about engineering team leadership, subscribe to our podcast, Dev Interrupted.
Join the Dev Interrupted community to discuss the Silicon Valley Bank crash, how Uber’s engineering team lost its way, the challenge of AI self-driving, and Kyte’s experimental product innovation playbook.
Kyte’s Head of Product and Engineering, Nick Cobb, joins host Conor Bronsdon in New York City for this in-depth podcast streaming April 4th and 5th.
