Developer title inflation

The laws of Economics apply to all kinds of human relations and it’s principles can be easily extrapolated to explain a great number of things, including developer titles. This is a joke I heard some time ago:

– How can a Junior developer become a Senior one?
– Simple. Just change the job twice

Sad, but true, and there are a great number of things that contribute to this.

Demand-pull inflation
The friendly HR girl that handles the hiring process often has only a vague idea on who she is actually looking for. She’s been given a checklist by the CTO and wants to do her job well by finding someone fitting as fast as possible. Why not let a guy with 2 years of experience a chance for the Senior dev vacancy? Especially if she represents a small agency that doesn’t get that many applicants in the first place.

The CTO may decide that even though the person he just interviewed isn’t quite the Senior they’re looking for he still could hire him for 80% of the salary, but the title stays. Titles, unlike money, cost the company nothing.

People conducting the interview use themselves as a standard
If the developers conducting the interview aren’t very good themselves, they are likely to also overestimate the interviewee. In fact they will do everything not to hire a person who is more knowledgeable than themselves, so that not to shake their position of power.

It’s getting very easy to develop
We have a multitude of libraries and frameworks available today. Becoming “good-enough” to string those together and make a CRUD app is no challenge at all. This combined with that a lot of people consider a developer that can throw together a website on his own a mid-level already means that the Junior title is pretty much skipped entirely, and people rarely consider themselves Junior PHP devs for longer than half a year.

Titles don’t get revoked
This is the worse kind of inflation to me. This happens when people who were genuinely awesome 4 years ago stopped learning new stuff, stick to old practices and put ‘hipster’ label on everything new. In PHP those are the kind of people who think namespaces suck, Composer is complicated and testing is just wasting time. They proudly state their 10+ years of experience, while actually being harmful to the team. Truth be told, their experience does come in handy when it comes to architecture sometimes. But development is so rapidly evolving that if you miss just 2 years you’re probably far behind the bandwagon.

Titles are rarely specific
Being a “Senior WordPress developer” doesn’t make you a “Senior PHP developer”, and somewhat vice versa actually.

The terrible consequences
There was a discussion on reddit recently that discussed questions that should be asked when interviewing a Senior developer. I was surprised at how trivial those were. “Knowing weak and strong points” of current ORMs is something a mid-level dev should be easily able to do. What happened to knowing algorithms, data structures, patterns, extensive database knowledge, cryptography etc. What do you call a person who knows all that then ?. You can’t put those on the same spot as the guy who can choose between ORMs. Perhaps we need more titles, maybe we need to start calling ourselves “exalted PHP developers of the 5th rank” from now on. But the worst part is that people who already consider themselves to be Senior stop learning, and a person who doesn’t learn constantly will never notice how ignorant he in fact is. And one day on your first day in a new company you may find out that you will now be lead by people much less experienced than you, and every architectural decision is going to be a battle between your knowledge vs their ignorance. And that frankly sucks.

TL;DR Be modest and learn every day.

3 Comments

  1. I agree with a lot of points here. In fact, some of these points help me when hiring.

    The agency I work for doesn’t have a HR department, so the hiring for my team comes down to the Lead Developer (me) and the Head of Development. Years of experience in my eyes doesn’t count for anything. I’ve met PHP developers that have had only one year commercial experience that have shat all over people that have had 5 – 10+. We hire based on the areas covered in their experience, how little it might be. If they could fill the position we’re looking for, it then comes down to salary.

    Personally I would never hire somebody lesser than me in fear of losing my position of power. A company will never progress technically if you only hire people below the existing skill set. It’s about creating a team with varying skill set’s which in turn can better the individual members of the team, as well as the team in whole.

    I revoke titles when needed.

  2. I agree with a lot of points covered in this article. This one in particular never occurred to me until now:

    “[A developer interviewer] will do everything not to hire a person who is more knowledgeable than themselves, so that not to shake their position of power”

    As the interviewee, I’ve been able to impress people with my technical skills, usually I tick all the boxes in their job description before applying, but then quite far into the interview process get rejected for “team fit”. Now considering the current developers skillsets and job titles, I’d suspect this was cause for them to say no.

    As the interviewer, when I paired with another colleague to interview a very good developer who had strong experience and a particular skillset we were missing (in this case it was ZeroMQ and Node), I wanted to hire him, but my colleague said he was a “show-off” and two weeks later, “maybe it’s not quite the right time to hire anyone”. My position wouldn’t have been affected with his, but for my colleague this would have been the case.

    Sad, but true.

  • Dracony

    January 24, 2015 at 10:53 pm

    My friend who was one of the people interviewing an applicant has had the same thing happen. Two other interviewers decided against hiring him saying he would later try to take over their position.

Leave a Reply

Your email address will not be published. Required fields are marked *

© 2024 Dracony

Theme by Anders NorénUp ↑