Why do we have roles?

People like naming things

Upside

It is easier to talk about categories or job levels then to always declare the full function or expertise of a person or group, i.e. “That task can be handled by one of the junior devs” vs. “That task can be handled by one of the devs that know our architecture, but are not yet experienced in the front end code”

Downside(s)

  1. it simplifies a person to a set of expectations (which are not objectively defined). So you can talk about the “junior devs” on your team, since you know what they can do, but you can never transfer this to another team, since this is not an universal construct.

  2. names can become a source of friction, i.e. if somebody is 30 and is still called a junior, he or she may not feel recognized, this seems minor, but this is exactly the type of problem a team should not have, so even more then in code, take good care of naming things correctly.

Hierarchy

the levels are sometimes used to create a hierarchy within dev teams (that I don’t approve of). Of course a senior developer has more experience in finding solutions, just because he did it more then a junior developer, but that does not mean that he will always have a better solution to every problem.

Every Developer brings a new perspective to the table and that is also how teams get better, more diverse teams fair better.

A Senior Developer should not call the shots just because he is more experienced, this should either be done by presenting a better solution or be based in a role within the team, like being the architect (of the whole project or the specific module).

Prestige

Some people need the Validation of a title, this may sound petty, but becoming a senior etc. is a great achievement for many developers (even greater in teams that emphasize these roles).

OK, but really, what’s the difference?

Fixed Definition

Some (mostly larger) Companies will have a clear definition or “Paths” for every Role in a Development Team, in these cases it is a checkbox based game (i.e. on a scale from 1 to 10, rate your Experience in OO). I have only experienced this in one Company, and it seemed to work very well there, since you get a better grasp of what you can expect of a junior/intermediate/senior/principal Engineer.

Of course, this is still not Bullet Proof, your own perception and the one of your Teamlead can differ significantly, so there is sometimes a need for a third person, but someone that also knows about your performance is hard to find sometimes.

“Feelings”-based Definition

I guess most Companies use this approach (which means they have none).

This is based solely on a kind of back and forth between the perception of the Team lead and the Team member, when both are on the same page, everything is fine, but as soon as they have different view can become difficult (this can range from “annoying” to “problematic” to “toxic”).

I’ll try to explain:

The main problem (in my limited Experience) is mostly not about money, most people need the Validation and want to be “seen” (for lack of a better word).

So it can be annoying to be called a junior dev when you feel like you have gained enough experience to be as good as the other intermediate devs, it can become problematic when this missing Validation lasts over a longer term or is even discussed, but not resolved. When it hits “toxic” level, there will be a chance of infighting inside the team and too much talk about what level who is, instead of talking about the work that needs to be done.

A good managed team is one with the least amount of friction possible

MY DEFINITION (under Construction)

junior

just starting out in development, that includes a student that starts today and lasts approx 3-4 years (this does not mean 3-4 years on the job training, we get applications from 18 year olds with 2 years of experience already). Juniors are learning the basics about paradigms, libs, tech and also about the software stack as a solution that is (normally) not all custom software but a lot of tools that work together to produce a working product (CI, servers etc.).

intermediate

An intermediate dev is somebody that can develop good modules on his own and research missing knowledge, but lacks the overview of the whole product and all technologies involved. This is mostly a learning stage where you can already develop software but have not been long enough into it to know i.e. history of web development. In my experience this is the stage where you feel a little stagnant but also the one you stay pretty short (2-3 years).

senior

senior devs are the last stage for a lot of developers, sometimes just because Companies only know 3 levels or because it is too hard to go beyond this stage (and it is certainly not needed for everyone to go further).

senior devs know all or nearly all parts of the product and what tool does what (not necessarily how everything works exactly, but enough to hack something together should the need arise), they also know the architecture and are part of discussions about extending/developing the architecture (everybody should take part in this, but often juniors can not yet give valuable solutions, or else they would not be juniors anymore…..).

principal

principal engineers (as far as i have experienced them) are the best of the best, people that live and breathe code, they have vast knowledge about a myriad of topics and can discuss pretty much every part of software development or current technology. These people are rare and rarely recognized for just how much value they bring to the team. When you have one on your team and he/she is able to communicate their knowledge, try to learn as much as you can.

How do i become a senior?

The Case against seniority

sometimes you encounter a line of thinking you thought was long gone, but then it rears its ugly head.

This hit me when i learned about a colleague in another country where just being older, means that you are right and a younger team member has to live with it. The problems are plentiful:

  • older employees can become complacent, as they are less and less called into question (as at some point nobody is older)

  • really demoralizing towards young devs, since they need years to do anything as they see fit

  • creates a rigid framework for everyone so creative problem solving is not easy

What about money?

it is normal for senior devs to get higher compensation then junior or “standard” devs, but not always, sometimes a developer stays with a company for a long time and gets promoted to become a senior, but another dev is newly hired, and has a better bargaining position. So it is important to think about this, word will get out, when you hire new people that earn more, sooner or later, the others will find out and ask (rightfully) for a raise.