Keff

Posted on May 24, 2022

Should every developer become a senior?

#career #discuss #watercooler

Would you say every developer should aim to become a senior or a higher role? Or is it okay to stay at a lower role?

Top comments (23)

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.

CuriousDev • May 26 '22

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.

peerreynders • May 26 '22 • Edited

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

CuriousDev • May 27 '22 • Edited

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.

peerreynders • May 28 '22

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

CuriousDev • May 29 '22

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.

Keff • May 24 '22

The article about he expert beginner you shared is a really nice read, thanks for sharing!!

Mike Nieva • May 25 '22

Awesome article. Thank you.

Keff • May 24 '22

I agree, well put!

Ben Halpern • May 24 '22

The way the term senior is typically used in the industry, I think it currently represents what I'd consider to be a "good landing spot" if you don't want to constantly face new challenges that over-stretch you and leave you unhappy.

I don't think anyone should feel bad about staying at that level below, but IMO senior is the good spot to think of as a possible permanent landing spot. But so much of it is circumstance. What is the company expecting from the title?

Regardless of what title is the right landing spots, I see a lot of happy developers who settled into a level and contribute really effectively for that level and don't put the pressure on themselves to move past it.

Paweł Świątkowski • May 24 '22

Interesting question.

I think no, not everyone should become a senior developer. Senior developer is not just a regular developer with added years of experience and changed job title. It should bring a switch in responsibilities and ways to think about the whole codebase. One very important part of being a senior developer it tutoring other developers - and it's not for everyone, just like founding your own startup is not for everyone (yet by some people it's considered o natural next step in developer's career path).

Jessica Veit • May 24 '22

Personally, I think having goals in life is important. Wether you set them in your professional or personal life is completely up to you. So, I would say, if you want it - aim for it 😄!

I know developers who are just content with the way they currently work and do not waste a single thought into doing anything different. In short, if you start thinking about it - work on it! Overall one should be happy 🍃

Alex • May 26 '22

I don't think every developer should become a senior, I don't think I want, I don't want to constantly take care of others or to do more meetings and talk with clients. I'd rather just code what I'm told.

SUCHINTAN DAS • May 24 '22

I think being a senior developer 🧔 should be a goal of every developer .

Want to know why❓

The reason is simply that , for becoming a developer then need to learn more and more everyday to keep themselves enough skilled to help out the junior developers. Not only in terms of experience they would have to rock . 📌 But also in terms of leadership and communication ❗ also so that they can help their juniors in the right way , making them a good senior developer.

Of course it's a good thing that people who learned stuffs from their seniors are now guiding their juniors also in the same pathway 🟢.

So the answer is simple YES ✅.

N Cee Dee • May 24 '22

If it's for them to stay in lower role.. then what is the aim and evidence of their past work experience...🤷🏻‍♂️.. it doesn't make sense.. everyone in this life is meant to move forward not to stay in one exact position...