How many people perceive 'seniority' in The Software Industry
This post was migrated from my old blog which used to be hosted on Blogger. As a result, some links might be broken.
When you get into the software industry, you notice how most companies make a big deal of whether you are “senior” or not. “Seniors” get to make more decisions, are more respected and get paid more. So everybody wants to be “senior”. But what does that mean?
“Junior” and “senior” are traditionally used to distinguish between generations. “Seniors” are older than “juniors”. That has been adapted to academia, where again, the “seniors” have basically been studying a bit longer than “juniors”. It appears that just having been in one place a bit longer than somebody else buys you the privilege of being more “senior” than that person.
I respectfully call bullshit. At least with regards to the usage of those terms in The Software Industry. The mere duration of having been in the industry is absolutely not a reliable indicator of “seniority” as most people mean it. Let’s move away from that ambiguous term, and say: experience.
How many people perceive 'seniority' in The Software Industry
There has been some discussion about the value of experience in the blogosphere lately. They, too, seem to be thinking of experience as the time spent on something.
I’ve done some interviews in my life now and I can wholeheartedly say that time itself does not tell you anything about somebody’s actual experience. There is a quote that I think fits nicely:
“An expert is a person who has found out by his own painful experience all the mistakes that one can make in a very narrow field.”
– Niels Bohr
Note how this quote is about experts. The word is clearly related to “experience”, but to complete the picture:
“A person with considerable experience in a specific field can gain a reputation as an expert.”
There you go. You gain experience by making mistakes, and making as many of them as possible. That makes you an expert. Expert is what most people should be saying when they talk about “seniors”. Because “senior” implies some form of age, whereas expert is what actually refers to somebody’s expertise (there’s that word again!).
Yes, it usually takes time to make all those mistakes you need to become an expert. But more than time, it takes pain. An expert will have spent a significant amount of time cursing and being frustrated about problems and tools, trying to make stuff work (and, hopefully, successfully doing so in the end). So while you can safely assume that an expert will have spent time in the field, you unfortunately cannot do the reverse. Just spending time doing something will not necessarily make you an expert.
That’s also why it’s much harder and more valuable to give useful critical feedback on something than it is to compliment it. Anybody can point out obvious good things. Those who have made (less obvious) mistakes before will remember, and warn you about pitfalls they have encountered when they’ve been there, done that.
Sadly, it’s also why many developers with little experience do not appreciate lots of advice that comes from so-called “seniors”. Because you cannot appreciate some things until you’ve been burnt yourself. I find that very evident when it comes to topics such as agile methodologies, test-driven development or even design patterns. If you haven’t felt the pain that these things can save you, you’ll probably not value them (yet).
Joe Programmer’s CV saying “10 years writing performance-critical software in C++” looks more interesting to many readers than Jane Hacker’s CV which states “4 years developing websites with Python”. I’ve come to learn that both of these statements say equally little about the applicant’s expertise. In fact, Jane could easily be more experienced (at whatever) because she might have been obsessively hacking away on twelve open-source projects in all her spare-time during those four years.
There's more to 'senior' than technical skills
I was once hired as a “Senior Software Developer” at a company, and the Head of IT let me know what he expected from a “senior”. It was not just technical expertise, but just as much the ability to scale. To spread that expertise throughout the team. In fact, the word “senior” was yet again misleading here, mentor would have been more appropriate.
“Mentorship refers to a personal developmental relationship in which a more experienced or more knowledgeable person helps to guide a less experienced or less knowledgeable person.”
When hiring an expert, the value is marginal if that person will sit in a corner with headphones on, going “Bring on the problems, I’ll hack them up!”. It can be useful to have that sort of maverick when you need a miracle asap, but it’s rather useless most of the time.
In a team, problems and solutions need to be explained and discussed. I’ve met people at that company who were great coders, but had big problems communicating. They’ve been on the project longer than me. They knew the codebase and tools better, too. Yet their official title did not say “senior”, and that was unlikely to change anytime soon. And rightfully so - their expertise was locked up inside their heads and did not scale.
Better definition of 'senior'. Note that there is lots of middle ground
Aside from recruitment, many companies make this mistake in management, too. It seems that people who have joined the company earlier than others somehow get dibbs on the next leadership position that becomes available. Again, just because somebody is older or has been with the company longer, that by itself does not make them any more of an expert in…anything than somebody else who is younger and just joined six months ago.
Furthermore, just because somebody can code well, it does not mean that they will make a good mentor or leader. Leadership involves much more than maintaining spreadsheets and going to meetings. I have seen many “team leaders” that, despite being decent programmers, lacked the most significant of attributes a leader should have, i.e. a general sense of direction, ability to make decisions even (especially!) without having access to all the information, and the ability to move a group of people into that direction. Preferably at the same time…and without requiring a whip.
Programming and leadership abilities are two entirely orthogonal concerns.
Think about what it is you mean when you say “senior”.
Stop using the word “senior” when you actually mean “expert”. It takes the misleading implication of time out of the equation.
Expert == lots of Experience Experience != Age Experience != Time on the project
Experience == Mistakes over Time
Anybody can tell you about the “good things” (they’re what’s printed on the box after all). An expert can tell you about the bad things that lurk beneath the surface - because she’s been there.
Age or time on a project say nothing about expertise. Don’t hire or promote people primarily (or even partially) based on those criteria when what you actually want are “experts”.
Expertise does not necessarily scale well.
“Senior” developers/engineers/whatever have made tons of mistakes and are able to help others learn from those mistakes.
Edit: Added green triangular “senior zone” to last graph. Edit: Added second graph highlighting seniority vs. technical skills.
Update: This post has received some attention and comments over at Hacker News.