It's a slippery slope, especially with small agencies giving away titles due to their smaller scale.
Niels Bohr once said that, "An expert is a man who has made all of the possible mistakes that could be made in a very narrow field". And this sums up seniority in most areas out there.
- The senior developer can solve almost every technical problem
with little to no supervision.
- Junior developers, on the other hand, can only solve limited types of problems with a small subset of alternative solutions.
Disclosing a few essential nuggets in my latest video here. 🎥
What's your take on juniors vs. seniors in your industry?
00:00:07 - What is an expert?
00:02:14 - Senior vs Junior developers in practice
00:04:24 - How to define a career in software engineering
00:05:42 - Going through the learning curve
00:07:57 - What is really crucial even for seniors
[Tweet "Learning - continuous learning - is really crucial even for seniors."]
What is the actual difference between a junior software developer and a senior software developer?
I get this question frequently from juniors who really want to figure out how to become a senior or how long does it take to become a senior, or what is the actual path to becoming a senior developer. What's the quickest way to become a senior developer and whatnot. And, to be fully honest, different organizations are just handing titles for whatever reasons especially smaller teams
and smaller agencies especially less progressive companies where you can become a senior in just a matter of a year with the right attitude, just kind of standing out from the rest of the audience. This isn't really the case for larger organizations where they do have a pretty well-predefined company hierarchy but it's definitely the case in a smaller company.
What is an Expert?
So, Niels Bohr once said that, "An expert is a man who has made all of the possible mistakes that could be made in a very narrow field" - meaning that, experts are really people and I've already talked about experts and how flaky this word is so don't quote me on that. But, seniors and experienced people are the folks who have already gone through all the use cases in a very narrow field. They've made all the mistakes. They know what are the implications, what are the problems, what are the best practices and what will happen when you make mistakes.
And, as you can imagine, this means that to become an expert you have to go through the path that leads you to all those mistakes and as tricky as it may sound, it really means that you simply have to fail - fail often, fail a lot, without of course compromising prediction software. But once you go through all that part you can learn from your own mistakes and really figure out what are the best practices and the best ways to make it work.
Ideally, you aren't going to go through this path before you even start a job by working on pet projects, by reading lots of programming books and going to, reading, listening to podcasts and going to events and just trying to reduce the number of failures when you still need to go to all those different use cases - meaning that, you need to work on a large set of projects within an organization, understand the different issues, and a bunch of other things.
[Tweet "Fail often, fail a lot, without of course compromising prediction software."]
Senior vs Junior Developers in Practice
So, a difference in a practice or how to compare, kind of a junior or a senior, is a senior developer can solve almost every technical problem with little to no supervision and all that all is going to be well documented well tested with inline comments and everything else. So you can easily assign a complex task, a small project to even a mid-sized project to a senior developer and you are going to expect that they will comply with it. They're going to follow the regulations. If there is a problem, they are going to indicate it early on or commented well, documented and everything else.
Junior developers, on the other hand, can only solve limited types of problems with a small subset of alternative solutions - meaning that, if you give them a pattern and if you give them a framework and say, you need to replicate it 10 times, it is definitely doable. If it's simple, if it doesn't require too many dependencies - these are usually a junior developer's job.
When the Devs Approach a Task
So, think about, you give, let's say, rebuild WordPress or build a blogging tool and you give that to a junior developer on one hand and the senior developer. So, the junior developers are probably to say, if they know what programming language, what framework, they are going to say, "Yeah, I know Java so I'm going to build it with JSF or its print framework or something else. I'm going to make it work and you know is going to use Oracle because that's what I use and he's going to have different roles and yada yada." But then the senior software developers are going to say, "Wait, first, why do we need to do blogging tool? We already have plenty of those. It doesn't make a lot of sense. To make a decent blogging tool, you have to invest a lot of time, resources, QA. It's expensive."
How to Define a Career in Software Engineering
And with that in mind, really, the career in software engineering
is defined by the depth of knowledge and the breadth of experience. So we have the depth of knowledge - you really need to understand a lot about a different field and then you have the breadth of experience in dealing with different types of problems with your knowledge and just to plan your knowledge stack into different sorts of use cases. So, that's pretty much how it goes in a nutshell.
Junior developers, again, they are usually familiar with lower subset of paradigms, use cases problems and they don't yet know how to apply new paradigms here. And, most of them, if they have a problem, they're going to get stuck, or they're going to ask a senior or they're going to read something on forums which is not necessarily quite helpful.
Simply, pretty much you have to go through all that experience yourself and just get comfortable understanding what are the pros and cons of different tools, paradigms, design patterns, solutions, strategies, frameworks, and be able to analyze and understand what are the implications of using each and every one of those in different use cases because there is no right tool for every job. There are different tools for a reason. They serve different purposes for different audiences for different types of programs.
[Tweet "There is no right tool for every job"]
How to Determine Seniority
Sometimes, performance may be an indicator. Traffic could be user base, could be a bunch of other things or security, adaptiveness, number of people available in the organization who can build something other available tools online. What are the pros, what are the cons, what are the business implications of a specific case? And senior developers seem to have lots of experience to be able to comfortably make those assumptions and make actual strategic consulting in order to, again, make the right decision at the end of the day. So, that's more or less, the difference between junior and senior developers.
One other note that I'd like to make is that sometimes, senior developers in an organization could be less experienced programmers who have spent plenty of time within the organization because seniority in software engineering for the most part, in most companies, isn't related to the programmings skills you've got - programming knowledge, clean code, faster execution refactoring, fewer regressions, no technical debt and things like this.
Going Through the Learning Curve
But, in some organizations, there is the learning curve when you develop. Or, meaning that, if the learning curve is really steep, then new developers or even senior developers may start as mid-levels because they can't grasp the knowledge of a business and the business implications, the business context, the business structure, the business model, may be very unique to a certain extent, leading to making it hard for a new person to join in and at the same time, or, on the opposing again, you also have less experienced people who may be acclaimed as seniors simply because they may not be as strong on the technical standpoint but they may take the right and make the right decisions depending on context.
They may say, "well I only know, (just as a very rough example), I only know two or three technologies, or two or three frameworks, whatever it is, but I know that in this case, we need to do this because it's a very complicated case. We've already worked with those plants three times over the past five years. We know that they are very specific here. This is going to help us do this. This is going to improve our efficiency here. We already have internal systems that do this and whatnot."
What Is Really Crucial Even for Seniors
This is also the reason why CTOs are not necessarily the best developers in the company. And quite the opposite actually in plenty of companies, CTOs are probably, kind of mid-level skillset or so technically. Or, at least above average. But, they simply have the ability to represent the entire information technology infrastructure, how it tailors to the clients, what the clients need, business requirements, business expectations, being able to pick the right solution depending on timeframes and budget and resources and other things that senior software engineers also have to understand for the most part. The more they understand them, the more possible for them to step up the ladder even further
So that's about software engineers. Again, there are different concepts and different ways to represent each one of them and companies may vary. They have different layers and different forms of assessments. But, if you're a junior engineer who wants to really become more senior, practice makes perfect. And also, understanding business requirements, understanding how important is to produce clean code, learning - continuous learning - is really crucial even for seniors and just becoming better and better with every single complete project.Read More