The Truth About Hiring "Rock Star" Developers 487
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.'"
Troll Indeed (Score:3, Interesting)
...No, you don't need 10, idiot,....
That's the attitude and one of the things that made my time as a developer miserable. It wasn't enough that I was under constant pressure to meet unrealistic dealines and spending all my free time keeping up with new tech, I had to put up with that kind of abuse and the constant intellect pissing contests and penis measuring.
The other was the fact that you couldn't say "I don't know. Let me research it." Any sign of ignorance or weakness would get you fired or the very least treated like a moron by one's colleagues.
Last year, I saw the National Geogrphic show on Stress. To make a long story short, the guy who was researching monkeys made some observations about them that reminded me of working in software development.
Desperate justification for hiring cheap people? (Score:5, Interesting)
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.
I've been in this game a looong time... (Score:5, Interesting)
Code written during the normal working day, with constant interruptions, will never soar like that.
The article is frankly stupid. (Score:5, Interesting)
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.
Re:Don't hire union workers (Score:2, Interesting)
Every time somebody brings up the topic of unions in the US, I find myself wondering whether "union" is one of those terms like "potato chips" or "football" that means something completely different over there.
Re:Don't hire union workers (Score:2, Interesting)
not sure why he equates senior developers with rock star developers, for me rockstar developer is someone able to do very complicated piece of functionality that a team of ordinary (even ordinary senior developers) would need a month for, and do it alone in less than one week with ten times less bugs, you know people that not only have 10+ year experience but also high intelligence
They're rockstars because they get the job done (Score:5, Interesting)
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.
Re:Don't hire union workers (Score:4, Interesting)
My brother used to work summers fixing lawn mowers for Sears. He was forced to join the Teamsters (fell under delivery, I guess).
The masthead for his monthly Teamsters newsletter looked like the dramatis personae for a mob movie. There were like 15 names, and every single one was Italian with a nickname in quotes in the middle. Crap like "The Knife" aand "Lefty".
If running for union leadership was a class in an MMO, the character creation sheet would have a line for "Enter nickname here. This is your mob handle and will show up in double quotes over your head between your first and last name."
Re:Who is the author, and what has he done? (Score:3, Interesting)
Another key piece of why programming tests are useful: If you give out some relatively easy problems, you learn a lot by finding out not just whether the candidate can solve them, but what it took for them to solve it.
For instance, I recently gave a relatively simple problem to 1 developer who seemed competent from the resume and our phone conversation: She took a quick look over the problem, typed for about 3 minutes and showed me her completely correct solution. I gave the same problem to another developer who seemed competent: He hunted and pecked for 15 minutes, poked through some documentation, and wasn't completely on the wrong track when I cut him off.
When you get clear results like that, the decision of which candidate to hire becomes really really easy.
Oh, and never ask stock interview questions, that's just a waste of time. Much better to ask them to apply their purported knowledge and experience to situations that might arise in the job, and use their answers to extract out thought patterns and problem-solving approaches. The fakers get really obvious in these kinds of interviews, and also really clear is whether they take any pride in their work or have a personality problem which would make them an ineffective employee.
Re:Don't hire union workers (Score:5, Interesting)
The link between labor and organized crime is an important one but not for the reasons you want people to think.
The link between labor and the mob formed because US corporations had their own private armies that were able to gun people down. The labor movement in the US quickly turned violent and labor needed it's own muscle.
The mob is just the other side of the coin.
Re:Unmanageable (Score:4, Interesting)
he's a whiny sod who no-one likes.
That's a typical subjective evaluation too easily made and abused for nefarious purposes. You forget the power of office politics. He could be a well-mannered, polite person who was given the brush off and shoved into a closet, for political reasons. The other people on the "team" were afraid they'd look bad, and this would imperil their jobs. So they maligned and sidelined him, behind his back of course. Said he wasn't a team player, and a whiner, and all sorts of other difficult to assess bad qualities. Blamed him for every problem regardless of actual fault. By such means, the cabal can cover up their own mistakes and push a dangerous rival closer to termination at the same time. They may even resort to sabotage, "accidentally" deleting his work, for instance, then enjoying it when management roasts him for lack of productivity. Very Sienfeldesque. Who is management going to believe when it's one person's word against 5?
Think cabals like that are uncommon? When people are feeling their own necks, feel they can't afford to be nice or fair, situations can quickly turn ugly. It can get rough when one team member greatly outshines the rest.
Meanwhile, the rock star programmer will soon figure out what is going on. What is he to do? The rest of the team has turned against him, and is determined to make his every effort end in failure. He didn't do anything to deserve that, his "crime" was merely being too smart. He could try to rise above the pettiness, ignoring the politics and concentrating on the job. That might work, but much depends on how able the others are at sabotaging him. He could try to befriend them, help them with problems and the like, but that may simply not work. When someone has to be voted off the island, all he is really doing is persuading the others to cut someone else's throat instead of his. Each may still think that their best chance is to get rid of the most dangerous competitors first, while they still have numbers on their side, and the rock star can't dodge that assessment. Once he's gone, the rest have better chances against one another than they would have against him. He's a dead man walking in an environment like that. He could therefore play dumb, but it's difficult to maintain the facade for any length of time. If he complains to management, he merely confirms that he is a whiner. If he quits, he gets painted as yet another flighty, difficult prima donna, further confirming the general view of rock star programmers. This view is very convenient for the incompetent masses, and they are quite good at suckering management into that kind of thinking, that too good is bad, and too smart is dumb. And so it is perpetuated, in crummy articles like this one. He could try to demonstrate to management that the rest of the team is incompetent, show them for the conniving, treacherous scum they are. But this is likely a waste of time. It's rare that management is at that borderline level of competence where they didn't already know it, but once there is evidence, they will be convinced, and will take appropriate action. If they are newly arrived, then there's a chance. But if they've been there awhile, forget it. More likely, they already know the team plays dirty, and can't do anything about it thanks to nepotism. They may not care. Or, they don't know, in which case they can't be very good managers, not to know the temperament of their subordinates. If they aren't any good at that, they won't be much good at seeing through the bull, and are more likely to fire him than the real troublemakers. The management may even side with the incompetents, seeing them as kindred spirits.
Re:Don't hire union workers (Score:5, Interesting)
One of the biggest problems with a capitalist system with a welfare safety net is that there is usually a dangerous gap between welfare coverage and financial independence. It doesn't do any good to be on welfare getting all the health care you need and then get a "real" job that offers no health benefit or a health benefit that you cannot afford. Another thing that Germany is doing well is their private health insurance system. It's actually similar to the US system under Obama, except that everybody pays the same percent of their income to fund the system. In the US programs like social security and medicaid tax the working and middle class, but incomes over $100k are not taxed. If the higher incomes were taxed for social security at the same flat rate then all people could enjoy a more secure retirement. As for health care, insurers in Germany are more regulated and can't just screw their policy holders like they do in the US.
Point is, welfare programs become a trap because making just enough money to no longer qualify for the aid will leave you exposed to so many economic barriers that you inevitably fall back into welfare whether wanting to or not. Someone on welfare may love to walk away with a job paying $40k+ per year, but maybe not so much if the job pays only $25k with bad work conditions, unflexible scheduling, no benefits, and the recipient has special needs children. In the later case I could understand why a single parent would try to game the system to stay protected by the welfare umbrella.
An alternative would be a form of socialism where everyone has a right and equal access to a baseline level of support, such as government hospitals and clinics, access to community gardens and food pantries, affordable housing projects, etc. When access to such basic needs is universal, then there is no counter-incentive to productivity. People may naturally prefer to work at a job or start a business to have nicer things in life than a subsistence serving of raw vegies, a half-day wait at a community clinic, a shared room in a dormitory, and mandatory 20 hours of labor for the able-bodied to qualify. Knowing that the safety net is available would encourage more lower-income and middle-class to take some risks in starting a business which is good for the economy as a whole. People might be motivated to save a reasonable amount of money - which is good, but also motivated to spend and invest, which also drives the economy. Such a system, however, cannot allow the able-bodied to just lounge and accept a passable existence. Those receiving the aid would have to also provide the labor, but it would ensure that "unemployment" would be virtually non-existant - there would only be those employed at the subsistence level and those employed independently.
Such a system doesn't necessarily make people "dependent" on the state, since they can attempt at any time under any circumstances to work independently to earn a higher standard of living without being fearful of earning too much and losing benefits, and they aren't "dependent" on the major corporations because they could always quit at any time, endure a short term on subsistence benefits, and then choose to work somewhere else or be self employed. The only risk to such a system is if the government outsourced the "management" of the system to some private for-profit corporation, which is how the US likes to do things.
Re:Summarized (Score:4, Interesting)
Re:Rockstars aren't all they're cracked up to be (Score:5, Interesting)
There are both kinds of awesome coders. Most often, seriously good coders wind up being the lone-wolf type simply because pairing them with other coders just slows them down. Most coders I know who don't suck prefer to work alone. It's one thing that draws them to this profession. Those who suck have to work with coders who don't in order to have any positive impact at all.
I like to think I'm a pretty darned good coder. A lot of coders feel that way about themselves, which is fine. I'm far more into team based development than most, so I generally impose coding practices that help code be maintainable and easily transferred between team members. Partly because of stupid software patent law in the US, I try to "code dumb", using simple algorithms when they will do the job, even when more clever ones would do better.
However, there's one rock-star coder who I humbly admit has skills far beyond what I ever will have: Ken McElvain, founder and CTO of Synplicity until it was purchased by Synopsis, is an inhuman coder. I was the first coder he hired to work with him at Synplicity, and he'd already written 350,000 lines of C code to do FPGA synthesis. I opened one of the more interesting files that implements one of the many ingenious algorithms Ken invented, and just about had a heart attack. It was over 2,000 lines long, and IIRC, it was exactly one function. There were dozens of variables, and most of them were 1 letter. There seemed to be 2 letter variables only because he'd run out of 1 letter options. There were no comments. Thinking Ken must put his comments elsewhere, I grep-ed the whole code base for comments. There was exactly one, that read "This is a hack." To this day, I doubt any other human understands that hack. I asked Ken why he didn't make smaller functions and why he didn't use longer variable names, and he said it slowed him down, because his typing speed was the primary limit to his productivity. Ken types like a fiend. I watched him develop code for a couple of years, and it was amazing. He writes files from first line to last, literally limited by his typing speed, and when complete, he hits a special icon on the desktop that means "Compile in release mode, and if no errors, push to customer download site". He rarely had any use for a debugger, because the only bugs he'd have would be typos (his fingers were not infallible at the rate he moved them).
So, a rock-star like I consider myself to be can help build an effective development team, one where I can be the lead contributor. On the other hand, I doubt I've ever been part of a team that collectively could out-produce Ken. I decided to write the first version of HDL Analyst rather than try to help Ken improve synthesis quality, which was a good choice. I was able to contribute and not slow him down. However, Synplicity basically went IPO on the strength of Ken's coding. That's one valuable rock-star, even if he's not exactly a team player.
Re:Don't hire union workers (Score:4, Interesting)
I like the free market when it works. Toyota eating Ford's lunch ten years ago? Awesome. Google taking the lead in search? Awesome. iPhone destroying Blackberry and Palm? Awesome. But clearly that kind of free market competition has been prevented from working properly in the banking industry.