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.'"
Rock Star Developers, seriously? None of them are that good.
Agreed. Rock Stars suck as developers. And most of them suck at rock, as well.
Those who can make you believe absurdities can make you commit atrocities. - Voltaire
I'm not sure about how unions work in America, but in Germany the purpose of an organised workplace is to have a forum between workers and management. The union wants the company to be productive because that secures jobs and usually results in higher wages. The management want the workers to be happy because then staff turnover is reduced, productivity increased and honesty maintained.
The UK and the USA are falling further behind as they put short-term executive profit over the needs of all classes of people.
No-one who identifies himself as a rockstar developer is a rockstar developer, and no good developer would call himself a rockstar.
I agree 100%. I've had the good fortune to work with some extremely talented developers in my career, and the best of them tend to be very humble about their skills (mostly because they tend to seek out the company of other engineers who are as good as they are.) "Rockstar" is a bullshit term used by dotcom promoters and headhunters.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
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.
Exactly.
If your "rock star" developers are over-engineering the problem, writing bad code or whatever, then they weren't "rock star" developers, but a bunch of ill experienced or underqualified amateurs that's kind of the fucking point.
The article will be better labelled as "If your rock star developers aren't, then they'll produce just as shit a product as developers who don't even pretend to be capable of doing the given task".
I think you've probably just been fleeced.
""Rock stars" - we called them divas in my company - are notoriously unmanageable: many of them are temperamental, don't work well with others"
To me this means they weren't rock star developers. Being a great developers means being excellent not just at writing fancy algorithms, but being able to architect great code, being able to communicate with the project stakeholders to find out what they really want, being able to organise and train other coders to improve their level of competence. If your "rock star" developers were problematic, then I'd argue what you actually had were a bunch of people who managed to sell themselves as being more competent than they were - they told you they were "rock star" developers and you believed them, but in reality they weren't.
"tend to do what they "know" is right instead of doing what they're told"
I take issue with this. Surely the whole point in hiring the best of the best is that they know from experience what the fuck they are doing. If you don't listen to them then you are hence the problem, why hire them if you're just not going to listen to them and do things your way anyway? If you know better then you don't need them in the first place. If you do need them, then fucking listen to them.
Really, it's not difficult. The ones who really do deserve the "rock star" developer title are the ones whom you'd never have any of the problems you listed with (bar the one in the last paragraph which I believe is a flaw with your management rather than them). If you're having those problems then you've hired a salesman. A salesman who is a pro at selling himself at an overinflated price, but not really the person you were actually looking for.
Having an ego runs completely counter to being a great developer or engineer, because if you have an ego you're not capable of introspection, you're not capable of noticing your flaws, your weak areas, and improving them. If your devs have an ego then they're never going to be as good as the ones who quietly and happily just self improve. Take John Romero and John Carmack, one of these has a massive fucking ego, an ego so big it can fill a football stadium, the other has a long history of writing pretty impressive cutting edge code without ever displaying an ounce of ego. The latter has had an impressive career developing cutting edge tech, the former, when he went it alone became probably the biggest flop in the industry and his studio was only saved by a bunch of other previously nameless devs who worked on a separate project away from him.
Egos are a trait of wannabes, real superstars just get the fuck on and do what they do.
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.
"Rock stars" - we called them divas in my company - are notoriously unmanageable: many of them are temperamental, don't work well with others, tend to do what they "know" is right instead of doing what they're told,
No disrespect, but we developers also have a name for people that describe developers the way you do :-)
Let me guess: "Sir".
Bullshit. The definition of a "Rock Star" developer is that they have a history of producing hits. It's not relative.
I have a history of producing software that gets the job done; sells pretty well; people like using; is very stable without too many bugs; and so forth.
I however would definitely NOT consider myself a "Rock Star" developer by any stretch of the imagination. I'm self taught and have glaring holes in my knowledge in quite a few areas. I often look at code from others and go "ah, that's a better way than I would've used" (and then try to use similar things in my own code in the future). For example, after a good 5 years of coding all day every day as my day job, I finally figured out the "right" time to use interfaces vs other methods. My code before that should've used interfaces worked (and worked well) but would be much more maintainable had I really known about their correct usage before. And vice-versa, I came across some REALLY old code of mine that uses interfaces when it makes absolutely no sense to do so (I assume it was when I first heard what about they are)
What makes me not a CRAP developer is that I know I have these holes in my knowledge and am willing to learn from others. That hardly makes a rock-star though, regardless of how much good stuff I've produced to date.
My book about LSD and Self-Discovery
Also on facebook as: DroppingAcidDaleBewan
Unions in the United States needs massive reform. However no one is really wanting to admit it. When ever someone says to the Union "Dude, you have some major problems, you need to fix them!" they go back and spout all the good stuff they did in the past. Weekends, Overtime, Vacation....
The problem now the Unions main goal is to increase the size of the Union. So I have seen Unions agree to something similar to the following example
Lay Off 50% of the IT Staff (say 10 People at an average of $70k a year), and Expand Factory workers by 20 average $30k a year. To save $100k, for the company. But the Union ends up getting more money out of dues.
Also because the Unions are structured there is a deep dislike towards Outside Consultants and Contractors for temporary work. (For example the Auto Union hired workers to do nothing until there is a surge in work, so they sat around all day and watched TV except for a few time a month or year) Because they would get more unioned members vs. hiring contractors to pick up the extra slack when it is needed, but they are not paying union dues so they are not welcomed.
Union shops tend tries to make sure no one does anyone elses job. You request and get approved for a whiteboard. The board is shipped to you. If you hang it yourself your are in trouble, you will need to wait an other week to get a Unioned employee to take 5 minutes to hang it for you.
I once got in trouble from the union because I was consultant commissioned to create a Web Application for them. The commission came from the Application Development group, I did the work to the best of my abilities... Apparently it pissed off the Web Group because my application looked better then what they could do, and they demanded more tools so they can make their apps look better then mine...
There is also a fear amongst union members to bad mouth the union. When I was taking my MBA class, and the Unioned Professor trying to teach how to deal with collective bargaining, she would close the door and talk quietly. When I use to work as a consultant, I was told to avoid these people because they are big in the union, and if I did anything to make them look bad there will be a lot of trouble.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
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.
No it is more of a case that most companies don't need a team of rockstar developers.
Because in truth you don't. For an average medium large project
1 Rockstar Developer
3 Mid Level Developers
6 Jr. Developers
The Rockstar works on the proof of concepts, and the base architectural design.
Mid Level make the core building blocks
Jr. Developers put all the pieces together.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
Indeed, the article is not actually talking about "rock stars" but about poaching senior developers. It is also quite possibly the most perniciously agist thing I have ever read. "People do their best work when their head is barely above water," huh? How about the "truth" that the person who's "slogged through it 100 times before" also knows where the pitfalls are? The entire article reads like a bad stereotype of crotchety old developers too arrogant to follow directions.
I sometimes ask revealing, often ignorant-seeming questions. Maybe they're harder to answer than you think.
You are describing a cowboy coder, not a rock star. The two could not be further apart. Rock stars are the ones who, by definition, get shit done right. If they cannot write maintainable code, then they are not a rock star, plain and simple. Maintainability is almost always the number one most important quality of any project. Anybody can get v1 out quickly. A cowboy does it by cutting corners and rushing. A rock star does it fast and right, which is what makes them a rock star. If your good, solid, dependable devs can do that, you might have a couple rock stars without knowing it. Remember that skill and ego rarely match up. Joel Spolsky's definition of a rock star is still the best one IMHO: smart and gets things done.
This "rockstar" term is so fucking stupid and abused. If you have millions of end-users who know your name and what you did, THEN you can call yourself a rockstar programmer. It's mostly a public image thing too, rather than quality or quantity of code. Programmed some lame server-side java app in half the time it takes most people? Not rockstar.
The only rockstar programmers I can think of off the top of my head are John Carmack, Tim Sweeny, Brian Fargo, Warren Spector, Sid Meier, Peter Molyneux, John Romero (classic rock I suppose), and Cliff Bleszinski. All of these guys are games industry programmers that are high profile. When's the last time you saw publicity on generic corporate coder #81635?
You are describing a cowboy coder, not a rock star.
The problem is that management equates "gets stuff done fast" with "rock star", regardless of the unmaintainable mess they may leave behind.