[logfromblammo]

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.

[ethbro]

Well said. Especially the "Version 2/3" part.

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.

[oldandtired]

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.

[Karrot_Kream]

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.

[logfromblammo]

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.

[vehementi]

minimum viable product

[logfromblammo]

But you see now how the TLA could be ambiguous.

[samcodes]

There are those who get it done RIGHT, and those who get it done RIGHT NOW.

[matfil]

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.

[Gargoyle]

This is one of the best summaries of software development practices I've seen. It's maybe even the way it should work.

[Karrot_Kream]

A gem of a comment. This is why I come to HN.

[zelias]

Great explanation