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.
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.
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.