Rethinking of Software Engineer Levels

Junior, Middle, and Senior are how a Software Engineer (SWE) career looks, right? But what does this mean? Different companies have different definitions, so borders are blurred. In this article, I’m going to share with you my considerations regarding levels in software engineering and try to rethink what the path might look like. A kind of disclaimer: this is only my vision and not the ultimate truth, so I’m happy to hear your feedback.

What Is Wrong With Current Levels

They are polysemantic. From what I can see on the market, from my experience, and those I tracked, different companies have different definitions of Junior/Middle/Senior engineers. Some of them have even more: Staff, Principal, and Distinguished engineers to have a better expression of seniority of highly experienced individual contributors. One of the key problems with “Senior SWE” is that people with absolutely different experiences might get this title. Technically, a Senior Mobile Engineer is not the same as a Senior Frontend Engineer or a Senior Backend Engineer. There are different specializations, and in general, that would not be correct to move from SME to SBE without any downgrade, but why? Logic dictates soft skills are the same, and life experience is the same as well (because it is still the same person). Only one thing changed - the ability to solve problems. You might be an extremely experienced Mobile Developer, but you have never solved issues within a web browser, problems with distributed systems, etc. So, let me take this particular criterion as a separator between levels. The first milestone is simple problem-solving.

1. Pathfinder: Random-Way Simple Problem Solver

Originally, a pathfinder was someone who found or created a path through an unexplored or wild area. This term was often used to describe explorers or scouts who ventured into unknown territories, paving the way for others to follow. They were crucial in mapping new lands and navigating through difficult terrains.

Sometimes, I hear, “You have to look after Junior dev, but the Middle one is working fully on one’s own." Is that true? Not. People on the Middle level usually do not care about the wider picture of the world, so they cannot make the best decision just by design. In any way, you need to look after every developer to help to stay within the project’s range of norms and not to allow to leak of over-engineered solutions. So, Random-way Simple Problem Solver (author: RwSPS short scares me as well), a.k.a Pathfinder, is able to solve atomic problems (not decomposable in a relevant way). Think about one task that someone else prepared for Pathfinder. Would you name it Junior? Middle? It doesn’t matter because you measure the results of these guys by their ability to solve business problems. Ok, Pathfinder will solve your problems. SOMEHOW, is it just enough? It depends. If you are creating a short-living project and all tasks are straightforward, a group of pathfinders will probably be enough. But for a long-living project, you need to solve problems, especially in a simple way. Otherwise, maintenance becomes a nightmare.

2. Specialist: Simple-Way Simple Problem Solver

Specialist has deep, extensive knowledge and expertise in a specific field. Specialists are highly skilled in their area, often focusing on a narrow aspect of a discipline.

Simple-way Simple Problem Solver (SwSPS), a.k.a Specialist, is the next level after Pathfinder. The key difference is that Specialists have enough experience to solve simple problems predictably in a simple way. That might be a proper framework/library usage, assembling solutions from existing components. For example:

• If Pathfinder tries to handle nulls by IFs, the Specialist will use nullable types to strict nullability by design.
• If Pathfinder might add logging at the start and the end of every method explicitly, Specialists will just use Aspect Oriented Programming (those who believe that AOP is unacceptable should throw tomatoes in the comments)
• If Pathfinder might refactor ten lines of code one by one. Specialists will use IDE’s multi-cursor to introduce changes in many places simultaneously.

With experience and seeing more and more code that works, mastering tooling Specialists will provide more reliable solutions faster. This level is limited to atomic tasks only. Sounds like the next growth point!

3. Generalist: Random-Way Complex Problem Solver

Generalist solves problems by synthesizing and applying knowledge from various domains. They are often effective in dealing with new or unforeseen challenges due to their adaptable and flexible approach.

What is outside of a simple problem? Other simple problems! The source of all these simple ones is one or more complex issues that software engineers have to decompose before they start working. Let’s define a complex problem.

In the context of this article, a complex problem is a problem that might be decomposed for the sake of improved predictability of implementation time. Also, a complex problem might consist of other complex problems that should be decomposed eventually.

The key difference between a Random-way Complex Problem Solver (Generalist) and a Simple-way Simple Problem Solver (Specialist) is scale. A generalist is still able to solve simple problems in a simple way, but experience relevant to complex problems is not enough to follow the same approach for complex tasks. Here are a few examples:

• Generalists might design a new complex system starting with microservices and ignoring the fact that the customer-facing systems have <10 unique users in total yet.
• Generalists might start from on-premise db instead of just relying on managed services even if requirements do not specify that need and the key motivation is past experience.
• Generalists might bring redundant complex technologies from the previous company, ignoring the fact that the previous and the current ones are at different stages of business maturity.

Getting experience in solving complex problems, Generalist starts finding ways to quickly get simpler solutions, and it means that the next level is coming.

4. Navigator: Simple-Way Complex Problem Solver

Historically, navigators were crucial on ships and aircraft. In modern contexts, the term is used in roles requiring strategic planning and direction-setting, like in project management or leadership positions in companies.

Counterintuitive that solving problems in a simple way is more complex, but the nature behind this fact is ignorance. At the beginning of your path, you have a high level of unawareness about already available solutions and ready-to-go components. Sometimes, they appear while you develop your own.

Simple-way Complex Problem Solvers (Navigator) can deeply and seamlessly dive into an unknown environment, map their experience, find a simple solution, and basically have this expectation of something available instead of reinventing the wheel. A few examples:

• Navigator would never start by creating a marketplace if the business is about selling things but not SaaS.
• Navigator would research available opportunities before planning and designing.
• Navigator is fine with Google Sheets + Forms to launch the business.
• Navigator provides relevant solutions to the current business stage.

Profits of the Alternative Level Classification

Relative to the classical level set, this gradation:

• Is more transparent in terms of specific business requirements.
• Is measurable in practical tasks.
• Does correlate with experience.
• Does align expectations of a particular company.

Conclusion

The past “Senior” job title doesn’t say anything about your real ability to solve complex problems in the new company. People should align their skills with reality and not pretend to be seniors only because they already have this title.

Movement through Pathfinder -> Specialist -> Generalist -> Navigator requires constant self-educating, so don’t waste your time.

And please, don’t tell me that I showed myself as Pathfinder when describing such a simple topic in such a complex classification :)