I believe a senior engineer is more than just technical prowess. It is more than how many languages, best practices, or frameworks you know. I would say it's all about attitude. A senior engineer owns their work. Most engineers do what they are told, do the specific work, and hand it in like it is homework. A senior engineer takes full ownership of their work. They will deep dive into the problem, understand how their work fits in the system, understand what value their work brings to the business, and support their work after completion. Senior engineers have an attitude of growth for the business, such as seeking out how to make the business more efficient through technology, mentor and guide junior engineers and other senior engineers. A senior engineer owns their career, they are constantly learning and constantly trying to teach and help others around them.
same - i'm a senior on my team and my younger engineers often have a technical edge on me but our projects and our communication and our initiatives fall on me <3 i'm new to it and i'm loving the heck out of it.
This is BY FAR the best description I have ever come across of what a senior engineer is.
I used to have intense arguments with so-called managers about the importance of ownership and why you shouldn't treat engineers like replaceable cog wheels.
It can be resumed to the aspect of solving problems (because this is what we, the engineers do).
junior devs - are given a solution to a problem to implement
mid lvl devs - are given a problem to solve
senior devs - are given a project to find (and fix) problems
> senior devs (principle, etc, names different by company) - are asked before making a project what the problems will be.
The more experienced will be the less "do that" you'll have.
Based on what they do, usually:
junior devs - work on top of what the other devs do, usually modify stuff
mid devs - develop small chunks of code (ex classes in a framework)
senior devs - develop the basecode (ex the framework)
> senior devs - develop the architecture that the senior devs develop on, solve future problems and select the next technological direction of the project, find the future scalability issues, etc.
I don't believe in magic numbers rules like "you have to know x paradigms" "x programming languages" "x years of experience".
The "x years" is the biggest caveat, most of the devs I saw have "1 year repeated x times" of experience.
These are great points. I'll add that that some of the "what you do" is highly dependent on the team size and the problem at hand. It's perfectly reasonable to be hired on as a junior to essentially build something from scratch if it's a small company or an indie project or something. Would obviously be way less common with a big project.
I know from experience: My first real software development job was "CTO" of a two person company 😋
The levels of seniority make sense only where the other positions are filled, for my first jobs I was a Junior but I was also the most experienced so I had to do the Senior+ grade things (including software architecture, database and system design).
In my experience, the difference between senior and junior dev is that seniors get things done without further problems down the road.
They know what they don't know so they can ask the right questions and analyze a problem so they know what they have to add to their skillset to solve it.
They know what skills are just too big to add quickly, for example crypto, distributed systems, graphics, etc. So they know what to do by themselves and what to let specialists do for them.
Also, they know how to find answers to their question without hogging the time of other people.
know what they don't know IMHO not all questions seniors should know when a junior ask them something (technical or problems stuff) but they do know how to execute and analyze them better. Seniors aren't google.
From a technical perspective: Master at least 2 different paradigms (for example object-oriented and functional) and 2 different programming languages (for example Java and JavaScript). Why? When you learn to code, you usually start with one language. You are able to write application that will work, but you are somewhat limited. By learning multiple languages you can compare how things can be achieved. You learn the concepts and when you do that, you can pick other languages more easily.
From a non-technical perspective: Learn how to explain difficult things in a simple way. Why? Because most of your time you will be either teaching junior developers or talk with stakeholders and both of these groups have limited technical knowledge. You should prepare for lot of questions and lots of misunderstanding. If you have practice on your own children or try the "Explain like I'm five" channel here on dev.to :)
Unfortunately, I'm not as awake and pithy as I'd like to be this morning. So instead of a short paragraph directly talking about what "Senior" means, I'll tell two stories about plumbing.
Before I was born, my parents lived in a small rental house in Massachusetts. (East coast of the U.S.) One day, they found that the upstairs bath tub wouldn't drain. So they called a plumber.
The plumber looked around, tried to unclog the pipe, failed, but was able to figure out exactly where the clog was. Unfortunately, the blockage was inside a wall. The plumber said he'd have to break open the wall and replace that section of pipe. Once he was done, my parents would have to call a plasterer to repair the wall, and a painter to paint it.
My parents decided their landlord wouldn't like them breaking holes in the wall, so they called the landlord and asked what he wanted them to do.
The landlord laughed and told them to send the other plumber home, and that a new plumber would be there shortly.
The second plumber arrived, and agreed with the first plumber's assessment of where the clog was, but said there was no reason to break open the wall.
Instead, he went up on the roof, blocked the air vents, and ran water down the downstairs drains. Then he went back up on the roof, unblocked one of the air vents, and there was a tremendous POP! as the resulting pressure differential sucked the clog out of the pipe and out the main drain.
A mid-level engineer (the first plumber in this story) has a clear understanding of the problem and knows a way to fix it directly. The senior engineer (the second plumber) understood how to use the architecture of the whole system to resolve the issue.
The second story:
My wife and I wanted to replace the fixtures in our bathroom, and we hired a plumber to do the work. He removed the spout over the tub, and discovered that the pipe it was connected to was too short to attach the new spout. And when he tried to put the old spout back on, it stripped the threads on the pipe so that it couldn't be re-attached. Attempts to remove the pipe only further damaged it, compounding the problem.
The plumber told me he would have to remove the tile around the pipe so he could get a proper grip on it and remove & replace it.
I asked the plumber to work on other things around the house for an hour while I considered my options.
I called several local plumbing stores, asking them for solutions. They had none. I searched online for tools that would let me grip the pipe from the inside. I discovered internal pipe wrenches. A few more calls located a store that had a set. I bought the tools, returned to my bathroom and extracted the pipe with no trouble.
I behaved as a senior engineer in this case: when the proposed solution wasn't good enough, I took it upon myself to find new tools and techniques that could solve the problem properly. It's easy to look at a problem and think that the solution you know, however bad it might be, is the only option. As a senior engineer, that's not the end of the decision-making process, it's the beginning of the research & learning process.
I'm not sure if that brings any light to the question, but I hope so. Solid technical skills are certainly a requirement for a senior dev, but if all you have are technical skills, then you're still mid-level. A senior dev brings a more mature approach to problem solving, and has solid social skills for working with the team, especially in stressful situations. You're a mid-level dev when your boss is happy you're on the team. You're a senior dev when your team is happy you're on the team.
I think a lot of people here are focusing on what it means to be a "good developer" over a "senior developer". It's really important to think of what it means to be "senior" before focusing on the "developer" part of the title. When we think of what it means to be "senior" in other contexts, while not entirely meaning "oldest member(s) of a group," it definitely means seasoned and knowledgeable within that context.
A Senior at high school/college is going to know where everything is and have their own "tips" about various things to help them in that environment. They'll know when to show up on campus to get to that first class on time, the first day of class they can show up 5 minutes late with no penalty, etc. A Senior Accountant is going to know what rules you can and can't push to keep your financial filings from raising eyebrows. They'll know that eating out a lot with an $10 tab is going to raise more eyebrows than $50-100 a piece (don't quote me on this). Overall, they have specific knowledge that is environment specific that comes from plenty of experience.
So where does this fit in with a software developer? Senior devs know their environment (projects and scopes) and have a deep understanding of what they're responsible for. Their insight and work saves days, if not weeks, of research, prototyping, and deploying. This can come from some hardcore understanding of general programming topics, or by the standard tradition of being around for a long time and taking the lead on environment/project-defining work. Most importantly, that "senior" descriptor is contextual and may not apply across all projects.
I see being a senior developer as someone who yes, can do the technical work, but can also lead / self-manage projects. They may also step in turning their manager's absence. They have the freedom to work on longer-term or bigger projects compare to the junior devs.
I started writing software in 1984. Over the years I worked with many languages, technologies, and tools. I have been in leadership positions since the early 2000s, and in executive roles since 2014.
It is all relative. Senior is a relative measure, so it depends on who's around you. You are a senior engineer when more than 50% of the engineers that work with you are "more junior than you."
What does "more junior" means? Here is a possible definition:
Engineers are more junior than you if, in a given amount of time, they regularly find solutions that most experts would agree are overall noticeably worse than yours.
There was a post in dev.to earlier on-senior-engineers. I loved the term, "Mature Engineers" and the definition for it. Definitely worth reading it. :)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I believe a senior engineer is more than just technical prowess. It is more than how many languages, best practices, or frameworks you know. I would say it's all about attitude. A senior engineer owns their work. Most engineers do what they are told, do the specific work, and hand it in like it is homework. A senior engineer takes full ownership of their work. They will deep dive into the problem, understand how their work fits in the system, understand what value their work brings to the business, and support their work after completion. Senior engineers have an attitude of growth for the business, such as seeking out how to make the business more efficient through technology, mentor and guide junior engineers and other senior engineers. A senior engineer owns their career, they are constantly learning and constantly trying to teach and help others around them.
I want to hug you right now; this is poetry.
same - i'm a senior on my team and my younger engineers often have a technical edge on me but our projects and our communication and our initiatives fall on me <3 i'm new to it and i'm loving the heck out of it.
This is BY FAR the best description I have ever come across of what a senior engineer is.
I used to have intense arguments with so-called managers about the importance of ownership and why you shouldn't treat engineers like replaceable cog wheels.
I can be a senior given this criteria.
It can be resumed to the aspect of solving problems (because this is what we, the engineers do).
The more experienced will be the less "do that" you'll have.
Based on what they do, usually:
I don't believe in magic numbers rules like "you have to know x paradigms" "x programming languages" "x years of experience".
The "x years" is the biggest caveat, most of the devs I saw have "1 year repeated x times" of experience.
These are great points. I'll add that that some of the "what you do" is highly dependent on the team size and the problem at hand. It's perfectly reasonable to be hired on as a junior to essentially build something from scratch if it's a small company or an indie project or something. Would obviously be way less common with a big project.
I know from experience: My first real software development job was "CTO" of a two person company 😋
Yes I will add:
The levels of seniority make sense only where the other positions are filled, for my first jobs I was a Junior but I was also the most experienced so I had to do the Senior+ grade things (including software architecture, database and system design).
I think you mean principal not principle : )
In my experience, the difference between senior and junior dev is that seniors get things done without further problems down the road.
They know what they don't know so they can ask the right questions and analyze a problem so they know what they have to add to their skillset to solve it.
They know what skills are just too big to add quickly, for example crypto, distributed systems, graphics, etc. So they know what to do by themselves and what to let specialists do for them.
Also, they know how to find answers to their question without hogging the time of other people.
That's a great way to put it
know what they don't know IMHO not all questions seniors should know when a junior ask them something (technical or problems stuff) but they do know how to execute and analyze them better. Seniors aren't google.
From a technical perspective: Master at least 2 different paradigms (for example object-oriented and functional) and 2 different programming languages (for example Java and JavaScript). Why? When you learn to code, you usually start with one language. You are able to write application that will work, but you are somewhat limited. By learning multiple languages you can compare how things can be achieved. You learn the concepts and when you do that, you can pick other languages more easily.
From a non-technical perspective: Learn how to explain difficult things in a simple way. Why? Because most of your time you will be either teaching junior developers or talk with stakeholders and both of these groups have limited technical knowledge. You should prepare for lot of questions and lots of misunderstanding. If you have practice on your own children or try the "Explain like I'm five" channel here on dev.to :)
Unfortunately, I'm not as awake and pithy as I'd like to be this morning. So instead of a short paragraph directly talking about what "Senior" means, I'll tell two stories about plumbing.
Before I was born, my parents lived in a small rental house in Massachusetts. (East coast of the U.S.) One day, they found that the upstairs bath tub wouldn't drain. So they called a plumber.
The plumber looked around, tried to unclog the pipe, failed, but was able to figure out exactly where the clog was. Unfortunately, the blockage was inside a wall. The plumber said he'd have to break open the wall and replace that section of pipe. Once he was done, my parents would have to call a plasterer to repair the wall, and a painter to paint it.
My parents decided their landlord wouldn't like them breaking holes in the wall, so they called the landlord and asked what he wanted them to do.
The landlord laughed and told them to send the other plumber home, and that a new plumber would be there shortly.
The second plumber arrived, and agreed with the first plumber's assessment of where the clog was, but said there was no reason to break open the wall.
Instead, he went up on the roof, blocked the air vents, and ran water down the downstairs drains. Then he went back up on the roof, unblocked one of the air vents, and there was a tremendous POP! as the resulting pressure differential sucked the clog out of the pipe and out the main drain.
A mid-level engineer (the first plumber in this story) has a clear understanding of the problem and knows a way to fix it directly. The senior engineer (the second plumber) understood how to use the architecture of the whole system to resolve the issue.
The second story:
My wife and I wanted to replace the fixtures in our bathroom, and we hired a plumber to do the work. He removed the spout over the tub, and discovered that the pipe it was connected to was too short to attach the new spout. And when he tried to put the old spout back on, it stripped the threads on the pipe so that it couldn't be re-attached. Attempts to remove the pipe only further damaged it, compounding the problem.
The plumber told me he would have to remove the tile around the pipe so he could get a proper grip on it and remove & replace it.
I asked the plumber to work on other things around the house for an hour while I considered my options.
I called several local plumbing stores, asking them for solutions. They had none. I searched online for tools that would let me grip the pipe from the inside. I discovered internal pipe wrenches. A few more calls located a store that had a set. I bought the tools, returned to my bathroom and extracted the pipe with no trouble.
I behaved as a senior engineer in this case: when the proposed solution wasn't good enough, I took it upon myself to find new tools and techniques that could solve the problem properly. It's easy to look at a problem and think that the solution you know, however bad it might be, is the only option. As a senior engineer, that's not the end of the decision-making process, it's the beginning of the research & learning process.
I'm not sure if that brings any light to the question, but I hope so. Solid technical skills are certainly a requirement for a senior dev, but if all you have are technical skills, then you're still mid-level. A senior dev brings a more mature approach to problem solving, and has solid social skills for working with the team, especially in stressful situations. You're a mid-level dev when your boss is happy you're on the team. You're a senior dev when your team is happy you're on the team.
I think a lot of people here are focusing on what it means to be a "good developer" over a "senior developer". It's really important to think of what it means to be "senior" before focusing on the "developer" part of the title. When we think of what it means to be "senior" in other contexts, while not entirely meaning "oldest member(s) of a group," it definitely means seasoned and knowledgeable within that context.
A Senior at high school/college is going to know where everything is and have their own "tips" about various things to help them in that environment. They'll know when to show up on campus to get to that first class on time, the first day of class they can show up 5 minutes late with no penalty, etc. A Senior Accountant is going to know what rules you can and can't push to keep your financial filings from raising eyebrows. They'll know that eating out a lot with an $10 tab is going to raise more eyebrows than $50-100 a piece (don't quote me on this). Overall, they have specific knowledge that is environment specific that comes from plenty of experience.
So where does this fit in with a software developer? Senior devs know their environment (projects and scopes) and have a deep understanding of what they're responsible for. Their insight and work saves days, if not weeks, of research, prototyping, and deploying. This can come from some hardcore understanding of general programming topics, or by the standard tradition of being around for a long time and taking the lead on environment/project-defining work. Most importantly, that "senior" descriptor is contextual and may not apply across all projects.
I see being a senior developer as someone who yes, can do the technical work, but can also lead / self-manage projects. They may also step in turning their manager's absence. They have the freedom to work on longer-term or bigger projects compare to the junior devs.
A way of looking at this:
It is all relative. Senior is a relative measure, so it depends on who's around you. You are a senior engineer when more than 50% of the engineers that work with you are "more junior than you."
What does "more junior" means? Here is a possible definition:
Engineers are more junior than you if, in a given amount of time, they regularly find solutions that most experts would agree are overall noticeably worse than yours.
There was a post in dev.to earlier on-senior-engineers. I loved the term, "Mature Engineers" and the definition for it. Definitely worth reading it. :)