Culturally the "be better than yesterday" aspiration would lead to the assumption that most people would incrementally improve themselves out of any lower role given enough time.
And as information technologies have a habit of perpetually changing at various rates a certain base agility/adaptability is be required to just "keep up". So in this industry one has to be committed to career-long improvement, study and learning—so some intrinsic drive to do so is beneficial, possibly mandatory.
Can circumstances conspire to keep somebody in a lower role? Certainly.
But if somebody doesn't advance due to being an expert beginner that's a red flag.
The flip side is that the 'senior' label is often meaningless—its more a label of status and compensation within the organization rather than a reflection of objective competence.
I think it is very important to agree on a understanding of what a Senior Developer is. But by just reading the Title, Role, whatever you want to call it, it just describes somebody with experience.
Somebody thinking of not becoming a "Senior Developer" can be an issue, if we are talking about getting experience and making progress. It should be acceptable, that there is a lot to learn and especially if we are talking about projects, it is not unusal (for my knowledge), that you most likely will have to deal with new stuff. But if it actually is about a certain Role in a Team, feel free to explain to me, what it would be like (I am asking everybody here). In that case it can be different of course and also fine to "refuse/avoid" to work with this assigned Role, because of responsibility and more.
fine to "refuse/avoid" to work with this assigned Role, because of responsibility and more.
Ultimately that depends a lot on the work culture the individual finds themselves embedded in. Presumably the place of work needs somebody to fulfil that role and after applying their selection criteria they will arrive at a choice. At that point rejecting the "appointment" could be judged as not being aligned with the "collective interest"—so ultimately refusing the role may have consequences.
This isn't to say to "always do what your boss tells you to" but it is important to be clear what your values are and to notice when they start to diverge from those being practiced at the work place, indicating that it probably is time to move on.
I take non-senior positions largely as entry points where someone will take 6-24 months to be trained and oriented within the organization before they "find their place" (at least for the time being).
In terms of "ten years of experience or the same year of experience ten times" the latter describes a perpetual junior.
However I'm also reminded of the stereotypical developer to manager transition; in 2002 Scott Ambler observed in Agile Modeling (p.4) the typical career path of a corporate developer:
"I also believe that the way that developers learn their trade has a few unique dysfunctions. For the most part our colleges and universities are doing a reasonable job of educating developers for entry-level jobs. However, even if the schools were doing a perfect job and everyone was getting a degree or diploma, I suspect that we’d still have a problem due to the inherent nature of software developers. When software developers are young, in their teens or early twenties, they typically focus on learning and working with technology. They describe themselves as PERL programmers, Linux experts, Enterprise JavaBeans (EJB) developers, or .NET developers. To them technology is the important thing. Because technology is constantly changing, younger developers have the tendency to just barely learn a technology, apply it on one or two projects, and then start over again learning a new technology or the latest incarnation of what they worked with previously. The problem is that they keep learning the same different flavors of the same low level, fundamental skills over and over again."
"Luckily, many developers become aware of this after several rounds of technologies - once you’ve written code for transaction control in COBOL, Java, and C#, you start to realize that the fundamentals don’t change. The same is true of database access in various environments, user interface design, and so on. Before long, developers begin to realize that many of the fundamentals, which they may or may not have been taught in school, remain the same regardless of the technology. This realization often comes when reach their late twenties or early thirties, typically the time when people start to settle down, get married, and buy a house. This is fortuitous because these new demands mean that developers can no longer afford to invest vast amounts of time learning new technologies; instead, they want to spend that time with their families. Suddenly higher-level roles such as project lead, project-manager, and (non-agile) modeler become attractive to them because these roles don’t require the constant and intensive effort needed to learn new technologies. So, by the time that developers begin to truly learn their craft they’re in the process of transitioning out of their roles as developers. Luckily, new “young punks” come along and the cycle repeats itself. The end result is that the majority of people actively developing software are typically not the one best qualified to do it, and they don’t even know it."
Thank you again for a great response, @peerreynders ! I always enjoy reading it. Regarding Senior Developer as a Team Role, I just wanted to emphasize, that it could be a difference depending on how you define it. If you would be allowed to pick a role with less responsibility, this could be a way. This is not trying to say it is realistic or the roles would be named "Junior/Senior etc.", but if there is the choice to pick something "below" instead of a "higher" role, then I guess it can be fine (not necessarily recommended).
I totally agree on that the project or whatever kinda tells you what is expected from you can heavily influence what you "should want" to do. In other words, regardless of "Senior Developer" as a Role or just a way to express an experienced person, in Software Development you should expect the need for constant learning and that the investment can be worth it. It is nothing to be afraid of.
if there is the choice to pick something "below" instead of a "higher" role, then I guess it can be fine.
From a humanitarian perspective, yes ("to each their own")—I'm trying to highlight a perspective where there may be a fundamental tension between the traits exhibited by a successful software developer and a personality who chooses to remain in a lower role.
"Software is never finished, you just stop working on it."
Similarly it could be argued that being a software developer isn't a destination but a journey.
Given that most software developers have to be comfortable with indefinitely adapting to a continually changing field, I would imagine that someone inclined to "stay in place" would not be happy in the software field.
"Someone with a growth mindset views intelligence, abilities, and talents as learnable and capable of improvement through effort. On the other hand, someone with a fixed mindset views those same traits as inherently stable and unchangeable over time."
I suspect that successful software developers tend towards a growth mindset and would consequently prefer not to stagnate.
If you would be allowed to pick a role with less responsibility, this could be a way.
But now you have to be specific about what "responsibilities" are. This usually refers to a leadership role where one makes decisions for and about other people.
That's not what a "senior" role is necessarily about.
One is always responsible for one's work being correct. Over the long term it's not going to be tolerated if there are always major concerns uncovered during code reviews; one cannot rely indefinitely on others to catch one's mistakes.
One is responsible to communicate effectively with team mates in order to keep the team effective.
One is responsible to communicate effectively with stake holders, clients and users to deliver what is needed.
One is responsible for acquiring the domain knowledge necessary to deliver solutions that are consistent within that domain.
Sometimes one is responsible for becoming the technical expert within the team for one or more products being used by the team.
I knew a developer who's sole job it was to constantly adapt a critical quarterly forecasting report against the corporate database according to directions of the subject matter experts (SMEs). While the requirements were the SMEs responsibility, the technical oversight, design and implementation was that developer's responsibility—not delivering accurate results in a timely fashion would have negatively impacted the business.
The other issue is that some organizations use "lower roles" as "taxi positions" for recent hires. When they need to fill a new internal position they have a ready pool of available people to immediately pick from. One or more people deciding "stay put" would reduce the effective size of that selection pool which would be counter productive. It's probably safe to assume that even in those "lower roles" the nature of the work would change over time—so there really is no "staying put".
Now there are always exceptions where you hear that somebody was just coasting on their software development skills for 10-20 years. But that doesn't mean one should be able to count on being able to do that. Ultimately that is a risky move—if and when that opportunity dries up, is one going to be able to finally adapt?
We probably haven't heard of the numerous developers who were obsoleted out of their job (Survivorship bias).
When I was writing about the "responsibilities", I seem to have mixed this up and this does not have to be related to Senior Roles.
The points you have then listed, are these for Developers in general or for something certain mind? I think these are important for every developer, but reality looks differents. To some extend understandable, if it is about unexperience people (still learning, getting used to work, etc.). But there seem to be also people, who do not have the motivation to "live" this points (they could do it, but when it comes e.g. to communication sometimes it is just not happening and they possibly just do not feel responsible for it). I am not trying to put experienced, but unmotivated people in a bad light, just sometimes wish it would be more like this and we could work together towards a great product.
Culturally the "be better than yesterday" aspiration would lead to the assumption that most people would incrementally improve themselves out of any lower role given enough time.
And as information technologies have a habit of perpetually changing at various rates a certain base agility/adaptability is be required to just "keep up". So in this industry one has to be committed to career-long improvement, study and learning—so some intrinsic drive to do so is beneficial, possibly mandatory.
Can circumstances conspire to keep somebody in a lower role? Certainly.
But if somebody doesn't advance due to being an expert beginner that's a red flag.
The flip side is that the 'senior' label is often meaningless—its more a label of status and compensation within the organization rather than a reflection of objective competence.
I think it is very important to agree on a understanding of what a Senior Developer is. But by just reading the Title, Role, whatever you want to call it, it just describes somebody with experience.
Somebody thinking of not becoming a "Senior Developer" can be an issue, if we are talking about getting experience and making progress. It should be acceptable, that there is a lot to learn and especially if we are talking about projects, it is not unusal (for my knowledge), that you most likely will have to deal with new stuff. But if it actually is about a certain Role in a Team, feel free to explain to me, what it would be like (I am asking everybody here). In that case it can be different of course and also fine to "refuse/avoid" to work with this assigned Role, because of responsibility and more.
Ultimately that depends a lot on the work culture the individual finds themselves embedded in. Presumably the place of work needs somebody to fulfil that role and after applying their selection criteria they will arrive at a choice. At that point rejecting the "appointment" could be judged as not being aligned with the "collective interest"—so ultimately refusing the role may have consequences.
This isn't to say to "always do what your boss tells you to" but it is important to be clear what your values are and to notice when they start to diverge from those being practiced at the work place, indicating that it probably is time to move on.
I take non-senior positions largely as entry points where someone will take 6-24 months to be trained and oriented within the organization before they "find their place" (at least for the time being).
In terms of "ten years of experience or the same year of experience ten times" the latter describes a perpetual junior.
However I'm also reminded of the stereotypical developer to manager transition; in 2002 Scott Ambler observed in Agile Modeling (p.4) the typical career path of a corporate developer:
"I also believe that the way that developers learn their trade has a few unique dysfunctions. For the most part our colleges and universities are doing a reasonable job of educating developers for entry-level jobs. However, even if the schools were doing a perfect job and everyone was getting a degree or diploma, I suspect that we’d still have a problem due to the inherent nature of software developers. When software developers are young, in their teens or early twenties, they typically focus on learning and working with technology. They describe themselves as PERL programmers, Linux experts, Enterprise JavaBeans (EJB) developers, or .NET developers. To them technology is the important thing. Because technology is constantly changing, younger developers have the tendency to just barely learn a technology, apply it on one or two projects, and then start over again learning a new technology or the latest incarnation of what they worked with previously. The problem is that they keep learning the same different flavors of the same low level, fundamental skills over and over again."
"Luckily, many developers become aware of this after several rounds of technologies - once you’ve written code for transaction control in COBOL, Java, and C#, you start to realize that the fundamentals don’t change. The same is true of database access in various environments, user interface design, and so on. Before long, developers begin to realize that many of the fundamentals, which they may or may not have been taught in school, remain the same regardless of the technology. This realization often comes when reach their late twenties or early thirties, typically the time when people start to settle down, get married, and buy a house. This is fortuitous because these new demands mean that developers can no longer afford to invest vast amounts of time learning new technologies; instead, they want to spend that time with their families. Suddenly higher-level roles such as project lead, project-manager, and (non-agile) modeler become attractive to them because these roles don’t require the constant and intensive effort needed to learn new technologies. So, by the time that developers begin to truly learn their craft they’re in the process of transitioning out of their roles as developers. Luckily, new “young punks” come along and the cycle repeats itself. The end result is that the majority of people actively developing software are typically not the one best qualified to do it, and they don’t even know it."
Thank you again for a great response, @peerreynders ! I always enjoy reading it. Regarding Senior Developer as a Team Role, I just wanted to emphasize, that it could be a difference depending on how you define it. If you would be allowed to pick a role with less responsibility, this could be a way. This is not trying to say it is realistic or the roles would be named "Junior/Senior etc.", but if there is the choice to pick something "below" instead of a "higher" role, then I guess it can be fine (not necessarily recommended).
I totally agree on that the project or whatever kinda tells you what is expected from you can heavily influence what you "should want" to do. In other words, regardless of "Senior Developer" as a Role or just a way to express an experienced person, in Software Development you should expect the need for constant learning and that the investment can be worth it. It is nothing to be afraid of.
From a humanitarian perspective, yes ("to each their own")—I'm trying to highlight a perspective where there may be a fundamental tension between the traits exhibited by a successful software developer and a personality who chooses to remain in a lower role.
Given that most software developers have to be comfortable with indefinitely adapting to a continually changing field, I would imagine that someone inclined to "stay in place" would not be happy in the software field.
"Someone with a growth mindset views intelligence, abilities, and talents as learnable and capable of improvement through effort. On the other hand, someone with a fixed mindset views those same traits as inherently stable and unchangeable over time."
I suspect that successful software developers tend towards a growth mindset and would consequently prefer not to stagnate.
But now you have to be specific about what "responsibilities" are. This usually refers to a leadership role where one makes decisions for and about other people.
That's not what a "senior" role is necessarily about.
One is always responsible for one's work being correct. Over the long term it's not going to be tolerated if there are always major concerns uncovered during code reviews; one cannot rely indefinitely on others to catch one's mistakes.
One is responsible to communicate effectively with team mates in order to keep the team effective.
One is responsible to communicate effectively with stake holders, clients and users to deliver what is needed.
One is responsible for acquiring the domain knowledge necessary to deliver solutions that are consistent within that domain.
Sometimes one is responsible for becoming the technical expert within the team for one or more products being used by the team.
I knew a developer who's sole job it was to constantly adapt a critical quarterly forecasting report against the corporate database according to directions of the subject matter experts (SMEs). While the requirements were the SMEs responsibility, the technical oversight, design and implementation was that developer's responsibility—not delivering accurate results in a timely fashion would have negatively impacted the business.
The other issue is that some organizations use "lower roles" as "taxi positions" for recent hires. When they need to fill a new internal position they have a ready pool of available people to immediately pick from. One or more people deciding "stay put" would reduce the effective size of that selection pool which would be counter productive. It's probably safe to assume that even in those "lower roles" the nature of the work would change over time—so there really is no "staying put".
Now there are always exceptions where you hear that somebody was just coasting on their software development skills for 10-20 years. But that doesn't mean one should be able to count on being able to do that. Ultimately that is a risky move—if and when that opportunity dries up, is one going to be able to finally adapt?
We probably haven't heard of the numerous developers who were obsoleted out of their job (Survivorship bias).
When I was writing about the "responsibilities", I seem to have mixed this up and this does not have to be related to Senior Roles.
The points you have then listed, are these for Developers in general or for something certain mind? I think these are important for every developer, but reality looks differents. To some extend understandable, if it is about unexperience people (still learning, getting used to work, etc.). But there seem to be also people, who do not have the motivation to "live" this points (they could do it, but when it comes e.g. to communication sometimes it is just not happening and they possibly just do not feel responsible for it). I am not trying to put experienced, but unmotivated people in a bad light, just sometimes wish it would be more like this and we could work together towards a great product.
The article about he expert beginner you shared is a really nice read, thanks for sharing!!
I agree, well put!
Awesome article. Thank you.