Slashdot Mirror
Ask Slashdot: Are 'Rock Star' Developers a Necessity?
An anonymous reader writes "Do you think so called 'rock star' developers are necessary at every company? Personally, I don't think so, and I equate it to not needing a college degree to work at Walmart. If you give every problem a complexity value from 1 to 10, and your problems never get higher than a 6 or 7, do you need people capable of solving the 10s? I work for a large software company and I'd rate myself a 7. There are more technically proficient developers, but I don't have an ego about my work, I work well with coworkers and customers, and I bring people up around me. Most 'rock stars' I've seen have been difficult to work with. Most of them are no longer with the company because they were terminated or quit for more money. Is this usually the case? Is it worth the trouble? (Note to any managers reading this: if you have a rockstar who is a pleasant person, pay them well; they are very rare.)"
The term "rockstar" is subjective and only douchebags use it. You could be considered a rockstar because you say you are bringing those around you "up" and are probably doing that by learning and training others about what you learn. You may not know how to develop something in a way when you start but you can learn and apply it when you do. I f-ing hate terminology like that.
You're conflating two unrelated things: Competence and attitude. You might find The No Asshole Rule an interesting source. People who can't cooperate with other people are not a necessity, no matter how amazing they are.
But... When all you have is a hammer, everything looks like a nail. The thing that makes exceptional developers exceptional isn't their very specialized ability to solve weird problems no one really needs to solve. It's their ability to spot an opportunity to replace a hard problem with an easy one, or to massively improve performance by solving a slightly harder problem. And that really is that useful, even if you don't directly see the benefits. You can do nearly everythign with plodding, methodical, mediocre work. Doesn't mean you won't be happier with the results if you have someone better available.
My blog: http://www.seebs.net/log/ --- My iPhone/iPad app: http://www.seebs.net/seebsfrac/
I'm a tech lead at a startup and have worked at mid-size companies (I've avoided large corporations). Even if your problems are difficulty 10, you don't need a "rockstar" to solve them. My experience with typical rockstar developers has been similar to yours, they work poorly with others, communicate poorly, and often write inscrutable code. I firmly believe that nobody is invaluable. No company can afford to have a person that were they hit by a bus, or just left, the company would fail.
There are plenty of developers out there that wouldn't be considered "rockstars" in the stereotypical sense but when given a problem, I know they will produce good, well thought out, performant code within a short period of time. During development they will seek out criticism from their peers (and they see the rest of the team as their peers) and the final solution will be respected and understood by the team. I think of these people as seasoned engineers, not rockstars and certainly not developers. Engineers break down problems and build a solution before they ever write a line of code. I also believe you can become a seasoned engineer rapidly, possibly even straight out of college. It's about perspective, not necessarily experience.
One of the most important things in an engineering group, in my opinion, is the ability to walk into a room, argue out a solution, possibly admit you're wrong and somebody else's solution is better, but know when to fight your corner, then leave the room as friends and colleagues, ready to build the solution together. The ego rockstars carry makes that scenario impossible.
You need to define your question better.
If you mean "A coder who is very good at solving problems," then yes. Every project develops problems that brute force and more manpower can't accelerate. Someone who can break the logjams is useful everywhere.
If you mean "someone who is super-smart but also an ass," then no. I'd rather have a solid team beat on a problem for a week then allow a morale-killing ass to poison the environment.
Many development project don't need a 'rock star'. They can be done with "typical" architectures, existing frameworks, and just need "assembly-line-type" workers for all of the steps. I'd even say "most" projects are like this and any project can survive without a rock star.
There are also different types of 'rock stars' and they can help on even the most basic project. In general, the 'rock star' can do any/all of these things, but what do they do on a day to day basis varies based on their individual "specialty"
* some can architect the "difficulty 10" projects so it can be implemented in assembly-line fashion by "typical" developers
* some can implement the "difficulty 10" projects that wasn't architected well (when a team of N "normal" developers would end up with a late and buggy implementation)
* some can debug like nothing most people have ever seen (they don't usually create difficult-to-find bugs but are a huge asset to the team when the bugs come up which can happen on even the most trivial project)
* some just implement so well (speed of development + lack of bugs) that they literally will be cheaper than a team of N people (so, to the manager they aren't necessary but would be preferred)
* some can mentor, and find other people's strengths, and reorganize efforts on the fly. they can help everyone else be more productive, and can adapt the process/team as requirements change and can be critical to delivering on time and above requirements especially when things go wrong.
* some can help where ever needed (front-end, db, back-end, sysadmin, security, build, etc) and can step in without losing a beat when another member of the team is out (sick, vacation, left for another job).
* some can find bugs in 3rd party libraries or system components (without the source code). find workarounds and/or patch those libraries to continue development quickly while sending the bug fix and appropriate level of explanation to the library developer to get a permanent fix. If you've ever been on a "difficulty 5" project which found a show-stopper bug in a critical 3rd party library during QA, you'll really appreciate this skill. I have seen one case on a "trivial" project where this skill was necessary and a few other cases where it really helped.
I've worked with a very small number of "rock stars" over 30 years. They all had multiple of the above skills. I've worked with 3x as many people who were considered "rock stars" (by themselves and sometimes others) but weren't. In almost all cases, the "fake rock stars" slowed the project down more than they helped and the team would have been better off with one less member.
I dunno, I think the guys in the band without a rockstar make a lot less money.
No definition provided.
The concept of "ROCK STAR DEVELOPER" is a fiction invented by professional recruitment outsources. All developers are "Side Men" - even if some are in the "Musical Director" category.
"Flyin' in just a sweet place,
Never been known to fail..."
Clarification of who you are. You are a mediocre to below mediocre programmer with an inferiority complex. Your code is always bug ridden because you can't even review a simple Slashdot post properly before you hit submit. You regularly apply commits to the repo that pull the rug out from under the true developers, and you often screw the commit up because you just learned about revision control in the last year and still think SVN is where it is at. You have heard of git, but it is too complicated. You need antacids because you can't get the sour grapes out of your mouth. Did I miss anything? Oh yeah. That's right ... you are going to create a Slashdot account just as soon as you figure out how to do it.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
And it is a constant challenge to make sure I am not talking down to people, or seeming to snotty.
Try this method:
"If the next thing you might say is douchey, skip it and think of something else. Repeat as necessary."
As a programmer, you'll immediately think of improvements to this algorithm, but if you are a good programmer, you'll understand the pitfalls of premature optimization. Keep it simple.
Yep. I've worked with a few people I would consider "Rockstar" programmers in the "non-asshole" sense. They were fun to be around, considerate, polite, knew their shit inside and out, and tutored / mentored me and others to become more effective at the parts of the project we worked on.
These days, the first interview question I throw at new candidates is "Tell me a story about a time you had a technical difference of opinion with another person or group, and describe what you did to resolve your conflict and move forward". It's a behavioral interview tactic I picked up from a former big employer, and it tends to be fun to note how much they squirm while recounting past bad blood. Now, no one has really ever totally bombed this question, but making them talk through some of their uncomfortable scenarios provides some good insight into how much experience people have when they inevitably have to deal with conflict resolution... and the mere fact that we ask it kinda prompts them with the expectations we have of our employees for cooperating with others in our environment.