Notch wrote Minecraft when he was around 30. He didn't have 15 years experience in professional engineering and it seems to me he mostly just mucked around writing games in his professional life. He's now recognised as creating more than a billion dollars in value.
Is a "senior" engineer doing better than that at creating software? Did he ever make senior? Does he exhibit all the traits of a senior engineer in the article like not having an ego? This is a profound challenge to the entire industry. The title really is just for HR, a developed ability to choose what projects should be worked on is much more important and there is a big gap between a Senior Software Engineer and someone who actually writes great software.
Spoiler: Minecraft Java Edition is still wildly inefficient despite having a trillion dollar company backing it for 10 years.
Even the latest (apparently controversial) recent redstone update is meant to take account of performance - https://www.minecraft.net/en-us/article/minecraft-snapshot-2...
"The performance impact of Redstone wire (connected blocks of Redstone Dust) has been improved"
I've no idea how true that statement is, of course!
True but the general game loop is still (wildly) inefficient; hence the multitude of performance mods (Sodium, Lithium, FerriteCore, ImmediatelyFast, etc.) that are considered basic mods for anyone wanting to play the game without dipping down to tragic fps.
All of that functionality could (and should!) have been folded into the Minecraft source years ago. But Microsoft didn't buy Minecraft to give people a good experience - they bought it because it generates a non-trivial amount of money from things like Bedrock IAPs, merch licensing, etc. Updating the games is just a necessary evil that keeps the money flowing.
(Bedrock, on the other hand, is much more optimised because, IIRC, the core game was written in C++ targeting mobile devices and needed to be efficient to even work.)
From that lens, Notch's "level" when he created Minecraft is pretty much undefined. He obviously had technical and entrepreneurial skill, which gave him huge credibility, and is a fast-track to a certain title / level at acquisition time, but that says very little about his ability to meet the expectations of a Microsoft engineer that worked their way up to that level through promotions.
The problem with any internal definition of "senior" is that it's misaligned with the market. If you pay someone less than their market value, they're likely to leave for a place that appreciates them more. If you pay someone above their market value, you're basically putting golden hand cuffs on them. I'm not saying I never did those things, but I did have almost exclusively bad experiences with both of these situations. And I've hired something like 200 developers in my CTO roles.
If I have a senior whose salary I'm reluctant to raise, I wonder about three things: Do they actually have enough experience to be in that bracket? Is that person perhaps just not a good fit for what we need? Do I perhaps have too high expectations in seniors that made me inflate their salaries?
If I have a junior whose salary I want to raise, I think about similar questions, but I also wonder if that person perhaps went above and beyond and a bonus is more fitting than a permanent raise.
Sounds a bit cold and rigid, and of course there's exceptions to any rule, but this guiding principle has served me best over the years.
Creating my own, literally made up and company specific, job description for a senior has pretty universally back fired. My company isn't a special snowflake that gets to invent their own job market. It's much more reasonable to connect to the actual job market.
As for titles, I usually didn't put "junior" or "senior" in them at all as far as I could get away with it. For the most part, my seniors were fine, many even happy, with this.
That's The Critical question. That is: the situation needs X (read: combo of hard tech skills and soft skills). Can they deliver X and then some?
If not, there's three choices:
1) Develop them to fill their deficiencies, if they're interested.
2) Communicate with them that the biz has evolved and the fit is a misfit. This happens with founders who evolve into CEOs and don't have the chops for that role. It happens.
3) Do nothing.
Note: A seasoned employee will always be asking the same questions. That is: is this the place for me. Should I stay or go?
Great leaders and managers are aware of the mutualness of the relationship and approach it from that pov
It doesn't sound like good management, and perhaps it isn't, but I did have people that didn't entirely meet my expectations stay, without gratuitous raises of course. I'd be open about this with them: "I think it'd make sense for both of us if you worked elsewhere, and I can help you figure out where that could be and how to get there. But I'm also gonna offer you a path here if you want it."
Sometimes that turned out to not be a good decision. Sometimes it was. But I felt it was a humane solution to the problem, that exceptional situation. No manager is all-knowing enough to understand to 100% what value they're getting out of each individual employee, so it's not the most illogical thing to involve them in that decision. But more than anything, I'm not a fan of changing a system that works for the general cases to deal with rare and varied edge cases. That's premature generalisation, and I think both in software and in organisations, that is the root of all evil.
Do they not want ppl able and ready to learn? Does the market not change? Is the dynamics of the org that ridgid?
Sometimes ya just gotta go with what ya got (and toss in some individual and team development). It will never ever be perfect.
So instead of golden handcuffs, you apply lead handcuffs, forcing them to lie in their resume if ever they have to apply elsewhere after the day they age out of the slim age bracket in which they would be accepted at anything below senior?
What is that age bracket, in your opinion?
That's what i meant: the titles don't have to mean anything in your company, but if you don't hand them out, even if only as a meaningless formality without any consequence, you're making life unnecessarily hard for employees when they need to look elsewhere. That's why i called it lead handcuffs: it makes leaving more difficult. And i don't get the impression that it's an intentional strategy ("yay, less fluctuation! Let's call them all junior janitors!"), that's why i was pointing out this aspect of "no junior or senior".
How can you expect anything substantial from senior developers if you promoted them purely on experience measured in time?. How anybody would be motived if they can just wait for promotion? How can hire people on senior positions if you do not have internal metrics for these positions? How can you get rid of underperformers?
If you have someone very experienced with a high market value who doesn't really pay off in terms of what value you can extract from them, it can make sense to look into an exit - or an exception.
With the amount of people I managed in the past, I rarely had to make exceptions. Your mileage may absolutely vary though, and there's certainly no one-size-fits-all solution. Management is hard, easy solutions and "best" practices rarely exist.
Seniors can do things that are hard or impossible for juniors. A good senior developer can bootstrap a project to MVP, establish best practices, onboard and mentor juniors/mid, communicate effectively with stockholders. Senior can manage technical debt and help with estimation and roadmap. Even on purely technical output, they can be few times more efficient than juniors. Many people will fail to learn these skills even after many years working as developers. Experience is important, but overall it is a smaller part of the overall skill set of a developer. I know plenty of people of 10+ years of experience that are just mid level developers and will stay this way.
> If you have someone very experienced with a high market value who doesn't really pay off in terms of what value you can extract from them, it can make sense to look into an exit - or an exception.
If you do not have metrics other than experience, then how you can know what value to expect? I get the feeling that you hired senior developers and then put them into mid/junior level roles and responsibilities. Value that you get from senior developers depends on opportunities that you give them.
> With the amount of people I managed in the past, I rarely had to make exceptions. Your mileage may absolutely vary though, and there's certainly no one-size-fits-all solution. Management is hard, easy solutions and "best" practices rarely exist.
That there reason why software in Europe losing to US. You decided on an easy solution to measure developers by experience in years instead of actual output. You want to extract value instead of create a value. Furthermore, you also do not want to pay senior developers because you do not understand the unique value that they can bring to the table.
When a master says you're ready to independently take on customers and have what it takes to satisfy their needs you become a journeyman, and when you've practiced long enough to have pushed the boundaries of the craft and reliably do things that masters can learn from, then they might count you among themselves.
A 'sufficiently capable' junior can run the show for a bit. I've been them, for better or worse. I'm great at the technical side but admittedly terrible at the 'softer' people aspect.
Multitudes, yo. Thanks to a lot of incident management experience, I'm the Dictator you want when the sky is falling. However, I'm absolutely best ignored when it comes to politics or making plans months out. My bias here is more apparent than normal, stability.
Titles are made up, just like the rest. Trying to apply these too much is suspect
I know a guy who became significantly more short-fused and less friendly when he was promoted into management. I don't think he liked management work, particularly when it involved both that and fulfilling outstanding responsibilities as an IC because he was the sole SME for a variety of different products/systems we had. There were many sad-sounding conversations with his then-girlfriend well after close of business.
Point being, sometimes people who turn into jerks when promoted are not necessarily narcissists, they just have a shitton more work to deal with now and/or are out of their element and/or can't get home to spend enough time with their SO/kids/pets to fully psychologically reset at the end of the day. I don't know how that description tracks with the devs you knew, though.
Seniors are juniors with a label and expectations applied. It's incredibly subjective of course. To your point, I find the conventional expectations of 'Senior' too high.
I have spent decades perfecting my technical skill. Literally since childhood. My personal skills have suffered, neither I or you want me to be a talking head.
The story of the Junior who doesn't get enough help is a bit self-fulfilling/lacking in context. How much has been given/stuck/to who? Hearing 'not enough' can either raise someone to the challenge, or create resentment.
A bit of closing irony. I was fine with providing on-site training as a Senior until RTO was ham-fisted so poorly... that I found an even more illustrious 'Principal' title, and expectations, elsewhere.