Forgot your password?
typodupeerror
Businesses Programming

The Truth About Hiring "Rock Star" Developers 487

Posted by samzenpus
from the bang-for-your-buck dept.
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 discussion has been archived. No new comments can be posted.

The Truth About Hiring "Rock Star" Developers

Comments Filter:
  • Summarized (Score:4, Insightful)

    by war4peace (1628283) on Friday August 31, 2012 @04:38AM (#41187733)

    The whole article could be summarized like this: "We have no fucking clue how to manage rockstar developers".
    If management or MBAs don't click with devs, the project is ripe for crashing.

    • by Anonymous Coward on Friday August 31, 2012 @07:21AM (#41188551)

      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.

      • Except they/we are rockstars because they get the job done

        The problem with rockstar developers is they often write code that mere mortals cannot read or maintain.

        Sure, they can whip out version 1.0 or impressive enhancements quickly, but if it becomes a maintenance nightmare later, isn't the cost just being shifted from up front to later? Rockstar developers are often more trouble than they're worth.

        Good, solid, dependable non-rockstar developers are better, in my experience, because they're more likely to write code that their colleagues can actually maintain lat

        • by hackula (2596247) on Friday August 31, 2012 @10:01AM (#41190307)
          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.
          • The problem is that every cowboy coder insists that he is the rockstar, it's the others that are the cowboys.

            Mart

            • "The problem is that every cowboy coder insists that he is the rockstar, it's the others that are the cowboys."

              Yes, but again, almost by definition, it is generally not what he thinks that makes him a "rockstar". It's what others think.

              • by Matt.Battey (1741550) on Friday August 31, 2012 @01:42PM (#41193055)

                Couldn't agree with you more.

                Rock-star Engineers produce designs, implementations and tests that are easy to comprehend and extend. They don't produce Golden Code that will never be put in to use. Also they have a more than effective knowledge of the technology and the problem being solved. They are able to lead-by example, and true rock-stars are able to realize when they need to follow and/or team lead when they are are on a larger project.

          • by Teckla (630646) on Friday August 31, 2012 @11:20AM (#41191345)

            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.

          • by WaywardGeek (1480513) on Friday August 31, 2012 @11:22AM (#41191369) Journal

            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.

        • No. The problem with Rockstar developers is that the requirements are usually such that it requires Rockstars to get it done. Unreasonable time lines, unfinished specifications that require constant changes as it's being written, Psychic coding (I know I *said* I wanted this, but I meant that), Managerial changes mid-project in which the new manager changes everything.... etc..

          Insane measures are required to meet insane expectations, and that is ALWAYS managements fault.

      • 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.

        You need to consider that you are not actually a rockstar programmer. Specifications change is one of the basic fundamentals of software design, and if you're having trouble with it, then your code is not flexible enough. Start now figuring out how to make your code more flexible.

        You seem to be making the same mistake the article made, confusing rockstar developers with senior developers. You're not a rockstar, you just type fast.

    • Re:Summarized (Score:5, Insightful)

      by jellomizer (103300) on Friday August 31, 2012 @07:39AM (#41188679)

      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.

      • Re:Summarized (Score:5, Insightful)

        by darronb (217897) on Friday August 31, 2012 @09:18AM (#41189719)

        I strongly disagree in the concept that rockstars only design and don't code. Sure, lots of senior people I meet seem to think they've earned the right to just think all day on problems and let more junior people slog through actually coding anything. Many times you end up with (as Joel put it wonderfully) architecture astronauts that do much more harm than good. Many of the ones that avoid that particular trap just cost you a lot of money to work at a way lower productivity level than what they're capable of producing.

        Coders need to constantly code, or they start to drift off the reservation. They develop odd ideas of what software development should be (which can end up quite burdensome since they don't have to do a lot of it themselves), and chase down crazy edge cases as thought experiments.

        While the junior people need to learn somewhere, I'd much rather just work with just 'senior' level people personally. (That's generally a watered down ranking anyway, and certainly not rockstar level) Sorry, you guys deal with the rest. :) Any competent senior-ish level person can code faster than they can explain what to do to/clean up after junior developers. Even assuming a really well architected system broken up into easy blocks for the junior people to code (which doesn't happen in practice quite as often as/well as it should) just means that the easy blocks could be done in minutes by the more senior people.

        At the moment, at my largest client they've got one near-rockstar guy and myself. We get things done about 10 times faster than -competent- teams I've work with in the past. When the platform evolves to a point where it needs some refactoring, there's no whining and it gets done FAST. (it's R&D, the requirements change rapidly) It's awesome. I wish I could hire the guy.

        One of the weakest points of having more junior developers is handling signficant design shifts. On past teams we ended up avoiding or delaying making changes we needed to make because we were afraid of dealinng with the confusion from the juniors. The code ended up accumulating cruft to a much greater extent as a consequence.

        • Re:Summarized (Score:4, Interesting)

          by hackula (2596247) on Friday August 31, 2012 @10:15AM (#41190501)
          Sometimes having specialized people who do not code a whole lot is necessary. I work with a lot of Phd folks who can crank out some really powerful algorithms, but their code leaves... something to be desired. I do work in a pretty edge case kind of field though (geospatial analytics), that has a good bit more math than your average business dev work. Those devs do go off the reservation, but that is pretty much the nature of the work, and its better them than me. I am more than happy to interpret their algos and architect them into a maintainable solution. We also have worker bees who write reports and do basic data processing code. I live happily in between (my title is software architect (which I realize everyone thinks is bullshit, but I think it fits pretty well)), writing the most code, designing the "big picture" of the applications, and piecing everyone's work into one unified product. TLDR: Every type has a place, even the people who cannot grok the complex design patterns AND the people who are too smart for their own good and can be focused in on particular difficult-to-design modules.
      • Re:Summarized (Score:5, Insightful)

        by Anonymous Coward on Friday August 31, 2012 @10:02AM (#41190329)

        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?

  • Troll Article? (Score:4, Insightful)

    by Narcocide (102829) on Friday August 31, 2012 @04:41AM (#41187749) Homepage

    Article is weak on expertise.

    1) No, you don't need 10, idiot, you just need ONE, and about a dozen or so relatively obedeient and competent non-novice developers.

    2) Those weren't senior developers.

    • by ccguy (1116865)

      No, you don't need 10, idiot, you just need ONE, and about a dozen or so relatively obedeient and competent non-novice developers.

      Some rules:
      -The definition of 'rock star' is relative to the teams (both past and present). The rock star in one team can just be so-so in a different team.
      - If everyone in the team knows (even if they don't publicly acknowledge) who their best guy is, all other egos are easily kept under control. No one wants to be more of an asshole than the best guy.
      - By using both previous rules at the same time, the best thing you can do is find the brightest possible guy that is also humble. You might think this i

      • Bullshit. The definition of a "Rock Star" developer is that they have a history of producing hits. It's not relative.

        • Re:Troll Article? (Score:5, Insightful)

          by YttriumOxide (837412) <yttriumox@gmai l . com> on Friday August 31, 2012 @07:07AM (#41188445) Homepage Journal

          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.

          • Mind sharing when is the right time to use interfaces? I like hearing the wisdom of other programmers.
      • by JWW (79176)

        You are so right a humble rock star developer is worth their weight in gold (or at least silver). Also humble rock star developers can be some of the best mentors to junior programmers because the don't maintain any off putting alloofness.

        Humble rock star developers aren't fairy tales either, they do exist. Having them on your development team is a fantastic benefit.

    • Re:Troll Article? (Score:5, Insightful)

      by donscarletti (569232) on Friday August 31, 2012 @05:17AM (#41187911)
      Best to have a couple of elite guys to motivate each other, a bit of camaraderie and some healthy competition. A single fulcrum may get stressed, lonely or complacent. I like having someone that I must work hard to prove I am better than.
    • Troll Indeed (Score:3, Interesting)

      by Anonymous Coward

      ...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

    • Re:Troll Article? (Score:5, Insightful)

      by Xest (935314) on Friday August 31, 2012 @05:27AM (#41187951)

      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".

  • It's an art (Score:4, Informative)

    by TheCouchPotatoFamine (628797) on Friday August 31, 2012 @04:47AM (#41187783)

    it's the lack of a single, piercing intellect who is given the power to do their best. You need SINGLE intelligence to coordinate complex maneuvers, and many minds to search out the plain of solutions like hunters of old. Coding is actually quite holistic, occurring in natural stages. Maybe the problem isn't that there too many or too few people; a good software team should be inspirational, allowing the members to spend time for excellence, even if its not obvious (to you, the hiring boss).

    No surprise efficiency is an issue in some places; if one builds a "well oiled" machines for it's consistency of action, trouble us not about these tiny changes (in all honesty) that leave managers hoping humans can be better machines. The art you are looking for, and the people, aren't found where that idea lives.

  • Unmanageable (Score:5, Insightful)

    by Rosco P. Coltrane (209368) on Friday August 31, 2012 @04:48AM (#41187785)

    "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, and have an overinflated sense of ego. It's a high price to pay to exploit their expertise.

    At any rate, one diva per project, provided a good supervisor is found to manage them and the project is in early development, is okay and probably does bring added value. A team of them however is sure to bring chaos, as individual personalities will inevitably clash. And forget about getting these guys to work on products that are in the middle of their product lives.

    • by TheCouchPotatoFamine (628797) on Friday August 31, 2012 @04:59AM (#41187823)

      truly, it's as if we should choose people to work together who actually have a lttlle in common. In many contracts i held, we didn't even read each others resumes. How can you build a bridge of understanding with a person who "just wants to work" and defines that as having no spark or interest greater than what's for lunch? (or, what's for project - same thing) Talking, and sharing mistakes freely - coming to know each other so as to render help and criticism without fear of reprisal IS work. That's what "professional engagement" means - one are engaged! I consider myself an eccentric coder (oh i do so qualify), but my major gripe wasn''t some big lack of skill - it was lack of professionalism. If people expect treating each other like strangers on the subway will make a better workplace, and if the company only promotes lax, lazy, quiet, and completely unstimulating environment - well, i can understand the divas better then the people that fail to *care*.

    • Re:Unmanageable (Score:4, Insightful)

      by epyT-R (613989) on Friday August 31, 2012 @05:03AM (#41187845)

      "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, and have an overinflated sense of ego. It's a high price to pay to exploit their expertise.

      except of course when they do when they're told, and shit hits the fan because they were correct to begin with, and then they're blamed for the failure and canned. Who's the diva then? Your phrase 'doesn't work well with others' tells me all I need to know about the culture where you work. Process and consensus matter more than facts and the truth of a matter. This is a very poor environment for logical thinking of any kind, nevermind computer programming.

    • by ccguy (1116865) on Friday August 31, 2012 @05:11AM (#41187887) Homepage

      "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 :-)

      • "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 :-)

        No disrespect, but is this "we" that you are referring to? The fact is that there are divas in the software industry, and they are not necessarily among the best developers (even though they thing they are.) Once we get a diva in the team, it's just utter chaos. They are simply impossible to manage. They can bang code like no tomorrow alright. And they might be able to describe the state of a TCP session by heart. But that doesn't necessarily make them good developers. That's just savantism.

        As Dijkstra on

        • Re:Unmanageable (Score:5, Insightful)

          by locofungus (179280) on Friday August 31, 2012 @06:29AM (#41188217)

          A diva, OTH, is always right, in his mind that is, he is abrasive and nearly impossible to manage effectively.

          While this is probably true for some people, especially above average people who have only worked at small companies where they are the best developer with no real competition I think there's a second problem that can make good people appear like that:

          Sometimes we are asked to do something that is impossible. Not hard, not boring, not beyond our capabilities, but impossible.

          Mediocre developers will go off to start things when they are asked. Months later they'll hit the corner cases that make the project impossible to do and then will be completely flummoxed at which point one of the top developers will be called in to try to rescue the project.

          Where the top developers can be particularly weak is in trying to explain why a project "just won't work." It's surprisingly difficult to do in any moderately complex system. Often any single example that won't work has a simple solution. It's only when you consider many of the difficult cases together that you understand that the solutions are mutually inconsistent.

          One of the key things of the top people isn't just that they're good but that they don't (often) start along roads that won't work. Get two or three of them together, give them time to thrash out ideas (and them leaving work early on Friday to go for a pint might actually save your company hundreds of thousands in developer time when they realize there's a problem ahead) and you really can see a ten fold performance improvement in productivity. Not because more code is written but less is written and then thrown away.

          Maybe we're saying the same thing. But I have seen few true divas while you imply they're common. Many able programmers are not perhaps as socially functional as managers might prefer but that is, unfortunately, going to be a consequence of hiring people who are doing a job that needs excessive amounts of pedantry to get right.

          Tim.

      • by Chrisq (894406) on Friday August 31, 2012 @06:06AM (#41188135)

        "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".

    • Re:Unmanageable (Score:5, Insightful)

      by Xest (935314) on Friday August 31, 2012 @05:39AM (#41187997)

      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.

      • by bjourne (1034822)

        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.

        I dont think the parent is talking about the same kind of "ego" as you. Unfortunately, it is not only the arrogant jerks that are seen as having an "overinflated sense of ego," even the most humble developer can have that accusation thrown at him or her in the wrong environment. You may be very good at something, you may also be aware of it and that most of your peers aren't as good at it. That's all it takes to have an overinflated ego because people will sense that you know it and will feel inferior. Does

    • by Carewolf (581105)

      "Rock stars" - we called them divas in my company - are notoriously unmanageable: many of them are temperamental, don't work well with others,

      If rock stars programmers work with genuine peers, the diva part of them will be suppressed. It is hard to feel superior when working with people against whom you are just average. Some of them can still lack in social skills(*), but you can often minimize the damages that could cause. Of course as a company you still need to be able to afford top talent and have a pr

  • by Hazel Bergeron (2015538) on Friday August 31, 2012 @04:49AM (#41187787) Journal

    No-one who identifies himself as a rockstar developer is a rockstar developer, and no good developer would call himself a rockstar. The only thing certain is that in any article about "rockstar developers", a few dozen people will wander in and complain that the only reason the world isn't perfect is because rockstars like them just aren't looked after well enough.

    So, for all of you thinking about making this claim: if you're so fucking great, go out and start your own business and rewrite every single software product in your own image. Be the rockstar you think you are, identify everyone's desires, and out-compete every other firm on the planet. Internet capitalism is more meritocratic than most forms of capitalism - if you write a killer operating system or office suite or CRM system or time&billing app or whatever, people will take notice. So team up with as many people as your ego will allow (you're a rockstar so you already have considerable savings) and go get 'em, tiger!

    • by jcr (53032) <jcrNO@SPAMmac.com> on Friday August 31, 2012 @05:01AM (#41187831) Journal

      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

    • by Migala77 (1179151)

      No-one who identifies himself as a rockstar developer is a rockstar developer, and no good developer would call himself a rockstar.

      You are not a rockstar (developer or otherwise) unless you have the groupies to prove it.

  • 'Cause we all just wanna be big rockstars
    And live in hilltop houses, drivin' fifteen cars
    The girls come easy and the drugs come cheap
    We'll all stay skinny 'cause we just won't eat

    And we'll hang out in the coolest bars
    In the VIP with the movie stars
    Every good gold digger's gonna wind up there
    Every Playboy bunny with her bleach blond hair

    And well, hey, hey, I wanna be a Rockstar
    Hey, hey, I wanna be a Rockstar!
  • by HizookRobotics (1722346) on Friday August 31, 2012 @05:16AM (#41187907) Homepage
    Description starts by talking about rockstar developers, then makes assertions about senior developers. These two groups are not even close to equivalent. Seniority (generally) implies experience -- not "rockstar" status.
  • by gweihir (88907) on Friday August 31, 2012 @05:23AM (#41187935)

    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.
     

  • Lay back, shut up, and let Angus pound you back into shape <screeching guitar riff>

  • by CaptainOfSpray (1229754) on Friday August 31, 2012 @05:39AM (#41188003)
    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.
    • by pnot (96038) on Friday August 31, 2012 @07:00AM (#41188411)

      Code written during the normal working day, with constant interruptions, will never soar like that.

      About half an hour before reading your post, I suddenly realized that Monday is Labor Day. My first thought was "fuck yeah, no office-mate, no visitors, finally I'll get some real work done".

    • I am a Mechanical Engineer but I also have a CS degree. It was interesting in school to see how software engineering being a relatively new field is struggling with what other engineering fields have had to deal with for a long time.

      Staffing a project is not a linear function. A project with twice the complexity doesn't take twice as many people. It may take 4 times as many because now you have to coordinate those people. This requires project managers and system engineers. This begs the question what is th

  • by gnasher719 (869701) on Friday August 31, 2012 @05:40AM (#41188005)
    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.
  • The problem with "Rock Star" developers is, that they might lose focus when the job they're doing is too simple for them. They may like to code on your internet-enabled office-style application for a while, but in the end they long for more interesting, worthwhile and complicated matters that are on the edge of scientific discovery.

    So eventually you'll lose them, and you're stuck with the code that they left.

  • by Qbertino (265505) on Friday August 31, 2012 @06:01AM (#41188117)

    There's quite a bit of truth to the article allthough I'd say that true rockstar programmers do use the right tool for the job. If a programmer builds a custom Java CMS where Joomla would do, he isn't a rockstar. He's an idiot.

    Then again, the best programmer in the world is worth nothing without the environment or the right people around him. That includes higher ups that keep people off his back, maintainers that can handle the pipeline and clear objectives to work against.

    If a rockstar doesn't have those, he'll be faster than others in producing workable stuff, but if he gets hit by a bus it will be just as much worth as the other unfinished stuff.

    Many programmers I know hat are considered rockstars are quite mediocre. They only were at the right place at the righ time and didn't have any scruples in building a complex key product only they could understand, without docs, concept comments or usecases, as a means of job security.

    My last teamlead was a nice guy and a demigod in Perl, but absolutely incapable of any sort of productive or result oriented teamwork-organisation or inter-team communication. In itself not very rockstarish, allthough people did think of him that way when he saved the day on some billing system or something every once in a while.

    Bottom line:
    Rockstar is always relative. Very relative.

  • Existing teams where everyone has know each other and worked together for a long time have their own functional relationships, but for new teams you kinda need a hierarchy.

    I don't think this matters if its a team of developers putting together an inside sales support system or a team of carpenters putting up a barn. You simply can't have a team of all equals because if you do everything becomes a debate and no actual work gets done. Or even worse everyone needs to shine and get some recognition outside th

  • by blahplusplus (757119) on Friday August 31, 2012 @06:02AM (#41188123)

    ... is not rockstar developers it's that making and understanding how software will perform and it's impacts is a hard problem. It's not like engineering where the laws of nature are relatively fixed and known and is a matter of trade offs (time vs cost), ANY change to a program has potential impacts and ripple effects on all other subsystems effectively changing program behavior to some extent. The real issue is the tools for software development and making these things understandable in complex systems is a hard problem. It's a matter of framing problems and solutions in ways that you can actually understand their impacts. Too much software development is undefined and uncharted because of the nature of coding itself. There is a lot of research going on in visualization trying to make these ethereal systems of code easy to grasp and understand in ways that are much easier and more natural for our senses as human beings.

    http://www.allosphere.ucsb.edu/ [ucsb.edu]

    It's a matter of being able to grasp what is that you are trying to do and it's impact. Most developers (even rockstars) have issues with not even knowing where they are headed and what will be needed down the line as projects grow and outstrip human ability to understand them. Software has long since passed the complexity where the human mind has the ability to full grasp all the complex interactions. The real problem now is getting the research and data to make demystify this complexity (i.e. complexity partially being a synonym for not being able to see/understand what a problem and solutions are and it's impacts).

  • How about hiring COMPETENT developers to begin with? the companies that have those problems have the fault lie with the management. managers that cant actually manage, pay scale for the actual developers is too low, budget for the department or project is too low, and the upper management focus is not on quality, but on profitability.

    Yeah, let's lay blame on the guys that are actually doing the work. In reality, every failed project has the person managing it to firmly blame for it's failure.

  • Rock Stars make great performances not great software.

    Ego has little place in software development and in most cases those that consider themselves 'Rock Star Programmers' are suffering from a chronic case of Dunning Kruger syndrome

    Great Programmers are masters at listening and comprehension. They are humble, asking questions before offering solutions. They not only accept criticism they solicit it. Their code is simple and elegant, capable of being comprehended by the most junior and appreciated by experts.

  • by Greyfox (87712) on Friday August 31, 2012 @08:17AM (#41188997) Homepage Journal
    They didn't have the budget for unit tests, realistic deadlines or an architect. They probably adopted "Agile" and had the project manager set all the deadlines, using the process mostly as a method of flogging the developers. And they probably never had clear requirements. You don't need rockstar developers to insure a project success. You don't even need rockstar managers. You just have to put some thought into the project, and that, sadly, is what's lacking in most of these badly-executed software projects.
  • by SecurityGuy (217807) on Friday August 31, 2012 @08:35AM (#41189223)

    If you're not a rock star manager, you vastly overrate your ability to identify, attract, hire, and retain rockstar developers. You're far more likely to hire people who have massive egos who don't realize their own faults, and who can succeed in pulling the wool over your eyes because you don't know any better.

  • by cfulton (543949) on Friday August 31, 2012 @09:46AM (#41190113)
    The best outcome of a project I have ever been a part of was during a project for an unnamed automobile manufacturers website. The project was far behind when we came on and the original development group was let go. :-) We put together a group of a few "Rock Star" developers together with a group of experienced developers that we knew form previous projects would take direction and understood design. It was only because of the urgency of the project and the potential profit that management allowed us to form this group. We placed them in what we used to call the prison. They were not allowed contact with the rest of the project team (Business, Graphic Arts, PMs etc). I had short standup meeting with them every morning. Then the "Rock Stars" rocked away. They implemented an elegant, workable, well executed design. There were 12 of them when normally we would have used more like 25 or 30.

    My point being they were real "Rock Stars". They could design and code. They were not above doing the actual work. The idea that there are only two kinds of developers: ivory tower academics who know UML and Patterns but can't code, and spaghetti coders who hack through crap but get it done, is the real problem. We hire everybody who can understand an if then statement as a developer these days. What needs to happen in the development business is that hiring managers need to learn that developers are not all equal and resumes can lie.

Work without a vision is slavery, Vision without work is a pipe dream, But vision with work is the hope of the world.

Working...