Senior vs Proficient
-
I'm not sure I can find the articles relating to this difference I am trying to figure out in my head. When discussing what a Senior Software Developer/Engineer should be and do, the 2 things that that stick out relate to Training Juniors and Doing multiple things (being either projects or multiple languages) So I am split on that 1, being aware of multiple languages is like having multiple tools in the workshop. Knowing that another tool might be better fit to the job. This seems to limit a proficient person. Someone that say is expert in C#.net back end. They can easily say No if a job is proposed and wanting C#.net to be the implementation, but maybe not 100% on offering a different solution The make code and systems which are solid at launch. highly maintainable by others, and delivered on time that they had a hand in proposing. But that person is not "senior" because not multiple languages. Will only take 1 job on at a time. Can work in a team but not as classic "mentor", happy to share knowledge but not the Padawan/Master strictness. Is there another term for this career path, Mastery or Proficiency, which is slightly different, or is the Senior concept a push over from other career structures.
-
I'm not sure I can find the articles relating to this difference I am trying to figure out in my head. When discussing what a Senior Software Developer/Engineer should be and do, the 2 things that that stick out relate to Training Juniors and Doing multiple things (being either projects or multiple languages) So I am split on that 1, being aware of multiple languages is like having multiple tools in the workshop. Knowing that another tool might be better fit to the job. This seems to limit a proficient person. Someone that say is expert in C#.net back end. They can easily say No if a job is proposed and wanting C#.net to be the implementation, but maybe not 100% on offering a different solution The make code and systems which are solid at launch. highly maintainable by others, and delivered on time that they had a hand in proposing. But that person is not "senior" because not multiple languages. Will only take 1 job on at a time. Can work in a team but not as classic "mentor", happy to share knowledge but not the Padawan/Master strictness. Is there another term for this career path, Mastery or Proficiency, which is slightly different, or is the Senior concept a push over from other career structures.
maze3 wrote:
C#.net
Of course, a senior developer would know that there's no such thing as "C#.net". ;P
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
I'm not sure I can find the articles relating to this difference I am trying to figure out in my head. When discussing what a Senior Software Developer/Engineer should be and do, the 2 things that that stick out relate to Training Juniors and Doing multiple things (being either projects or multiple languages) So I am split on that 1, being aware of multiple languages is like having multiple tools in the workshop. Knowing that another tool might be better fit to the job. This seems to limit a proficient person. Someone that say is expert in C#.net back end. They can easily say No if a job is proposed and wanting C#.net to be the implementation, but maybe not 100% on offering a different solution The make code and systems which are solid at launch. highly maintainable by others, and delivered on time that they had a hand in proposing. But that person is not "senior" because not multiple languages. Will only take 1 job on at a time. Can work in a team but not as classic "mentor", happy to share knowledge but not the Padawan/Master strictness. Is there another term for this career path, Mastery or Proficiency, which is slightly different, or is the Senior concept a push over from other career structures.
Proficient: I can do hard stuff. Senior: I can do hard stuff but 99% of my bugs will be stupid stuff like "==" instead of "=" beacuse of seniliority.
GCS d--(d-) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
-
maze3 wrote:
C#.net
Of course, a senior developer would know that there's no such thing as "C#.net". ;P
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
I'm not sure I can find the articles relating to this difference I am trying to figure out in my head. When discussing what a Senior Software Developer/Engineer should be and do, the 2 things that that stick out relate to Training Juniors and Doing multiple things (being either projects or multiple languages) So I am split on that 1, being aware of multiple languages is like having multiple tools in the workshop. Knowing that another tool might be better fit to the job. This seems to limit a proficient person. Someone that say is expert in C#.net back end. They can easily say No if a job is proposed and wanting C#.net to be the implementation, but maybe not 100% on offering a different solution The make code and systems which are solid at launch. highly maintainable by others, and delivered on time that they had a hand in proposing. But that person is not "senior" because not multiple languages. Will only take 1 job on at a time. Can work in a team but not as classic "mentor", happy to share knowledge but not the Padawan/Master strictness. Is there another term for this career path, Mastery or Proficiency, which is slightly different, or is the Senior concept a push over from other career structures.
"Proficient" : "I can do this stuff".
"Senior" : "I get paid more"."I have no idea what I did, but I'm taking full credit for it." - ThisOldTony "Common sense is so rare these days, it should be classified as a super power" - Random T-shirt AntiTwitter: @DalekDave is now a follower!
-
I'm not sure I can find the articles relating to this difference I am trying to figure out in my head. When discussing what a Senior Software Developer/Engineer should be and do, the 2 things that that stick out relate to Training Juniors and Doing multiple things (being either projects or multiple languages) So I am split on that 1, being aware of multiple languages is like having multiple tools in the workshop. Knowing that another tool might be better fit to the job. This seems to limit a proficient person. Someone that say is expert in C#.net back end. They can easily say No if a job is proposed and wanting C#.net to be the implementation, but maybe not 100% on offering a different solution The make code and systems which are solid at launch. highly maintainable by others, and delivered on time that they had a hand in proposing. But that person is not "senior" because not multiple languages. Will only take 1 job on at a time. Can work in a team but not as classic "mentor", happy to share knowledge but not the Padawan/Master strictness. Is there another term for this career path, Mastery or Proficiency, which is slightly different, or is the Senior concept a push over from other career structures.
My definition of a Senior Developer is one that does not need help. But I get your point. I hired a Senior Developer years ago but he wanted a lot of hand holding, not writing code, but in knowing what to work on next. He was still Senior because he did not need help writing code, but he lacked a lot of skills other Senior Developers have.
-
I'm not sure I can find the articles relating to this difference I am trying to figure out in my head. When discussing what a Senior Software Developer/Engineer should be and do, the 2 things that that stick out relate to Training Juniors and Doing multiple things (being either projects or multiple languages) So I am split on that 1, being aware of multiple languages is like having multiple tools in the workshop. Knowing that another tool might be better fit to the job. This seems to limit a proficient person. Someone that say is expert in C#.net back end. They can easily say No if a job is proposed and wanting C#.net to be the implementation, but maybe not 100% on offering a different solution The make code and systems which are solid at launch. highly maintainable by others, and delivered on time that they had a hand in proposing. But that person is not "senior" because not multiple languages. Will only take 1 job on at a time. Can work in a team but not as classic "mentor", happy to share knowledge but not the Padawan/Master strictness. Is there another term for this career path, Mastery or Proficiency, which is slightly different, or is the Senior concept a push over from other career structures.
Seems to me that we had these ratings, graded from senior to junior: Leaps tall buildings in a single bound Must take a running start to leap over tall buildings Can only leap over a short building with no spires Crashes into building when attempting to jump over them Cannot recognize buildings at all, not to mention jump. :)
>64 If you can keep your head while those about you are losing theirs, perhaps you don't understand the situation.
-
I'm not sure I can find the articles relating to this difference I am trying to figure out in my head. When discussing what a Senior Software Developer/Engineer should be and do, the 2 things that that stick out relate to Training Juniors and Doing multiple things (being either projects or multiple languages) So I am split on that 1, being aware of multiple languages is like having multiple tools in the workshop. Knowing that another tool might be better fit to the job. This seems to limit a proficient person. Someone that say is expert in C#.net back end. They can easily say No if a job is proposed and wanting C#.net to be the implementation, but maybe not 100% on offering a different solution The make code and systems which are solid at launch. highly maintainable by others, and delivered on time that they had a hand in proposing. But that person is not "senior" because not multiple languages. Will only take 1 job on at a time. Can work in a team but not as classic "mentor", happy to share knowledge but not the Padawan/Master strictness. Is there another term for this career path, Mastery or Proficiency, which is slightly different, or is the Senior concept a push over from other career structures.
I think the only "senior" developers I have seen were called that (and probably earned accordingly) because they were old or with the company for many years. It never said anything about their skill level. They always underwhelmed me with their lack of basic knowledge of any tech after approx. 2005. Doing the same thing for 20 years != 20 years of experience. A common misconception, it seems :sigh:
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
I'm not sure I can find the articles relating to this difference I am trying to figure out in my head. When discussing what a Senior Software Developer/Engineer should be and do, the 2 things that that stick out relate to Training Juniors and Doing multiple things (being either projects or multiple languages) So I am split on that 1, being aware of multiple languages is like having multiple tools in the workshop. Knowing that another tool might be better fit to the job. This seems to limit a proficient person. Someone that say is expert in C#.net back end. They can easily say No if a job is proposed and wanting C#.net to be the implementation, but maybe not 100% on offering a different solution The make code and systems which are solid at launch. highly maintainable by others, and delivered on time that they had a hand in proposing. But that person is not "senior" because not multiple languages. Will only take 1 job on at a time. Can work in a team but not as classic "mentor", happy to share knowledge but not the Padawan/Master strictness. Is there another term for this career path, Mastery or Proficiency, which is slightly different, or is the Senior concept a push over from other career structures.
my understanding of the real definition of "senior" is: 1. needs very little assistance, if at all, to get their work task completed. 2. mentors and reviews entry level and junior developers/programmers/engineers/whatever. 3. is part of the system architecture and design process and decision making. what I have discovered is more in line with what Sander has posted: people who have been with the company a long time. I have also observed people who have been in the business for a certain amount of years and these people think that gives them the right to be called "senior", when it fact, they are terrible at what they do and are anything but senior. at the end of the day, it really doesn't matter anymore.
-
I'm not sure I can find the articles relating to this difference I am trying to figure out in my head. When discussing what a Senior Software Developer/Engineer should be and do, the 2 things that that stick out relate to Training Juniors and Doing multiple things (being either projects or multiple languages) So I am split on that 1, being aware of multiple languages is like having multiple tools in the workshop. Knowing that another tool might be better fit to the job. This seems to limit a proficient person. Someone that say is expert in C#.net back end. They can easily say No if a job is proposed and wanting C#.net to be the implementation, but maybe not 100% on offering a different solution The make code and systems which are solid at launch. highly maintainable by others, and delivered on time that they had a hand in proposing. But that person is not "senior" because not multiple languages. Will only take 1 job on at a time. Can work in a team but not as classic "mentor", happy to share knowledge but not the Padawan/Master strictness. Is there another term for this career path, Mastery or Proficiency, which is slightly different, or is the Senior concept a push over from other career structures.
I reject the premise of the question.
-
I'm not sure I can find the articles relating to this difference I am trying to figure out in my head. When discussing what a Senior Software Developer/Engineer should be and do, the 2 things that that stick out relate to Training Juniors and Doing multiple things (being either projects or multiple languages) So I am split on that 1, being aware of multiple languages is like having multiple tools in the workshop. Knowing that another tool might be better fit to the job. This seems to limit a proficient person. Someone that say is expert in C#.net back end. They can easily say No if a job is proposed and wanting C#.net to be the implementation, but maybe not 100% on offering a different solution The make code and systems which are solid at launch. highly maintainable by others, and delivered on time that they had a hand in proposing. But that person is not "senior" because not multiple languages. Will only take 1 job on at a time. Can work in a team but not as classic "mentor", happy to share knowledge but not the Padawan/Master strictness. Is there another term for this career path, Mastery or Proficiency, which is slightly different, or is the Senior concept a push over from other career structures.
Senior is a job title. Proficient is the ability to do the job. The two should be (but too often are not) related.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
-
I'm not sure I can find the articles relating to this difference I am trying to figure out in my head. When discussing what a Senior Software Developer/Engineer should be and do, the 2 things that that stick out relate to Training Juniors and Doing multiple things (being either projects or multiple languages) So I am split on that 1, being aware of multiple languages is like having multiple tools in the workshop. Knowing that another tool might be better fit to the job. This seems to limit a proficient person. Someone that say is expert in C#.net back end. They can easily say No if a job is proposed and wanting C#.net to be the implementation, but maybe not 100% on offering a different solution The make code and systems which are solid at launch. highly maintainable by others, and delivered on time that they had a hand in proposing. But that person is not "senior" because not multiple languages. Will only take 1 job on at a time. Can work in a team but not as classic "mentor", happy to share knowledge but not the Padawan/Master strictness. Is there another term for this career path, Mastery or Proficiency, which is slightly different, or is the Senior concept a push over from other career structures.
(Senior) Programmer Analyst. Can wear multiple hats. Bridges the user - programmer gap. I'd say most "junior" programmers are weak / lax in analysis and design; so if you find one that can, he's a "senior". There are probably senior junior programmers out there that may become senior senior programmers one day.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it. ― Confucian Analects: Rules of Confucius about his food
-
I'm not sure I can find the articles relating to this difference I am trying to figure out in my head. When discussing what a Senior Software Developer/Engineer should be and do, the 2 things that that stick out relate to Training Juniors and Doing multiple things (being either projects or multiple languages) So I am split on that 1, being aware of multiple languages is like having multiple tools in the workshop. Knowing that another tool might be better fit to the job. This seems to limit a proficient person. Someone that say is expert in C#.net back end. They can easily say No if a job is proposed and wanting C#.net to be the implementation, but maybe not 100% on offering a different solution The make code and systems which are solid at launch. highly maintainable by others, and delivered on time that they had a hand in proposing. But that person is not "senior" because not multiple languages. Will only take 1 job on at a time. Can work in a team but not as classic "mentor", happy to share knowledge but not the Padawan/Master strictness. Is there another term for this career path, Mastery or Proficiency, which is slightly different, or is the Senior concept a push over from other career structures.
Disclaimer: I'm probably more of a developer than anything, but I've held senior positions for most of that time. Also I've got to talk about myself a bit here because it's only fair you know how I came by my information. I would consider someone senior if they were comfortable in the following roles (whether or not they will be doing them in a particular position): 1. They should be good at being a team lead, which requires some amount of project management 2. They should be able to supervise and mentor (see #1) 3. They should be able to be critical in making hiring assessments that benefit the company 4. They should be a good liaison between management and the software team 5. They need to be good at communication at a high level (see #4) #4/5 is one that was the most challenging for me, because I'm very technical and analytical, but I was good at the first two in large part because developers tend to respect me professionally - i can develop as well as lead a team and manage a project. I'm good at the 3rd one because I'm good at assessing people's technical abilities. This is probably overall why I've been in those roles. I hope that helps. ETA: It seems some people here have had different experiences with what people expect from senior developers. I was working at consulting firms that would hire at senior level and expect something very much like the above from anyone that they hired at that payscale.
Real programmers use butterflies
-
I think the only "senior" developers I have seen were called that (and probably earned accordingly) because they were old or with the company for many years. It never said anything about their skill level. They always underwhelmed me with their lack of basic knowledge of any tech after approx. 2005. Doing the same thing for 20 years != 20 years of experience. A common misconception, it seems :sigh:
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
I've found differently when I worked at consulting firms like sogeti and emc. The would hire at the senior level and pay accordingly, but they expected particular skills, bordering on project management, and definitely including team lead abilities.
Real programmers use butterflies
-
Disclaimer: I'm probably more of a developer than anything, but I've held senior positions for most of that time. Also I've got to talk about myself a bit here because it's only fair you know how I came by my information. I would consider someone senior if they were comfortable in the following roles (whether or not they will be doing them in a particular position): 1. They should be good at being a team lead, which requires some amount of project management 2. They should be able to supervise and mentor (see #1) 3. They should be able to be critical in making hiring assessments that benefit the company 4. They should be a good liaison between management and the software team 5. They need to be good at communication at a high level (see #4) #4/5 is one that was the most challenging for me, because I'm very technical and analytical, but I was good at the first two in large part because developers tend to respect me professionally - i can develop as well as lead a team and manage a project. I'm good at the 3rd one because I'm good at assessing people's technical abilities. This is probably overall why I've been in those roles. I hope that helps. ETA: It seems some people here have had different experiences with what people expect from senior developers. I was working at consulting firms that would hire at senior level and expect something very much like the above from anyone that they hired at that payscale.
Real programmers use butterflies
With regard to your 5 points, I agree with each more strongly as you go down the list. If someone is really good at developing code, #1 and the supervision part of #2 can be outsourced, for much the same reasons that it would be wasteful to have that person clean toilets. :laugh:
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
With regard to your 5 points, I agree with each more strongly as you go down the list. If someone is really good at developing code, #1 and the supervision part of #2 can be outsourced, for much the same reasons that it would be wasteful to have that person clean toilets. :laugh:
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing.Don't get me wrong, I don't think it's the best use of my time either, but it's also something that helps you keep teams together. And having that skill .. well let's just say there are a lot of soft-skills surrounding it that, while less tangible, such as communication and leadership skills, really help in a senior position.
Real programmers use butterflies
-
I think the only "senior" developers I have seen were called that (and probably earned accordingly) because they were old or with the company for many years. It never said anything about their skill level. They always underwhelmed me with their lack of basic knowledge of any tech after approx. 2005. Doing the same thing for 20 years != 20 years of experience. A common misconception, it seems :sigh:
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
I think the only "senior" developers I have seen were called that (and probably earned accordingly) because they were old or with the company for many years. It never said anything about their skill level. They always underwhelmed me with their lack of basic knowledge of any tech after approx. 2005. Doing the same thing for 20 years != 20 years of experience. A common misconception, it seems :sigh:
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
Sander Rossel wrote:
I think the only "senior" developers I have seen were called that (and probably earned accordingly) because they were old or with the company for many years. It never said anything about their skill level. They always underwhelmed me with their lack of basic knowledge of any tech after approx. 2005.
If that's truly part of your metrics for judging someone's capability, I look forward to your career plans when you are in late middle age.
Software Zen:
delete this; -
Sander Rossel wrote:
I think the only "senior" developers I have seen were called that (and probably earned accordingly) because they were old or with the company for many years. It never said anything about their skill level. They always underwhelmed me with their lack of basic knowledge of any tech after approx. 2005.
If that's truly part of your metrics for judging someone's capability, I look forward to your career plans when you are in late middle age.
Software Zen:
delete this;It is, seeing how pretty much everything we're working with nowadays was released after that time. .NET 3.5+ (introducing stuff such as LINQ and EF), .NET Core, Git, many (or all?) front-end frameworks, DevOps and CI/CD, microservices, pretty much anything cloud... Even "old tech" such as SQL and Web API's have evolved (preferring JSON over XML for example). And not only tech, but methodologies such as Agile and Scrum as well. I make modern web apps in reasonably modern environments, so yeah, having knowledge of modern tech is most certainly one of my metrics! If you think these people were any good before 2005, think again by the way. Many I've met were not aware, or did not understand, how to properly apply OOP principles. Oh yeah, and all your logic goes in huge SQL stored procedures, because that's your central unit that all software has access to. NoSQL is a curse word. Trust me, when I say these people are not good at programming, they're not good at programming. What usually sets them apart is their knowledge of the field and environment (as they've been using and developing it for the past 10+ years) and the long hours they make to make up for their lack of skill, knowledge and interest in (new) tech. Yeah, I've worked with some really bad seniors. Really great at keeping stuff going and fixing bugs, really frustrating for any new development. I really hope my career plan won't be to work on obsolete tech X|
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
It is, seeing how pretty much everything we're working with nowadays was released after that time. .NET 3.5+ (introducing stuff such as LINQ and EF), .NET Core, Git, many (or all?) front-end frameworks, DevOps and CI/CD, microservices, pretty much anything cloud... Even "old tech" such as SQL and Web API's have evolved (preferring JSON over XML for example). And not only tech, but methodologies such as Agile and Scrum as well. I make modern web apps in reasonably modern environments, so yeah, having knowledge of modern tech is most certainly one of my metrics! If you think these people were any good before 2005, think again by the way. Many I've met were not aware, or did not understand, how to properly apply OOP principles. Oh yeah, and all your logic goes in huge SQL stored procedures, because that's your central unit that all software has access to. NoSQL is a curse word. Trust me, when I say these people are not good at programming, they're not good at programming. What usually sets them apart is their knowledge of the field and environment (as they've been using and developing it for the past 10+ years) and the long hours they make to make up for their lack of skill, knowledge and interest in (new) tech. Yeah, I've worked with some really bad seniors. Really great at keeping stuff going and fixing bugs, really frustrating for any new development. I really hope my career plan won't be to work on obsolete tech X|
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
I am one of the people you are disparaging, as I turn 60 in less than two weeks. While I am currently the oldest member of my team, I am also the leading advocate for new technologies and new techniques. I will admit I don't do web programming. My fields of expertise include complex machine UI's, real-time distributed process control, and embedded applications. By your standards and based upon these factors I'm an out-of-date oldster who should be euthanized because I'm in your way. I will be laughing my ass off from hell when you do, as you try to run a commercial ink-jet printing system(*) from a web server. You're trying to keep track of printing four colors on both sides of the paper, at 600x900 dpi, putting down over 1 billion drops of ink per second, on paper that's moving over 10 feet per second, and that's for one system. (*) Using my current job as an example
Software Zen:
delete this;
