Then you will need two senior devs. This is because rockstar devs rarely want to mentor junior devs nor attend meetings.
Most inventors are not professors.
Then they aren't a rockstar. And frankly, I've spent my career cleaning up the obfuscated, badly documented, untested code of "rockstar" devs.
The idea of a "rockstar" you seem to be referring to has, in my experience, been a dev who can go into a corner and pump out high volumes of code with little supervision or collaboration. That's great, except no one else can make sense of the code they pump out, so when it comes time for the next guy to add a feature to the rockstar's mess it takes 2 to 3 times as long as it should.
I've also had to clean up messes by rockstars who made unilateral decisions about incorporating new technologies into a product. Like building out a single part of the product in React with out asking anyone else. You see, the rockstar didn't like meetings and didn't want to make the case to the rest of the team for why we should all learn React and gradually switch over. Instead, he just stuck it into the code. So now, you have a couple of views built as React components, and the rest of the thing is in Backbone. No one else knows React or has time to learn it, cause we're blazing ahead really fast. They just get very confused when they have to change something in those components and it takes them forever. But the rockstar got to have his fun and play with new tech.
This conception of a "rockstar" isn't a great developer... it's a selfish, cocky developer. When you hear "rockstar" dev, you shouldn't hear great performer. You should think of Keith Moon trashing his hotel room and driving his car into the hotel pool.
A great dev knows the value of documenting their code and writing testable code. A great dev knows the value of taking the extra time to make code easily understood and easily modified -- that sweet spot between spaghetti and over engineering. A great dev loves to mentor junior devs, enjoys walking other devs through their code, is happy to discuss design decisions with the team, and willing to admit when maybe their idea isn't the best one.
A great dev doesn't think they are god's gift to code, they are humble enough to understand they are one part of a team. They put the team first and work hard to teach others what they know, while always remembering they don't know everything.
That's why I've always told people that I'm a "studio musician" developer. Not a rock star, but a competent professional the studio calls when they need to make a record.
That's what I'd been saying for a while -- the best devs are session musicians. They have enough all-around comoetence to deliver what is asked for for that particular recording.
Normaly session musicians are better than rock stars James Jameson (funk brothers) was a better bassist than Paul McCartney, and Paul would admit that.
I have worked with a Musician with Phd in music who taught him self coding after an accident broke all the bones in his feet (drink had been taken)
It was fun in the pub when some hit tracks came on he would say ah I think that's one of mine :-)
Near as I can tell, the term stems from the 80s computer gaming industry, in which the game studio heads got the idea to promote the individual developers by name as if they were rock stars, and oftentimes attempt to treat them to the "rock star lifestyle" (girls, parties, etc.) in order to keep their output from flagging. In those days, games were often written by teams as small as one, and no bigger than a handful -- and the studios themselves were often fly-by-night outfits whose idea of "product packaging" was a Ziploc bag to ship the disk and manual in.
Eventually in the 90s, some developers really took the rock star bit to heart and started plastering their own names all over their output (cf. "John Romero's Daikatana", "American McGee's Whatever-American-McGee-Is-Working-On-Now"), but for the most part, developers at the time hated the rock star characterization.
Electronic Arts started as an outfit for people like this, as did Activision. It's saddening to see how much their ethos has changed in the ensuing 30-40 years.
A great dev gets out amongst his user community and finds out the real feelings of those who are using the software. The great dev tries to understand the actual user requirements (not just what has been supplied by the design docs). The great dev listens to the criticisms of the users and discusses what can and can't be done.
I don't disagree with your "great dev" qualities but there is more needed to make a "great dev". Otherwise all the documentation, code ease, mentoring, being a part of the team, etc. is not going to make the code useful to anyone.
The whole "rockstar dev" branding has always made me cringe, but my opinion is software should be made by rock bands. Sometimes you have to play bass and not get laid.
First off I hate the phrase "Rockstar dev" because it gives the impression that someone can be successful without the support of the team, which is wrong.
Second, I hear this extremely often: Rockstar devs don't like to mentor, Rockstar devs don't like to write documentation, Rockstar devs don't like to write tests.
At what point do you need to reevaluate your definition of a rockstar dev?
The hiring filter is a powerful thing. It allows you to find very special people if you know how to look. It's also a feedback loop. Getting momentum with a program like this is the hardest part. Once it's going it practically self sustains. The biggest part of your role becomes quickly firing any mistakes.
Rockstars are lone wolves, write unmaintainable code that works quickly for demos but gives the company pain for years to come as nobody can figure out how to make it stable or maintain it. A rockstar's reputation is self reinforcing because it's easy to get a lot of shit done when one doesn't have to worry about maintainability, communication with the rest of the team members or the company at large, and service.
Senior devs balance development work and "service", a term I'll borrow from academia - hiring, mentoring, speaking, writing docs, etc. They either find fun in these tasks as well (I legit enjoy interviewing and mentoring), or understand this is a necessary part of being a well functioning team player at a senior level.
You hire the rockstar to write version 1. That's the one that gets you to market fast, and the one you should be planning on throwing away. It's the one you keep in production as your non-rockstar ninja and guru coders write version 2 from scratch. Once you release version 2, you really need to fire your rockstar. They will never be happy in maintenance mode, and that's fine, because they're usually bad at writing for maintainability.
Then you can hire some boring reliable folks from the khaki-and-polo brigade to help upgrade version 2 to version 3. This is when you have an opportunity to hire juniors and mentor them on what good software actually looks like, and how to make good-enough software better. The ninjas will probably leave at this point, and if they have done their job, the company will never need that level of expertise again in a permanent employee. The gurus will stay on to be an expert in your specific system, and teach the new people how to preserve its grandest traditions.
The problem is that a lot of companies never get to what I call "version 3". They might slap higher release numbers on it every so often, but if they never did a clean re-implementation of the quick-and-dirty prototype, that's still "version 1.X", no matter how high the numbers go. You put a junior in that environment, and they're not going to become a stable maintenance developer, and that's where the majority of the jobs will be for the foreseeable future, especially for inexperienced people.
To sum up: rockstars live fast and die young; ninjas quietly demonstrate incredible skills, and vanish; and gurus are the high priests for your established project, who will eventually pay off all your tech debt, if you let them.
There are different breeds of senior developer, and you really want the gurus teaching juniors when they start to run short of other useful things to do. If you don't have the kind of company that is mature enough to evolve a developer into a guru, you won't be able to handle juniors. And there aren't enough companies that can handle juniors. It may be because they aren't honoring the full software lifecycle that includes the long, long tail of maintenance mode.
I think the never getting there often happens because management isn't aware of the current quality of their software vs hypothetical quality of a rewrite.
And I get it: I imagine every one of them has been burned by an overly optimistic developer. "It'll be rewritten in 3 months and run 2x as fast" types.
As a discipline, inculcating "respect that the years of person-work in the current version weren't done by idiots solving unimportant niche use cases" would be very healthy.
Labels like rockstar, guru and ninja are labels we don't need. We need competent generalists and competent specialists who can work in teams as well as work alone and can communicate with those who are part of the team or part of the management and user bases.
When a person takes on for themselves labels like rockstar, guru, ninja, etc. I don't doubt that they can write code, but I certainly doubt that they can write code that fulfils the needs of those who will be using it.
Labels likes these are a detriment to the profession. If we want businesses to take note and consider those in the IT profession to be anything more than ignored, we need to lift our game a long way.
What is IT known for (in the general sense), games, social media, search engines and lots of crappy software that users have to fight to get anything done.
Yet we have people and companies that produce great software that fulfils the needs of those who use it in a way that is not detrimental to those users.
It's coming up to forty years that I have been involved with the industry and I hear complaints every day from users who are frustrated by the inconsistencies in the software they are using, whether it be social media, business software, games, etc.
In general, as an industry, we are far too arrogant about our own self-importance and what we develop. Whether it be the likes of Apple, Oracle, IBM, Google, etc, the industry has forgotten that they only exist as long as people will tolerate the bull dust that is thrown at them by these companies. We are always looking for the "next big thing", yet many of the actual needs that we could be filling are not being done. We like flashy and not substance.
We don't need titles like that at all. Let's change rockstar to MVP Developer, Ninja to Builder, Guru to Experienced Builder, and the 3rd type of developer described in GP to Maintenance Developer. I think the industry could go a long way if it admits that it needs all 4 of these types of developers, so that expectations were transparent for employees and needs are transparent for developers.
I object to those terms. The rockstar is most definitely not the MVP. To the extent that I have worked with any, they are the insufferable primo donnos that fill the garbage bin and set it on fire then they proselytize their own trash fire to management until they think it is "hot", "energetic" and "enlightened". The rest of us then get stuck dealing with their legacy issues. If you're going to title-ify it, how about "prototype developer"?
The others can be "foundation developer", "transition developer", and "maintenance developer". It's still meaningless as long as different companies won't standardize on those titles.
We likely all know which category we belong to now, and which one we want to be. We also know that any company that asks directly for a "rockstar", "ninja", or "guru" is probably one to be avoided.
Yes to both of these, but there are other options as well.
The frustrating ones are those who talk a good talk about "doing things right" (and, generally, talk a lot...), but then work on something for an age and come back with a solution that's objectively worse than the "RIGHT NOW" solution we've been using in the interim.
This is not a great example.
In academia, that's because they are fundamentally different jobs in most cases.
Most of the professor roles are not teaching their research, and where they are, i would bet your best professors are the inventors. But most are researching x and teaching y.
By contrast, in software development, the devs should be teaching, because what they are teaching is what they are doing on a daily basis, and the knowledge they've learned in how to do that well.
The notion that people who refuse to mentor or attend meetings (assuming these are symptoms of the same "not team player" phenomenon, and not something else) are rockstars is, imho, pretty misguided.
Even if you assume the 10x people silliness is true, each person mentoring 2-3 new people and building them will make the organization more productive than your 10x person fairly quickly.
(Again, situation may be reasonably different if you only will have a team of one or two, etc)
> By contrast, in software development, the devs should be teaching, because what they are teaching is what they are doing on a daily basis, and the knowledge they've learned in how to do that well.
I don't agree, senior tasks are often much more high-level and related to figuring out requirements/stories, or their tasks are hard enough that explaining them to juniors is not the most productive.
I'm kind of confused here, so i feel like i missing something.
The way this is written makes feel feel like you you don't think the junior devs need to become competent at those high level tasks over time?
Otherwise, how do they become senior devs if not by things like "gradually delegate higher level work, see what happens, help them learn by mentoring them based on results".
It's not like they read a book and suddenly know how to do that.
"hard enough that explaining them to juniors is not the most productive"
I strongly doubt this. Most of the differences i've seen over the years are in approach to complexity, and not level of complexity themselves.
If you don't want to teach, you're not a rockstar. The best developers I know have always been ready to show and explain what and why and how. Inventors love to talk about their inventions.
Teaching isn't a simple matter you can flatten down to like/dislike.
One aspect of teaching is explaining your inventions to your peers.
But another aspect is telling a new graduate what a version control system is and why you need one. Then doing the same for your build system, continuous integration system, staging environment, code review, bug tracker, style guide, and so on.
Seems to me those are quite different skills - I can easily imagine a person who is good at / enjoys one might not be good at / enjoy the other.
To a first approximation there is no such thing as a "rockstar" developer. I mean a few of them exist, but the actual stars (not poseur wannabes) are already locked down doing other things so it isn't possible to hire them anyway. If you're hiring or building a team you have to target developers who are actually available, not the stars.
The idea of a "rockstar" you seem to be referring to has, in my experience, been a dev who can go into a corner and pump out high volumes of code with little supervision or collaboration. That's great, except no one else can make sense of the code they pump out, so when it comes time for the next guy to add a feature to the rockstar's mess it takes 2 to 3 times as long as it should.
I've also had to clean up messes by rockstars who made unilateral decisions about incorporating new technologies into a product. Like building out a single part of the product in React with out asking anyone else. You see, the rockstar didn't like meetings and didn't want to make the case to the rest of the team for why we should all learn React and gradually switch over. Instead, he just stuck it into the code. So now, you have a couple of views built as React components, and the rest of the thing is in Backbone. No one else knows React or has time to learn it, cause we're blazing ahead really fast. They just get very confused when they have to change something in those components and it takes them forever. But the rockstar got to have his fun and play with new tech.
This conception of a "rockstar" isn't a great developer... it's a selfish, cocky developer. When you hear "rockstar" dev, you shouldn't hear great performer. You should think of Keith Moon trashing his hotel room and driving his car into the hotel pool.
A great dev knows the value of documenting their code and writing testable code. A great dev knows the value of taking the extra time to make code easily understood and easily modified -- that sweet spot between spaghetti and over engineering. A great dev loves to mentor junior devs, enjoys walking other devs through their code, is happy to discuss design decisions with the team, and willing to admit when maybe their idea isn't the best one.
A great dev doesn't think they are god's gift to code, they are humble enough to understand they are one part of a team. They put the team first and work hard to teach others what they know, while always remembering they don't know everything.