Cruising blazing-fast through the programming hierarchy

People like to build hierarchies. It’s a natural instinct, probably it’s one of the advantages which helped our first ancestors fight off a rival monkey tribe who wanted out of the jungle as well. Hierarchies are easy to coordinate: you know who’s leading who, nobody is without a leader (except the capo di tutti capi), and everyone obeys people above them in the hierarchy. It’s simple.

The corporate career is really a hierarchy climbing effort. You’re starting from the smallest role in the company (ideally) and you become better at everything corporate until you can become one of the big bosses. So when corporate life discovered software engineering, it created a set of hierarchies to capture the whole programming specter in a simple, easy to understand hierarchy. So we have junior software developers, software developers and senior software developers. Then we have technical leaders, technology specialists, technology evangelists, tech wizards, tech superstars, tech gurus, buzzword((insert buzzword here)) gurus, team leaders, who are pretty much at the same level because nobody can really tell what the heck are they. Above them, a class of project managers, which generally are extracted out of the technical/team leaders because those have the „leader” thing in the name, and it makes sense. Managers are leading and managing, therefore leaders only need to do managing or something.

So here’s the problem: while we agree that we have juniors, normies and seniors, we have no idea what’s above them. And we really don’t have any idea what normies are and what seniors are, because when do you call a person a senior? If, like any corporation, you have defined criteria for when you do name a person „senior”, you’ll see that people will rush to prove to you that they are seniors, even if they have been doing this „programming thing” for one or two years at most.

And it’s easy, because all criteria are easy to meet. Seniors are not super-human, and humans are not known to expand their capacity with every passing year – to the contrary. So a 15 year old could easily do everything that a senior does, if he only knew how to do these things – they only use a set of tools, they can even be more proficient at writing mails, or editing code, or performing the same tasks as a senior. The same way as every writer could be Dostoievski, because they use the same tools: words.

And here’s me introducing in a subtle way the problem. Although on the surface everything that has to do with development is easily quantifiable, reality is that it’s not. A man who has to dig 10 meters of trench does an easily quantifiable job: a hole in the ground is binary defined, it’s either there or it’s not. Programming work, well, it’s more complicated, even if it’s there it might not be, and even if you can’t see it, it might be there. It’s a creative job done with theoretically precise tools.

So who does it better could be a question of artistic „eye of the beholder”. But it’s not that either, a senior should be objectively better in many (perhaps all) ways to a normie, and a normie should be even able to train a junior; that’s the point. And before we would start discussing about „objectively better” when it comes to art, let’s head back to my problem.

Today I saw a young developer in my old firm who was bumped to senior software engineer. Young, ambitious, dedicated, all that – way too young, though. It’s not what you’d expect to see when you say the word „senior”. And while I mean no offense towards her, I think she still has a lot to learn. I don’t think she’s mature enough to be a senior, and it’s the kind of thing that doesn’t change in a year. I think she’s aware of that, but she has no other way to mark her (undeniable) progress in this business. But what happens when you’re a senior by 25? Does the label „senior” really say something about your experience and your capabilities?

So here’s what happened. The firm, like all others in the IT industry, has defined a payment cap for your label. Instead of evaluating the person they evaluated the labels, and decided that the junior label gives you three oranges, the normie gives you four and the senior gives you five oranges. If you feel like you deserve five oranges, you have to be named senior, even if you’re too young and haven’t had enough experience to actually deserve that name.

So, unfortunately, the senior label only means she is paid a different amount of money, and probably she has different responsibilities because of that. But that doesn’t mean she dramatically improved when it comes to code quality. No. Most likely, she’s just escalating the hierarchy to end up in a better paid position, probably as a something-something manager. Which will lead her to know nothing about everything, and not have any real qualification at all.

First of all, it’s a disservice to her. Because unknowingly, her label won’t allow her to be in the position where she can ask questions – she’s a senior, senior say stuff, they do not ask((of course, that’s bullshit, but that’s what people will expect from her, unfortunately)), and the learning curve ends there when it comes to coding. She’ll see less development time and more „management” time – she’ll never be a good specialist, because the company robbed her of this opportunity. Why? Because they weren’t able to pay her more when she deserved a better pay, without her being required to shift responsibilities.

This trend is what gives us discouragingly worse quality for products. Luckily, users won’t complain if people can enter your account with any password, so it’s all good, but this trend will only lead everyone towards a far less favorable future, where there will be one coder and 10 people to manage them. Which is what happens in every corporate-cultured firm.

Hierarchies are necessary, but when the productive leaves are visibly outnumbered by the rest of the nodes on branches, questions must be asked. And that’s what happens there.

How should things be? Pay people what they deserve, no matter the label. Sure, you’ll have people who will complain about them being better than they are paid, and they’ll be right because they have various genetic features and the law says they are right. But the real solutions to real problems are sometimes politically incorrect. So pay people for what they are able to bring valuable to your company, and don’t label them. You’ll definitely have juniors, who will learn from the normies – the normies should outnumber every other type of developer in your firm, and seniors? Name a handful – so that people will know that the senior label really means something. And if a junior works better than a senior, pay them accordingly. But stop using labels for pay grades, because that’s not a working system. It will only bring your quality down, and your morale down, because people will hunt labels instead of results. Because that’s why people are advancing blazing-fast through your hierarchy: for a better pay, not because they are so damn good at their job((a joke for the Romanian readers: cum poți obține un calendar al lunilor din orice an? Cauți când a picat ING home bank pe google.)).