Slashdot Mirror
The Truth About Hiring "Rock Star" Developers
snydeq writes "You want the best and the brightest money can buy. Or do you? Andrew Oliver offers six hard truths about 'rock-star' developers, arguing in favor of mixed skill levels with a focus on getting the job done: 'A big, important project has launched — and abruptly crashed to the ground. The horrible spaghetti code is beyond debugging. There are no unit tests, and every change requires a meeting with, like, 40 people. Oh, if only we'd had a team of 10 "rock star" developers working on this project instead! It would have been done in half the time with twice the features and five-nines availability. On the other hand, maybe not. A team of senior developers will often produce a complex design and no code, thanks to the reasons listed below.'"
This sounds like a desperate justification for doing it on the cheap. And the "truths" are badly flawed. First, the term "rockstar" is already pretty bad and way off. A very senior engineer is not a "rockstar". Rockstars are people that crave attention and can generate it.
As to the items:
1. Wrong. If you hire highly competent and professional people, the savings in time, maintenance, etc. will be far higher then the higher salary you have to pay them.
2. Wrong. People in the described situation have trouble seeing the big picture, and will get details wrong as well. Their code will basically barely good enough if you are lucky, but it will be a nightmare of maintenance, architecture and design issues.
3. Wrong. This is confusing "rockstars" with very senior engineers. Very senior (by experience and capability, not age) engineers will know this pitfall (hint: Brooks calls it the "second system effect", a really senior coder will know about that) and will know how to avoid it.
4. Well, yes. But what is the point? If the hiring process is run incompetently, of course you will get bad people. That is in no way the fault of the good people that are out there as well. Seems to me the author needed an excuse to bring it up to 6.
5. Wrong. This is a typical problem of people that may think they are senior when in fact they are not. Also see 3 and 4.
6. And here the truth is revealed. This person does not want senior individuals that actually know what they are doing and may criticize as stupid plan. In fact this person wants no individuals on the team, so everybody can be replaced easily and knows it. Yes-men preferred. Unfortunately that is a sure recipe for disaster.
Bottom line: All there "truths" are wrong or irrelevant and show the real problem: The author of this article has no clue and is a "rockstar" himself. But not one of those that can actually do things right. Just one of those small people that cannot handle others being better at something than he is.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
and every really hotshot piece of software I have ever encountered (and I'm talking world-wide success here) has been written by a very small team of highly-motivated developers working very long hours at very odd times of day with no management interference at all. They weren't rock stars before the project or they would have been managed into oblivion. After they had completed the product and it became successful, then they were rock stars. The self-motivation usually came from "fuck you, manager, I'm going to prove that my ideas are correct" One of these projects, where I knew the people well, became one of IBM's top 5 most profitable products world-wide (you've never heard of it), and those guys broke every rule in the book. They worked nights, never went to meetings, smoked cigars at their desks, suppressed all records of how many hours they were really working. By working those hours, the two of them held the entire structure of a big application, its database, and all its interactions with the operating system in their heads, and that mental state enabled them to write vast quantities of simple clear code that contained no serious errors on shipment, and none revealed in the first year. Later people added on to the project for subsequent releases never found any serious errors in the backbone written by the first two guys, nor did they have any problems adding to the code.
Code written during the normal working day, with constant interruptions, will never soar like that.
"Cock Up Your Beaver" does not mean what you think. This sig is intended to clog filters and annoy do-gooders
If you have 40 people writing spaghetti code, then you need _one_ good developer and code reviews, and reject bad code until they learn. Many bad developers are bad because they haven't learned how to do it better. Those that can't learn - sorry, but their productivity is negative, so let them go. What you don't need is a dozen "rock stars". You need developers who can lead by example and let them do it, and who can solve difficult problems that turn up, and you need more people who are reliable, not necessarily bright, who can do all the boring bits - of which there are usually lots.
What I can't understand is how the author talks about smart people making smart designs that don't work. If the design doesn't work, it wasn't smart in the first place. If someone creates a design that isn't smart in the first place, that person wasn't smart. So this seems to be about people who can bamboozle others into thinking they are smart, creating designs that nobody understands.
Except they/we are rockstars because they get the job done, despite a bunch of MBA's trying to stop them. I agree with him about too many senior developers, they cancel each other out. I've use teams of 3-4 people, usually one rockstar and 3 who are happy to play second fiddle and follow his lead.
When I've done the rockstar roll (before I moved into managing them). The number of times I've had ineffective programmers try to trip me up. A typical pattern is the 'spec says X', I'm well into the spec, X is already written, a programmer on some other platform is falling behind and hasn't gotten to X yet. What do they do? Typically they will start changing the spec, now X is Y and I have to go back and re-implement X as Y.
Do this often enough and I have to WAIT for the slow coach to decide what he's going to implement from the original spec. before I can clone it on my platform.
Then there's the IBM type guys (I think EDS are the same, but I haven't personally had experience of them yet). I couldn't get them to code at all in any way. I'd receive a mountain of design documents for the most trivial of things, and a million excuses why it would take 10 years and more resources than we had. If I simply went ahead and coded their part, they'd send in the 'Rock Star Business Analysts' to claim it's spaghetti code and the distraction of it was the reason they couldn't code their part.
I've seen IBM do a hatchet job on a Danish software producer, so much that the Danish company refused to continue with the project. Yet I never saw an IBM guy deliver a single line of code that tackled a single problem. All they every did was produce meetings explaining what is wrong with the code (which was nothing but a few bugs they were hired to fix but didn't).
That's the other problem superstar programmers face, superstar bullshitters whose real agenda is to delay a project.
I often think there are superstars in every company, and the difference between a Google and a Microsoft is that one company can tell the superstar developer from the superstar bullshitter, the other can't.