Types of Senior Software Engineers
I’ve been thinking a lot lately about my career over the years and about my path from junior developer to senior software engineer. There isn’t one single path for progression amongst software developers. Sometimes the end goal wasn’t even a goal and just happened. Sometimes it’s something the dev has been striving for since they started coding.
In this article, I’m going to try to articulate the four most common types of Senior Software Engineers that I’ve noticed over time. This list isn’t particularly exhaustive, but it might be sufficient to categorize everyone. Some may fit into multiple categories as well, but not necessarily. Keep in mind, none of these categories are technically bad to be in. All of them allow for a highly-paid lifetime career with plenty of opportunity. I definitely have my own opinions of which one is the best though ;) which I’ll certainly make apparent as we go.
The Specialist
Possibly the most common Senior Software Engineer is The Specialist. This engineer started by learning a language in college and decided they had to master that language to be truly valuable at any company.
There’s a stigma in the software development world about being the “jack of all trades, but master of none.” For some reason developers feel like if they aren’t mastering a particular language then no employer will want to hire them. “I’m a C# developer” or “I’m a Java developer” are common ways to introduce yourself. When searching for jobs, this engineer only searches for specific language requirements, or even specific versions of specific languages (Java 8+ for example).
The Specialist is highly beneficial to any company as they have a strong understanding of the particulars of their language. They’re the engineer that knows of a strange obscure API method that no one else has ever heard of, which solves an enormous problem promptly and efficiently. They are revered by those new to the language and they are ideal mentors. But let’s not forget, specialization does create silos.
Pigeon-holing
This is probably the biggest concern for The Specialist. What happens if your preferred stack dies off? Or the company you work for is trying to pivot to support a different framework? Well, nothing really. The Specialist is at a point where they understand programming and logic, not simply a single language. Even if they’ve never used another programming language (unlikely) they’ll be able to pick up a new one without much difficulty.
There is, however, something to say about being pigeon-holed into a specific language. Potential opportunities will be harder to find. Recruiters won’t look at your profile as much as others. Plus you won’t necessarily have the proper tools for each individual scenario, even if the tool you have works well enough.
The Polyglot
As a stark contrast to The Specialist, we have The Polyglot. The title says it all. The Polyglot is proficient in many languages and frameworks, but a master of none. Luckily in a fast-paced environment (especially if this engineer doesn’t stay at a company for too long) there’s little need to be a master of a single language.
In circumstances where Python may be a more efficient way to solve a problem, The Polyglot can think back to that open source contribution they did for a random Python project to help them learn it. If they need to make a Windows app in a Java shop, they can use C# and WPF instead. Why not use containers in the real world if you spent some time setting up a Docker/Kubernetes cluster in your free time? You have the skills and know it can be better for your current use case, so do it!
Some of the difficulty for The Polyglot comes in approval from the company. If the company you work for pays for Microsoft licensing, they probably don’t want to use Docker containers when all the ops staff is trained on Windows Server and IIS. This is the most difficult situation for The Polyglot. They can feel discouraged when they know there’s a better option to use, but they simply aren’t allowed to. Maybe then it’s the time to ask forgiveness rather than permission ;) Prove out your proof-of-concept and use data.
The biggest benefit for The Polyglot is the mentality of continuous learning and improvement. Not paying attention to new technologies can be crippling for the career of a software engineer. Things change way too quickly. We have to keep up. Learning new tech makes you more attractive to companies that desire a broad skillset to solve problems in the “best” way instead of just their way.
Larry
Early on when I started developing software professionally, there was another engineer working on our team. He was much older than the rest of us and his title was Junior Java Developer. I was always confused as to why he was considered a Junior dev when he had talked about developing for decades! It turns out that Larry’s software career was mostly in older languages. He started programming in Cobol and later Pascal. He always had steady work at older companies until he didn’t. It was time for him to move on from those languages, but he never kept up with newer technology. His only choice was to accept a Junior Java Developer role and learn a very different way of programming.
To avoid the Larry Effect, The Polyglot is constantly learning and paying attention to new tech trends. Angular becoming popular? Time to learn some Angular! (Be careful with too many Javascript frameworks though, since most die in a few days haha)
The They’ve-Been-Here-Forever
This next category can easily fit into The Specialist or The Polyglot depending on the work they’ve been doing. The key point is that they’re doing the work they’re given. This is the most passive of the Senior Software Engineer categories. They’ve been at the company for 5 years, then 10 years, then 15 years. At some point a promotion is inevitable. Don’t get me wrong, this isn’t a bad approach, just passive. They aren’t striving for that promotion, or if they are they aren’t letting on that they are. The They’ve-Been-Here-Forever isn’t bothering their manager about a promotion or title change, but they are certainly learning and providing value to the company.
Depending on the problems this engineer has been given to solve, they may be specializing in a particular language, or they may be doing a broad range of tasks. The benefit of The They’ve-Been-Here-Forever is domain knowledge. This engineer has an intimate knowledge of the systems the company relies on daily. They’ve been around long enough to develop systems-level-thinking, which is how each piece of technology works in conjunction with every other piece. They know the lines of communication between services, but even more important, they know the lines of communication between people.
Understanding people is critical to making useful products. When you’re working with people for years, you know how to communicate effectively. You know what things to say, but also when you should tiptoe around a subject. It’s called manipulation and The They’ve-Been-Here-Forever usually understands how to manipulate those around them to solve problems.
The company also highly values this category. It costs much more to hire someone new rather than retain someone. The company values those who have been around for a while especially if they pay attention to the domain and lines of communication.
They’ve-Been-In-Software-Forever
This category doesn’t only apply to those at a company for a long time. It can also apply to engineers that have been engineering for a long time, but don’t stand out in other ways. They are passive in their type of work. They don’t go to local user groups. They don’t contribute to open source. They do their work during work hours and produce value, but don’t normally go above and beyond. The “Here” in They’ve-Been-Here-Forever for this side of the category is “the software industry”.
It’s hard to say if this side of the category is better or worse. Some would say better due to having more experience across multiple companies to see different ways of thinking and working. Some would say worse because domain knowledge at a company for a long time would be more valuable. My personal opinion is that too long at a single company causes stagnation and laziness, but I’ll explore that in a separate article.
The Demoted
This category is much less common that the other three. The Demoted used to be a manager, or a director, or a vice president, or even the CIO/CTO. Changes in the company caused them to be “demoted” back to an engineering role instead of a leadership role (I say demoted in quotes because I don’t really consider it a demotion, just a role change).
The company is taking a risky chance by creating The Demoted. Often with leadership comes pride. If the leader in question is too prideful to go back to an engineering role, they might leave along with their domain knowledge and years at the company to go elsewhere. They company also may not have a choice. A department or project could be failing and they need to restructure without enough management positions. The Demoted will then be allowed a spot as an engineer again rather than staying in management.
The Demoted usually is in a very unique place to provide interesting value to the company. They have a completely different outlook of the bigger picture than a typical dev. They’ve been in meetings with real shareholders and C-suite employees. There’s context they’ve had that is less understandable to the other categories and that makes them quite valuable in a more hands-on role. If they see it that way, then they’ll stay at the company, but that also depends on their loyalty to the company as a whole.
Sometimes The Demoted was created by choice! Sometimes managers didn’t realize they missed coding so much and it’s a relief to finally be back in a cube pounding out keystrokes all day. Managing people isn’t an easy task (not that coding is) and it takes a certain personality to do it well.
My Ideal Engineer
I believe there’s no one category that actually is best. A combination of all of them would be most valuable.
- Deep knowledge of a main language (The Specialist)
- The right tools for the right situations (The Polyglot)
- Domain knowledge and industry knowledge (The They’ve-Been-Here-Forever)
- Big picture context and insight (The Demoted)
There are positives and negatives for each category. Most good Senior Engineers understand that and know what to look for to advance their career and become more valuable.
Again, this list isn’t exhaustive, but they are the main categories I’ve seen throughout my career and easily allow room for everyone to fit into. If there are more interesting categories you think I missed, let me know in the comments :)
Happy coding!
