A proposal that honors every developer by performance
Think a moment about any senior developers you might know who can hardly work on their own. They can’t solve a single ticket but have to be always helped by (junior) colleagues.
Senior is a prestige title, once earned, never reevaluated.
This leads to the fact that companies often wrongly assign the terms — Junior and Senior. And probably so do you.
These words become hollow when grouping developers according to age and experience rather than performance.
Don’t get me wrong, I like my earned senior badge and the favor of dividing developers into different categories or classes. After all, the underlying concept is to help companies achieve higher software quality with less risk.
To get a safe estimation of one’s skill, a better model can be applied by separating it into Silver, Gold, and Platinum developers.
No worries if your company still uses the junior and senior models. You can always apply the model in this article to yourself or inside your team and create awareness about skillsets matching the latest requirements of the tech world.
Ultimately, this will also give you a confidence boost during your job interview. Any interview partner often comes with the classical “Ah yes, you have just one year of experience. Well, we can’t pay you more then.”
The terms junior and senior suggest a division according to age and experience.
This concept is very well known in the field of management consultancies. Graduates generally have little experience. They are usually a junior consultant. When they have gained experience, they become a senior consultant.
This might work well in this area but does not fit into the tech world.
The incorrect application
Changes happen almost every week in software development.
Once anyone has achieved the status of a senior developer, they usually hold this status for the rest of their lives. New technologies, new platforms, and new frameworks are coming out. This circumstance leads to a constant moving knowledge barrier to work on the latest projects.
The consequence is often that a senior no longer meets the baseline because they have shortages in particular areas.
The reality hits even harder.
Not only do seniors mostly not match the knowledge baseline, but corporations often use these developer categories as a form of recognition. Mainly through lower/higher salaries.
The division is exemplary and should stay, but it must be reshaped.
The subdivision should not be recognition for older colleagues, nor should it be a status or a salary model in software development.
Instead, it should award those developers that match the fulfillment of a baseline of must-have technologies.
And that’s why I believe this subdivision is simply depriving, often intransparent, and therefore not very meaningful regarding software quality.
Junior developers are dangerous, and senior developers are an asset.
An example is the best way to explain the difference:
Imagine two developers working on a project. A junior developer and a senior developer.
The junior developer is relatively new to the job, perhaps just out of school/university.
If the junior developer now implements functionality in the application, this will, of course, work. But not so easy:
- It will take longer due to inexperience
- They may also need help from more experienced colleagues
- Functionality in the application is most likely not sustainably implemented (due to lacking knowledge of software design and software architecture)
The three mentioned complications result in code that is not as reusable, not as exchangeable, and not as evolvable as desired.
The senior developer, on the other hand, already has many years of professional experience. They even stayed with the same company for years, which evolved knowledge in their tools and domains. Furthermore, they are also familiar with the area of software design and software architecture.
If this developer implements a feature into the project:
- They will most likely implement it fast
- They will also make the function maintainable
- They will also make the function further developable
- They will also make the function modifiable
In other words: a senior developer tends to implement a feature/function sustainably.
But is this always the case?
Your thoughts are coming to my mind: “I am a junior, but I am far from being a danger to the project, Instead, I enrich it.”
I have seen a few junior developers that fulfill the skill-based determination of a senior developer. Even I was one of them. When I changed a position inside my former company, I was officially a junior developer (roughly 2 years employed), but since I was better in web development, I mentored my new team (consisting of three Senior devs) on things they didn’t know.
And maybe you know senior developers who are hardly able to work alone. They can’t solve a single ticket but have to be always helped by (junior) colleagues. I also experienced this in the past.
Would you “demote” a 50-year-old senior dev to a junior?
I know such situations. However, this is not due to this class system per se, but because it is misused in most companies. Here is an example to make it right:
I am going to work as a freelancer for a Rust gig. Do my project partners see me as a senior, although I have almost eight years of experience? No, they don’t, and I don’t either. In Rust’s world, I am a bloody junior. I have only worked through the official Rust book and made some example applications the book told me.
What does that mean? Every senior reclassified as a junior has the potential to overstep certain thresholds faster.
And that’s the keyword for a better approach: thresholds!
What makes a junior developer become a senior developer?
I believe the required toolbox of a developer and thus what a developer must master to increase the project’s quality.
This is precisely the boundary that any developer must cross to level up.
A developer below this baseline in knowledge and experience is a junior developer. Getting above the baseline means being a senior developer.
It is important to note that this baseline is flexible. Individual points can be added or removed from the baseline at any time.
Suppose one or more senior developers no longer meet the baseline after it has been adjusted. In that case, they must be reclassified as junior developers. Otherwise, there is no proven guarantee to continue working safely on the project.
Sticking to a division on a project-based scale is fine if actively adjusted.
Introducing three categories to value the work of any developer:
This renaming seems meaningless and fancy at first, but it makes one thing much simpler and more non-depriving:
It detaches the aspects of age and experience.
After all, the new entry-level developer (a 20-year-old developer) may already be a Gold developer due to private projects or practical studies. These private projects were a massive part of any of my job interviews—even the one where I got to teach three senior devs about web development.
The threshold is your tool to measure the developer’s quality
It has to be adjustable.
For example, when the project grows and more technologies are used, the entry hurdle is higher, so the threshold must move. Hence, it is necessary to classify your developers into risky, sustainable, and risk-free.
It might happen that a large number of Gold developers are suddenly downgraded to Silver developers just because the baseline has changed. And that’s okay. Their age or time in the industry is no part of this division.
Do you think someone turns automatically good just because they do something for long enough? Think of anyone you know that doesn’t drive a car well. Now, think about how long they are doing it? Do you see? Even decades aren’t a guarantee for being good at something.
What stays essential from a software quality perspective is transparency. Even this one shows you clearly who can deliver quality to the project.
The team leader/company goal
Any team or company should always try to have as many Gold developers in the project teams.
For Platinum developers, you could implement a certain regularity — for example, every half a year — all team members designate one or more developers who have made remarkable achievements recently.
For example, they have shown outstanding performance in a project, were particularly profitable for the team, or for some other reason.
These Platinum developers retain their status for a certain amount of time and can take advantage of certain benefits during this period:
- bonus payments
- conference attendance
- work-free days
- more remote work
- whatever benefits you want to offer them
I think the current application of the junior and senior division is wrong.
It does not represent what it should.
It is disconnected from the underlying experience of a developer compared to the project he is working on. Senior is a prestige title that doesn’t have to be refreshed. The substance of dividing developers into different classes is still a good way to reduce risk in a project while increasing software quality. But then you have to measure it by the used technologies.
The key difference is to not group developers according to age and experience rather than performance.
Although these are undoubtedly essential and commendable aspects, this does not apply to software quality.
The approach with Silver, Gold, and Platinum developers based on a transparent baseline implements a visible and reachable barrier to move towards.
Last but not least, it keeps young and talented devs where they belong and thus more fairly.