Sometimes you have to step back from a situation to see it for what it really is, and I think this is particularly true of the way software developers are labelled as junior, middleweight and senior.
For some reason, it’s become an accepted part of the software development industry that if you’re a junior developer looking to get an junior level job and learn the ropes, you may end up being passed over because you haven’t got — in some cases — up to the necessary three years experience!
Sounds silly right? Junior level jobs that need three years experience?
Well that’s because it is.
Seeing this in a job advert does have its uses however. It serves as a pretty clear warning about the kind of company you’re applying to. There seems to be a growing culture in the software industry of businesses playing the job title game: slap ‘junior’ in front of any job description you publish and you can get away with paying a much lower salary.
The sad truth is that these businesses are going to find it harder to hold on to staff as new starters quickly realise their own worth and spot the gap between the value of what they are doing, and what they are getting paid. In the long run, as word gets around, they’re going to find it more and more difficult to recruit great candidates.
There’s a huge difference between a developer looking for his or her first job and someone who has been working in the industry for three years. You might think I’m advocating a new term for another strata of developer to be introduced, but quite the opposite.
From my own experience I have found it easiest to grow professionally when working within a flat structure where developers are simply called developers. There are no senior developers, no middleweight or junior developers… just developers.
Maybe it’s psychological, but I’ve found that this kind of structure goes a long way to encourage opinions and input from newer coders in meetings, whilst also taking the pressure off those who have been doing it longer who may feel (and this is often unnecessarily) that they need to carry the team and almost take on a managerial role. It means that developers are judged solely on what they know and on their actions.
This is not to say that everyone learns at the same pace. I would encourage people to consider that years aren’t a reliable comparator across developers. Due to the volume of complex technical knowledge that makes up the industry it’s not uncommon to have incredibly intelligent long term coders not know very basic stuff about a rudimentary technology. Similarly there are plenty of very new coders who have abilities far beyond what you would expect based on their time in the industry.
I’m certain that coding abilities across a group of devs after three years in the industry could look very different, based on the relative speeds at which they each pick up new material. In that case, the labels of junior, middleweight and senior are pretty unhelpful when it comes to choosing the best candidate for the job.
The answer? Employers should be gleaning information about skill levels from aptitude and developer tests coupled with interviews, rather than relying on number of years experience. As an industry, we should break free of the labels that plague the developer job search. When time is taken to find out what people are capable of rather than how long they’ve been in the workplace, everyone wins!
Top comments (7)
Perhaps it's my personality or that my first "real" dev job was as "cto 🤔" of a two-person startup, but I never even considered labelling myself "junior". I didn't say "senior" either, I was just a developer.
But the thing about humans and language is that any time we sort of do away with some construct we kind of wind our way back into that situation by playing with words. We have a remarkable ability to twist the meanings of things until we fall back to the hierarchical statuses we collectively crave.
I hadn't thought about it like that before, its a really interesting point - people tend to instinctively put themselves inside boxes. To attempt to add to your idea perhaps in addition to the developers that do this to themselves, quite often it may be the gatekeepers to positions i.e the recruiters that do this as a way to gauge some level of understanding of what companies expectations and individuals expectations are and if they line up. Some of the approaches I have had from recruiters have focussed more on if I am a junior/middleweight/senior over talking about the actual things I can do. Hopefully done with the best intentions, however ending up pigeonholing people, I suppose this is where some of the collective frustration about software recruiters may stem from.
I see those terms as useful, but not based on years of experience or number of libraries/frameworks. Instead, it's a way to describe the mental and technical maturity that a developer displays, not only with regard to code quality in the simple sense but also but also in relation to making sensible and maintain decisions from a larger architectural and business perspective.
That of course doesn't mean that everyone uses it in that sense, or that some people use words to trick or deceive (like fullstack = we'll need you to do everything, at an unreasonable pace).
larger architectural and business perspectiveI really like your consideration of this. This is so hard to quantify and makes up such a huge part of the criteria of being considered an experienced developer by others.
"it's a way to describe the mental and technical maturity a developer displays" - this is what terms such as junior, intermediate, and senior mean to me and also a number of companies which I have worked for.
My current employer also rates non-tech skills, such as sensible decision making, self direction, client interaction etc, when considering the seniority of staff and for performance reviews.
This is particularly relevant for companies who hire full-stack developers. Inevitably you will have some with better front end or backend or DB etc skills than others, this does not (or should not) determine their "level". While you may be "junior" at one thing you could be "senior" at another. In this scenario labels become not only useless but harmful to the team.
agreed, full stack devs are likely to have T shaped skills and labelling incorrectly across the stack skills totally feeds into this.