#8: Rethinking of Software Engineer Levels
From Junior to CTO Weekly Thoughts
Junior, Middle, Senior is how a Software Engineer (SWE) career looks, right? But what does this mean? Different companies have different definitions, so borders are blurred. In this issue, 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 & Distinguished engineers to have a better expression of seniority of highly experienced individual contributors. One of the key problems with “Senior SWE”: people with absolutely different experience might get this title and technically, Senior Mobile Engineer is not the same as Senior Frontend Engineer and not the same as 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 never solved issues within a web browser, problems with distributed systems, and so on and so forth. So let me take this particular criterion as a separator between levels. The first milestone is simple problem-solving.
#1: Random-way Simple Problem Solver
Sometimes I hear, “You have to look after Junior dev, but 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 (RwSPS) is able to solve atomic problems (not decomposable in a relevant way). Think about one task that someone else prepared for RwSPS. 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, RwSPS 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 RwSPS 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: Simple-way Simple Problem Solver
Simple-way Simple Problem Solver (SwSPS) is the next level after RwSPS. The key difference is that SwSPS has 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 RwSPS might try to handle nulls by IFs, SwSPS will use nullable types to strict nullability by design
If RwSPS might add logging at the start and the end of every method explicitly, SwSPS will just use Aspect Oriented Programming
If RwSPS might refactor ten lines of code one by one. SwSPS will use IDE’s multi-cursor to introduce changes in many places simultaneously.
Having experience and seeing more and more code that works, mastering tooling SwSPS will provide more reliable solutions faster. This level is limited to atomic tasks only. This sounds like the next growth point.
#3: Random-way Complex Problem Solver
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 Random-way Complex Problem Solver (RwCPS) and Simple-way Simple Problem Solver is scale. PwCPS 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 a complex problem. Here are a few examples:
RwCPS might design a new complex system starting with microservices. Ignoring the fact that the customer-facing systems have <10 unique users in total yet.
RwCPS 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.
RwCPS 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, RwCPS start finding ways to quickly get simpler solutions and it means that the next level is coming.
#4: Simple-way Complex Problem Solver
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 Solver (SwCPS) 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,
SwCPS would never start creating a marketplace if the business is about selling things but not SaaS.
SwCPS would research available opportunities before planning and designing.
SwCPS is fine with Google Sheets + Forms to launch the business.
SwCPS provides relevant solutions to the current business stage.
Profits of the alternative level classification
Relative to the classical level set, these levels are:
More Transparent
Measurable
Correlate with experience
Align expectations
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 a senior only because they already have this title.
Movement through RwSPS → SwSPS → RwCPS → SwCPS requires constant self-educating, so don’t waste your time.
And please, don’t tell me that I showed myself as RwSPS when describing such a simple topic in such a complex classification 🤓
It's an interesting take on grading programmers. I think, the Junior-Middle-Senior levels has more to do with technology knowledge, and this levels - with technology using. So both these rulers are useful))