Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Programming IT Technology

How To Deal With (Techie) Prima Donnas 425

budcub writes "IT Recruitermag has a informative column, on How to deal with Prima Donna programmers from a management point of view." Put on the asebestos -- but I will say that a number of people that I've worked with, or talked to, have complained about working with people like this before.
This discussion has been archived. No new comments can be posted.

How To Deal With (Techie) Prima Donnas

Comments Filter:
  • by Anonymous Coward
    Or get him a date. If he spends that much time with a computer to be that good, he hasn't discovered the virtues of sex with other people. That'll kill his free time.
  • by Anonymous Coward
    You know the ones. The techno wannabees. The ones who know just enough to think they know it all. These are often contract people, beta testers, accounting ilk, tech support bozos, or just whoever happens to be in the office next to the programmers office. They like to spew jargon and think they are big shots, connected to all levels of company operations.

    "Yeah man we gotta ODBC the user database from the SQL server into the IIS machine's Java applet to ramp up the TPS and get it all into the Excel template for the reports for the CIO I tell you whut."

    Then they just look at the programmers like they're all supposed to jump and start implementing all this shit.

    I wanna say "Fuck you VB script kiddie punk. I've been keeping the machines running here for 10 years. You'll be gone within one. And you're telling us how everything should be rewritten and run?"

    But I'm mellow now. As a veteran, I've found that simply ignoring these people works best; tossing out a randomly directed "yeah, sure", if pressed. Whatever get these people to quit bugging you and go bother someone else.

    God, I hate them.

  • You asked. I answered. I like coding, but like documenting too. Heck, had a higher GPA in writing classes than I had in CS classes.

    -E

  • It doesn't mean you're stupid, it just means you're stupid about this.

    I disagree. "Lame", to me, means one step beyond ignorance - it definitely implies ignorance combined with an arrogant belief that you are not ignorant.

    i.e., in the demoscene - you write a demo with a single spinning cube and scrolltext. OK, you're a beginner. You write a demo with a single spinning cube and scrolltext saying what a godlike coder you are. OK, you're fucking lame !!

  • But mediocre programmers are already useless. Unless maybe you are shooting for a mediocre program.

    Assholes, territorialism, and egoism are all drags. But so is mediocrity. At least an asshole might also be a good programmer. The mediocre programmer might be a good mascot, but not a whole lot else.

    Unless, god bless you, you are actually willing to invest in an individual so they can become a good programmer. There aren't many willing to do that these days.

  • >If I am looking for a unix development position,
    >why is it necessary that I pad my resume with
    >crap like "knows how to work Microsoft Office"?
    >Or list every single operating system I have
    >ever used? (I suppose then I'm being misleading
    >when I leave out cpm, z, tandy-dos or my
    >extensive experience with Pet Basic?)


    It felt odd the first time I started deleting things from my resume. But once I reached around 7 languages there, a) it was overkill, and b) I was forgetting to include some of them :)


    on top of that, these days, the details of my technical backround just aren't important to those likely to hire me. Noone even *cares* which languages a computational economist knows if he can read c and fortran, and is proficiet in Unix. For that matter, very few on the committee would understand the details . . .


    hawk

  • Good.

    YOU go fucking take the customer calls then. I'll give them your extension, 'k?

    Have some respect for tech support guys. If they're clueless about the product you coded, it's because you didn't fucking document it properly. Or can't put the effort into communicating information with another human being. How the fuck are they supposed to troubleshoot a black box? Get out of your ivory tower and answer the phone.
  • Its one thing to present something "new" to the competitive-programming community, but another to present something that's already been solved. If an 8-bit 6502 with 16 _K_ of memory could run a z3 machine and the degree of AI that the early Infocom games provided (on a single floppy, double-sided @ 720 K total space used), then a 32bit cell phone with a meg (much less the 16+ meg that are coming out in palms nowadays and even THAT's considered small by what _should_ be out there) could easily manage a z5-z6 inform-compiled game.

    There's already several great languages for "reaction and daemon" based AI "characters" and no contest is gonna come up with something better than the systems that are out there 'cause they evolved over 10+ years to get to where they are.
    --
    You know, you gotta get up real early if you want to get outta bed... (Groucho Marx)

  • There is an interesting contrast to be made here. There's obviously a problem with the sort of prima donna who has actively destructive habits. E.g. acts in an unprofessional manner towards coworkers, doesn't follow "egoless" programming practices, or is otherwise immature in the workplace -- that boatload of alleged talent notwithstanding.

    On the other hand, there are those who happen to be good programmers, but who are really hard-core computer scientists and/or software engineers. In such cases management fails utterly to understand why they work and act differently than the rest of the rank and file programmers. In days of yore, they might have achived the word "Analyst" somewhere in their title, but distinctions other than "Senior" and "Principal" seem passe these days. The basic nature of such an individual's contributions to a project are often far, far different than the rank 'n file... but both are seen as "programmers". So the question is: how to effectively educate management and set expectations under such circumstances to avoid an unwarranted "prima donna" tag due to miscommunication about the nature of one's work?

  • Yeah, but it's the prima donnas that ignore the coding standards. "The way I write it is more readable". They're also the ones most likely to have "highly optimized" (read: unmaintainable) code.
  • Bruce Perens, Linus Torvalds, Bill Joy and Alan Cox could probably code in one weekend what it would take a team of coders a week to do, yet they at best are not even making twice what an intern at a Fortuen 500 makes. Then to add insult to injury the overpaid MBAs who have wrecked the tech industry now have the nerve to call them Primma Donnas.

    Each of these people are great programmers, but more important to thier success, they are good managers (and its unfair to call them primma donnas!). After a project grows beyond a one person some form of communication must be established, and some chain of command must be established. Someone in the team has to take the responsiblity for managing whats going to go in, whats going to go out and so on. Someone has to direct the effort, and keep it on track. A lot of that work are things that most programmers don't want to do.

    In short if you want a successful product (and linux is a product) you need to:

    • 1. Identify your goal.
    • 2. Identify the most cost effective way of achieving it (wrt time, money, etc).
    • 3. Execute according to this plan.
    • 4. Adjust your plan and execution to compensate for changes in the conditions on the ground to get to your goal.
    The manager is responsible for keeping all this going.

    I will trade a primma donna for a solid engineer anyday. My experice is that a primma donna does not have the where-with-all to go through this process. They are bored or frustrated by steps that you have to take to communicate, and to ensure quality in a production system. So you can keep 'em.

    --locust

  • I have often read comments lamenting the effort required to read other's code. While I can understand that logically, two people can put together two different programs to serve the same purpose - but come on. Syntax? Capitilazations? This is what coding standards are for, and any good _team_ will have a well-defined standard for things like that precisely for this reason.
  • Sure, 1 woman can ummm, show 8 other women how to make a baby, and in the
    end, you might end up with 1 baby in 9 months, and 8 in 10 - but if the project
    is 1 - WTF does it help to have all the baby versions? :)

    Managers love saying "team player", but in some cases, it takes individuals. It
    takes different people playing different rolls to get jobs done, you can't have
    3 leads on a small project. - It just makes things messy.
  • that wasn't a prima donna... they'd *never* be caught dead uttering that phrase.
  • BTW: On a similar parallel watch how many headlines talk about the tech crash, usually coupled with the collapse of the tech job market. Yet the reality is that overwhelmingly the crash has laid off low to mid level managers, HR, accountants, paper pushers, etc. IT workers are by far the least affected, yet they get the hugest majority of the attention. As another post mentioned: It's a desperate attempt to make programmers feel vulnerable.

  • What makes a good programmer a Prima Donna is he knows he's good.

    What makes a bad programmer a Prima Donna is he thinks he's good.

    The problem for management is figuring out which is which, keeping and nurturing the first case, and getting rid of the second case (or not allowing it to be there to begin with).

  • Is it just me, or is the idea that there's a tiny cigar chomping woman grinning evily and roming among the towering capacitors of my motherboard, possibly wreaking havoc MORE THAN A LITTLE CHILLING! WHAT THE HELL IS UP WITH THE GRAPHIC ON TOP OF THAT STORY???
  • An excellent example!!! This exactly what happened to me when I was in my mid-20's. I helped developed the test systems that are used to ground test the space shuttle's robotic manipulator systems. I was a hotshot, nominated for engineer of the year at Spar and walked on water, but was paired up with a "Senior Staff Engineer" who was twice my age and so far up the engineering totem pole that you need binoculars to see him otherwise. He was BRILLANT, a Soviet national mathematics champion as a child, a Ph.D later, who excaped the system and went to Israel and finally to Canada where he worked as an Lead Aerospace Engineer and Space systems designer.

    It was the best thing that could every have happened to me. He could reel me in on a snap and kept me focused on the tasks at hand, explained the politics surrounding what was going on, spend hours discussing design and ultimately let "do my thing" but provided the insight to understand not just what needed to be done, but the whys, wherefores and hows that went within the decision making process. I learned to recognise that building complex systems is never a one person task, that regardless of how good you are there will always be one person better and it is even more fun to "really" work with others then being a lone wolf.

    I will always look back to that time with great admiration and respect for that man, not for the lessons found in Scientific and Engineering R+D but on how to be a good team member and more importantly, how to be a more compassionate and decent person. In other words, he helped me to grow, taught me what it means to act as a professional -- and for that I will always be grateful.
  • ..and you're instantly called a "prima donna" if you aren't a team player, which means "agree with us even if we're wrong."

    Just do what all managers do: sacrifice the quality of the project in the interests of the personality contest. Nobody cares if the work gets done, just as long as everyone agrees.

    I don't care if someone wants to be a prima donna as long as the work gets done. Most managers, OTOH, are far more interested in consensus than leadership, which is, in turn, why the dot-coms couldn't ship anything.

  • I have to agree with what you've said. I've met a few managers that were worse than the worst prima donna programmer I've ever met. What makes them worse is that they usually have power to go with their ego, and can enforce their problems on other people.

    I would also add to what you've said that I think most of those like your description weren't that great at programming to start with, and that may be one of the reasons they were drawn to management. I can't imagine a "true" techie wanting to be away from the fun stuff.

  • I know you're speaking from experience, but stop generalizing, eh?

    I know it sounded that way, I'm sorry. I can only really speak about those I've known, and that's all I did. I fully concur that it's not restricted to younger programmers, and certainly not just programmers. I didn't mean to generalize, and I apologize for writing it that way.

    Speaking of the guy that wrote the Linux book -- do we know each other? I also know a late-20s early-30s guy that wrote a Linux book and was a horror to be around after that. I also know several younger programmers that are constantly overlooked because of their age when they're far more talented than many of their co-workers.

  • Learn from Them

    You're right, I did leave that out. The type of person I was describing typically isn't good enough to teach anyone anything, though. As several other replies pointed out, I wasn't clear that I was referring to the "Think They Know It All&quot type rather than a truly competent individual.

    Let me clear this up -- I'm not a manager, and have turned down management positions because I think it would be miserable, and I really like the programming. I don't mean that the assholes should be told what to do -- usually a real challenge or partnering them with someone they can also learn from is good not only for them, but those around them... i.e. the experienced person they're paired with can also learn.

  • Are you sure you're not my boss? Sounds like you're describing me :)

  • Get them to program in pairs.

    I think I did suggest that, but with a more experienced programmer. I think your way would work at least as well, as long as they're not paired with someone they could bully, or someone that's very submissive. I think the prima donna would insult their partner to everyone, and claim he was doing all the work. That's the one fear I'd have about pairing them with a peer. It might make the prima donna worse, and make their co-worker angry or bitter, or even worse -- scared to code anything.

  • In this case, though, as other people have said, age does NOT correlate to one's workplace attitude. Older programmers sometimes have a "I'm more important because I've worked longer" mentality that pollutes their interactions with younger co-workers.

    Hallelujah, brother. I've met plenty of those too. Interestingly, I think the cause is often the same -- they're scared of what others know. And another comment sure to get me in trouble -- government workers seem to be the worst offenders at the "seniority makes me special" game.

    The best solution is to prevent people from being prima donnas in the first place because it's a hard thing to convince someone with an oversize ego that something is wrong with them.

    I agree with this, and though my suggestions might have sounded mean or hateful, I didn't intend them that way. I'd like to see the prima donnas, especially those that are truly gifted, become even better at what they do. My suggestions were mostly oriented not at punishment, but at improving whatever it is about them that makes them difficult to work with. I don't want them to go away -- I want them to be nice :) .

  • Interestingly enough, I've seen corporate environments where the arrogant idiot in marketing gets much further ahead the the arrogant genious in development.

    Doesn't that piss you off? The company sees their "value" directly because they can point to direct dollars they've supposedly created. A lot of companies forget the marketing guy is selling the work of the engineers... and we're back to the old argument of "without engineers, there's no product to sell" vs. "without marketing, there's no one to sell the product." The other thing that pisses me off -- who gets laid off first? The programmers! You know when you see a company maintaining their marketing people and decreasing their numbers of engineers that they're headed for fuckedcompany.com.

  • And we get back to the issue of how to give programmers job performance ratings. It's a never-ending argument. Unfortunately, the LOC standard is often used, next the reuse standard... hardly ever on the functionality/genius of the code. Hell, I'd love to work in a comments-to-code factor too :)
  • I like this idea, but wouldn't want to see it used exclusively... I'e also seen shops where there was only one competent person and everyone hated them him even though he wasn't a prima donna, and was actually nice. Sometimes, the reverse of what this whole article was about is true, and you've got an office full of prima donnas and one decent person :). I'd hate to see that person screwed because of everyone else's short-sightedness.
  • I've had a couple folks write for details on the book, and it turns out I had the title wrong. If any of you are looking for the book, it's
    Dealing With People You Can't Stand
    by Dr. Rick Brinkman and Dr. Rick Kirschner
    ISBN 0-07-007838-6.
  • <blush>

    What bothers me most about working anywhere at any job is really how people treat one another. Rather than helping one another, they attack and plot against one another. It doesn't advance the species, ya know? But I guess that'll get me pegged as a liberal Star Trek fan :)

  • But Bruce, Linus, Bill, and Alan are going to heaven ... isn't that worth a 1000% cut in pay? Mmm... maybe not.
  • Everyone Is Replacable


    Also known is certain circles as "the Showgirls Principle".

  • One of myh favorites:

    //trust me, it works

    ----------------------------------------------
  • My boss rules...in addition to the 6 month reviews that are standard in the company, he does 2 additional very informal reviews, part of which is a list of suggestions for improvements to make before the next official review. These can be very straightforward and simple things (one time I got "Don't wear sneakers to customer sites") to more important things, like proper communication or a change in focus (once I was told to spend more time working on preventitive maintenance so we had less crisis situations with the servers and networks). And, of course, like a good manager, he starts with the compliments and gradually moves into the suggestions. In past jobs, I usually thought of individual meetings with the boss as either a complete waste of time or an indication that I was about to get yelled at. I feel a lot better with a boss who actually acts human.

  • The nature of a business is to complete the tasks at hand. If an employee doesn't consider his paycheck as incentive enough to do the job properly (which includes things like documentation and proper communication with the rest of the group), then the employee should try to find a different job. The "interest" of the employee in the job material doesn't need to be anywhere near the top of the list of employer priorities.

    A while back, I tended to act in some of the ways detailed in the article, though maybe not quite so severe. I noticed that I was often withdrawn from coworkers, and tasks that required me to interact with others became increasingly frustrating. So, I started documenting a lot of the more obscure tasks. I started keeping people informed on the status of projects that touched their tasks. Now, I tend to be more on the same page with my coworkers. We get a lot more work done with less conflicts and problems.

    Yes, there are bad managers, and sometimes it's hard to get rid of them. If you can't get rid of them, and you're really that damn good, then you should be able to get another job without too much trouble.

  • Real ass niggaz don't flex nuts
    'Cuz real-ass niggaz know they got 'em
    -Geto Boyz, "Damn It Feels Good to Be a Gangsta"

    -jhp

  • by Eric Green ( 627 ) on Tuesday July 10, 2001 @05:42PM (#93302) Homepage
    I once had the displeasure of working with an arrogant jerk. We (the two senior-most programmers in the company) asked him to write a class for accessing our database. We told him the API we wanted, and gave him sample code that accessed the database. He argued that we didn't need that class, and that his way (sprinkle database code all throughout the program) was better. We agreed that our class was overkill, but noted that it would improve future maintainability of the code and we wanted this code to have legs. He refused to listen. Finally we had to pull rank on him to get him to do his job. First and last time I have ever had to do that. After the VP of Engineering pulled him into a meeting and gave him a lecture about teamwork, compromise, and cooperation, he drove to the central office and turned in his resignation because we "didn't respect him".

    Fact: It doesn't matter whether the reason work isn't done is because he's incompetent, or because he's a prima donna. Either way, the work ain't done.

    Note that I am *NOT* talking about confident programmers who are simply not shy about sharing their knowledge. I've been accused of that myself in the past :-). Rather, I'm talking about "legends in their own mind" who, in reality, are legendary only in their ability to make excuses as to why he isn't going to implement the solution that the rest of the team has agreed upon.

    -E

  • by iabervon ( 1971 ) on Tuesday July 10, 2001 @05:15PM (#93303) Homepage Journal
    Linus used to code like that, but he's got better things to do. What makes him a really great programmer is that even more work on Linux gets done in a weekend now than when he did; a great programmer increases the productivity of everyone on the team by providing good examples of code to emulate, and by providing well-written, reusable code.

    If one member of a team is 10 times as productive as another, then either the unproductive one isn't any good or the productive one isn't writing good clear code. This means that the code will probably have to be thrown out if the team changes. It also means that the prima donna is being unproductive overall, since they're wasting their coworkers' time. If the best programmer on a team can improve the code base such that the other members' code is easier to write, they can save themselves the trouble of writing the easy stuff. If the guru is only 4 times as productive as a normal member, but the other 8 people are twice as productive as they would otherwise be, the team gets more done overall.

    Being 10 times as productive as an average person is a good reason to work alone. Which is, in fact, what Linus did initially when he was churning out tons of code.
  • by Toast ( 3221 ) on Tuesday July 10, 2001 @02:03PM (#93304) Homepage
    That puppy went down faster than usual.
  • by ergo98 ( 9391 ) on Tuesday July 10, 2001 @06:52PM (#93305) Homepage Journal

    Because most organizations have come to depend on their programmers to such a degree that they despise them. I had been cast as a prima donna at a previous place of work, and it was hilarious seeing the lengths that people would go to to try to prove this point: They would claim that I was hoarding code until I pointed out that they had full access to the source control and were welcome to look at it. Then they'd claim that I wouldn't explain it to them at which point I'd offer a meeting to go over the code. Then they'd claim that I was hiding some piece of information or other, at which point I'd direct them to deja, show them my sources, etc. All of it was absolutely useless because they were desperate to prove that I was a "prima donna" because how else could they explain my abilities? I had managers seriously believing that I was hoarding some secret stash of information because I could easily solve problems that others pondered over for weeks. There is a great irony in being despised for being a great asset to a company. I had managers constantly pathetically trying to drop hints that there are loads of great programmers out there, etc. (like this article says regarding trying to make your programmers feel replacable), which was laughable because I really wasn't demanding a lot of pay and was actually a very dependable employee, however their dependance on me led them to shine the spotlight on me ultra-bright, and they tried everything to psychologically control me.

    There is another sort of prima donna that I would never stand up for, and that is the reverse prima donna that uses arrogance and elitism to pretend to have knowledge that they don't. At the same place I worked with a VB wanker who didn't have the slightest ounce of understanding of good code design, and any new technology would take him weeks to grasp remotely. He would attempt to look down his nose from high to his coworkers, hoping and praying that they would buy that he was 31337, when instead he was below average.

  • by Mike Buddha ( 10734 ) on Tuesday July 10, 2001 @02:12PM (#93306)
    It figures, the link's to an asp. I'm guessing IIS.
  • by Katravax ( 21568 ) on Tuesday July 10, 2001 @03:04PM (#93307)

    Sounds like the Prima Donna is an exceptionally talented programmer, and not, as you say, a one-trick pony. Ego problems aren't confined to young people, you know. But maybe I should just shut up and let the older, wiser and bitter speak.

    Can't let those young 'uns get all uppity now!

    I'm annoyed you got modded down. You made a good point, and I hope someone else can mod you back up. I was speaking strictly from my own experience and not trying to rehash what the article was calling prima donna. If a person is as the description you quoted, they're clearly not a beginner :). I'd like to point out that the article was written from the point of view of a recruiter/manager... those typically the worst at identifying whether a programmer is smart or talented. They frequently mistake ego for intelligence.

    I'm not an old person myself. I'm also young by most standards (I'm 33, and have only been a professional programmer for 11 years). I consider myself a good middle-of-the-line programmer in terms of experience, neither a beginner nor a seasoned pro. I guess what I meant to describe was what the book calls not a Know-It-All, but a Think-They-Know-It-All.

    As for the young'uns getting uppity, some of the most outstanding programmers I've met were beginners. I guess it was the attitude of the assholes (young and old) I dislike, and made it seem like I meant all young programmers. I apologize for that. But in my experience, all prima donnas that don't have the right to be because they're not that good were young. I'm sorry I sounded like I meant all young programmers.

  • by Katravax ( 21568 ) on Tuesday July 10, 2001 @03:13PM (#93308)

    Right on. There's a book called, I think, How to deal with difficult people and it described exactly those two personalities. The Category 1 you described was called the "Know It All" and the Category 2 was the "Think They Know It All". I agree with you that the Category 1 is at least redeeming in what they can bring to a project, but the Category 2 folks should be helped out of their situation (at the very least). I've found most of the Category 2 types are like what I've described: They've always been the big fish, but they were in very small ponds before. The most common type is the one that's gaining decent skill at one thing, but doesn't yet know enough to understand how tiny a fraction of the real IT world that one thing is... They think they know it all. The type I was describing was the Category 2, and I wasn't clear about that.

  • by a.out ( 31606 ) on Tuesday July 10, 2001 @03:22PM (#93309)
    Once everyone realizes that I'm always right, the world will be a much better place.
  • by Platinum Dragon ( 34829 ) on Tuesday July 10, 2001 @04:26PM (#93310) Journal
    Argh, find me /any/ programmer that has the capacity to document their work! Something other than

    // increment i
    i++;

    and then have no comments when they use some complicated algorithm!


    How about:

    /* You are not expected to understand this. */

  • by CharlieG ( 34950 ) on Wednesday July 11, 2001 @12:35AM (#93311) Homepage
    Twas in briefs
  • by brianvan ( 42539 ) on Tuesday July 10, 2001 @02:59PM (#93312)
    I agree that there's a tendency for recent college grads to be prima donnas. Typically, such people are prima donnas themselves.

    I just graduated, but I (humbly) do not consider myself a prima donna. I don't assume I know everything, I don't challenge direct orders (I'm not afraid to give feedback, though), and I enjoy working with other people. I also DON'T have a lot of experience or knowledge, but that doesn't mean I'm useless. My main professional goal right now is to learn as much as possible and contribute in any way possible to a real work environment.

    In this case, though, as other people have said, age does NOT correlate to one's workplace attitude. Older programmers sometimes have a "I'm more important because I've worked longer" mentality that pollutes their interactions with younger co-workers. Sometimes they don't have this attitude, but it's an easy trap to fall into. Also, being a prima donna isn't something you grow out of unless you have an awakening - you can stay a prima donna forever if you choose to.

    I don't take offense to the suggestion that younger people are prima donnas - because they are - but then again, older people can be too. I think that it's a problem with gifted people in general, and it affects various professional fields and areas of study. So this is basically history repeating itself with computers. The best solution is to prevent people from being prima donnas in the first place because it's a hard thing to convince someone with an oversize ego that something is wrong with them. But prevention is unlikely, seeing how even the dirtiest crackwhores and muscle thugs can also think that the world revolves around them as well...
  • by eric17 ( 53263 ) on Tuesday July 10, 2001 @10:45PM (#93313)
    OK. You have found that you can out-code most or all of the people around you. But years have gone by and you are still making pretty much what everyone else is. Do you a) admit defeat as MikeySquid did b) become despondent and read slashdot all day, or c) become an asshole that everyone wants to get rid of?

    No, you are in the unique position to create your own temporary automous zone (TAZ) right there in your little own cubicle. Yep, right there. Read on....

    1. Don't put in extra time on office work. But more importantly, don't become a slacker in dispair or a disruptive pain. Realize that if the structure of a company rewards extra or better work with the same salary, then don't do any more than you need to _for the company_.

    This may strike you as dishonest at first, but if the company is paying you for an average amount of productivity, and will not pay for exceptional work, then by all means give them what they pay for. An honest trade. Do your best work for two hours a day (or whatever it takes), and then spend the rest developing your skills. You will need them when you finally find someone willing to pay what you are worth, start contracting, or start your own thing.

    Examples: Develop some open source code on company time. Read about algorithms and design. Spend extra time optimizing the code you wrote for the company (even if they couldn't care less). But, if by some miracle you get an assignment that is actually interesting, look at it as an opportunity to show what you can do. Not to management, but to yourself. Pull the throttle out, rev the engine, see what you can do.

    2. Be respectful to your coworkers, but don't buy into the idea that the company is in any way your family or tribe. Accepting this fact will keep you from getting frustrated by the situation. You don't need to make the company brass look good, and you can be sure that they don't give a damn about you. They are stupid enough to treat all the engineers the same, so give them what they deserve.

    3. Don't worry about how you stand with the company. It does not matter. They are a stepping stone, one much like the other, until you find or create the one that is enlightened. You are not what they are looking for anyway. If you conformed to their ideals you would be killing your soul slowly. But don't give them any reason to think you are anything but another cog. They are idiots, but they have no need to know. Don't argue with the idiocy, and don't stop doing enough work to look productive.

    4. Forget about playing the game, unless money is primary to you. You starting this stuff because it was fun--intellectually challenging. If so, you will not find politics fun. Money may come to you or it may not. The height of the stack of dollars that flow when you are compensated at full value will be determined by how you prepare yourself.
  • by tcyun ( 80828 ) on Tuesday July 10, 2001 @01:51PM (#93314) Journal

    I must say that there are plenty of people (managers, support, IT, HR, etc.) that have the exact same types of problems/foibles/etc. Why is it that they are focusing on programmers instead of how to more properly screen out these types of employees, work with them, provide education to them, etc.

    while I instinctively agree with the article's statement that prima donnas should be removed from teams (there is a decent discussion towards the end of the article), I feel that there should have been some more discussion in the article that did not just write them off completely.

    The article's subtitle is "managing the employee..." I guess that firing them is one way to manage, but I hoped for a more interesting solution.

  • by sopwath ( 95515 ) <justins at visi dot com> on Tuesday July 10, 2001 @02:30PM (#93315) Journal
    I hate how they recommend making it look like they're just going to replace you. (the managers replace the programmers) What the hell kind of work environment is that? I've worked at places where my job security was about nill and everyone wasn't working hard, they were trying to make it look like they were working hard so they didn't get fired. That's a bad way to run a business.

    The article also recommends hiring smart, not brilliant, people. Those brilliant people end up changing the world, I'd like one of them working for me if I ever get into a managment position. Just think what one of those brilliant people could do for your company or your project for that matter. Most things aren't earth shattering, but you can change the way a lot of people do thier work. Someone like Gates might have outright taken a lot of things from Apple, but his relentless persuit of what he wanted made him the richest man on earth. Where would we be if he had just done eveything IBM told him to do. There'd be no linux revolution, becuase the home PC would never have taken off in the first place.

    sopwath

  • by Fjord ( 99230 ) on Wednesday July 11, 2001 @04:40AM (#93316) Homepage Journal
    Sometimes management think that 9 women and an abortion doctor can make a baby in 1 month, but what you really end up with is a bloody mess.
  • Interpersonal communication problems are the norm in every aspect of human endeavor. Someone who has trouble communicating, or more accurrately, trouble working well with other people can cause all kinds of trouble no matter what you're doing.

    Egotistical and abrasive people who program might stand apart because programming is a discipline which tempts one to think of it in objective terms - that there might really be an up or a down, a "better" or "worse" solution... additionally, we tend to think of programmers as bricklayers; once it is clear to a bricklayer where the wall needs to be, he should be able to build it without incident, and joining his work with that of another craftsman should be straightforward.

    I suppose a reporter might lately find it a stereotype well-developed enough to "report" on; the shortage of programming talent worldwide actually has given programmers more clout in their endeavors; mobility, stakes in their companies, etc. And of course, more ability to make spectacles of themselves without causing lightning to strike.

    The annoyance of a newly minted ego, and the difficulty with which it is sometimes dispatched, coming somewhat out of left-field, as it were, must certainly disturb the established primma donnas of the workplace and the world, and those that observe them. Certainly, we must see this "phenomenon" in the context of the irrational, antisocial behavior we have come to expect from others; our "executive class," for instance - producers, managers, entrepeneurs, owners, landlords...

    In winding up, though, I can't help but think that the particular experience of the programmer lends them to concern with organizations, structures, rules, and hierarchies, and because of this, they may be continually confronted with the derivative of the moment's annoyance, seeing its underlying, persistent and tantalizingly correctable causes, finding unique sources of frustration in them. The tendency to see one's life, or one's company, as a system, and to understand it with the particular rigor and clarity of the skillful architect, may frequently lead an engineer, quite unsuspecting, into frequent (and to the layman, inexplicable or antagonistic) conflict with those around them, unless or until their experience with people, and their understanding of human relationships, allows them to act on their feelings with more sophistication.

  • by MrBlack ( 104657 ) on Tuesday July 10, 2001 @01:59PM (#93318)
    I assume you're referring to the "Surgical Team" style development team where someone is the "chief surgeon" and everyone else fills in to support this individual. I can see your point, but I doubt many surgeons would pull the type of shit prima donna programmers pull.

    Surgical Team Member: What's route do you plan to send the arthroscope down doctor?
    Chief Surgeon: I can't tell you what I'm doing, it's too complicated, now look away everyone, only I may look at this stage of the operation.
    Surgical Team Member: I've finished the sutures, doctor.
    Chief Surgeon: You call those sutures? My cat has coughed up better work than that.

  • by jgerman ( 106518 ) on Tuesday July 10, 2001 @06:51PM (#93319)
    Dude can I work for you?

    Seriously. Personally I'm much happier at work when the leash is removed and I can just run with whatever comes down the pipe. While I realize the importance of doing the day to day things and getting my job done, it's the coolness factor that drew me to computers as a child. Regardless of whether I'm playing with something that's theoretical or practical I'm at my best when I'm left to explore. Sometimes it's exploration of something that has been covered before and it's just new to me, and other times I may be breaking some new ground. But either way I'm learning and growing (and taking steps down the path to computer geek enlightenment). Whichever way you look at it, I'm willing to offer up my drive to explore and solve problems to whatever company I work for. It's only of benefit to the company when you let passionate workers loose (at least occasionally). I'm not saying let them loose constantly so that no daily work gets done, but it only takes some freedom to keep people like me happy. I'm ten times as productive when I'm fired up about something than when I'm not.

  • I find it interesting that the absolute last resort that the article mentioned in dealing with it was sitting down with the tech worker and talking to them about it. But that seems to jibe with my employment experience in silicon valley.

    I have not once ever been approached by a manager, even informally, saying "You know, I like some of what you're doing, but I could really use some more of xxxxxx" or "I'd like to see some improvement in xxxxxx". I'm not talking about the old-school microsoftian pseudo-confrontational insults and "motivation" you'll get from some hardliners. I'm talking about basic honesty and constructive criticism, like a healthy romantic relationship or friendship - where you actually talk about potential problems and head them off at the pass.

    At my employee reviews (which I had to ask for), they were always 100% positive and I had to specifically ask "What sort of things would be helpful for me to WORK on or improve upon?" and it was like pulling teeth getting them to answer. And I know first-hand that after enough time of being ignored in that sense, it gets easier and easier to start slacking off and pulling attitude.

    There are a lot of "prima donna egotists" out there that will probably give you a couple of surprised blinks and then actually be receptive and adult to a manager that goes up and has an honest, concerned, constructive conversation with them.

    tune

  • by www.sorehands.com ( 142825 ) on Tuesday July 10, 2001 @02:39PM (#93321) Homepage
    Learn from them.

    While at MSI, I had the tech support, later became the product manager come to me with, "I know this is a stupid question..". I taught him enough to come to me with a question that had been thought through and in some cases a possible solution. Or, if there was a bug, he would tell what steps to reproduce, isolate, and classify the bug prior to comming to me. In a little time, he started learning alot.

    People don't learn by being told what to do. When people think and understand, they learn.

  • by TekPolitik ( 147802 ) on Tuesday July 10, 2001 @01:58PM (#93322) Journal
    The best revenge for prima donnas is to give them what they want until thep choke.

    I'll second this. We had a prima-donna here recently who loved to find the most obscure way possible to implement a feature. If there was a direct way, he'd never use it. His mission was to show how "clever" he was by using obscure C++ features or arcane side-effects of them to achieve his ends. He always thought he had the best ideas on how development should be done and wasn't backwards about saying so.

    So, I gave him a senior role. He choked on it and three months later he resigned.

    The thing is, people who take this approach may be clever at some things, but designing and implementing workable and maintainable projects isn't one of them. Prima donnas will hang themselves, given enough rope.

  • by giantsquidmarks ( 179758 ) on Tuesday July 10, 2001 @01:44PM (#93323)

    There are also prima donna Managers, Executive assistants, Bankers, Stock Brokers, Doctors, Professors, Hair Stylists, etc... In short, there are prima donna PEOPLE who happen to make a living at a specific profession.

    It is easy for a craftsperson to be a prima donna because they can easily come to the false conclusion they are unique.

    You know what... If I write a program in a week that saves my company 700,000/year over the next 5 years... i'm going to have a little personal pride. It's human... It's fun...

  • by K45 ( 207177 ) on Tuesday July 10, 2001 @04:43PM (#93324) Homepage

    "Yeah man we gotta ODBC the user database from the SQL server into the IIS machine's Java applet to ramp up the TPS and get it all into the Excel template for the reports for the CIO I tell you whut."

    Mmmm.. yeah, I've been meaning to talk to you about your TPS reports.

    (if you're not laughing, go watch Office Space)

    K45.

  • by evocate ( 209951 ) on Tuesday July 10, 2001 @04:15PM (#93325)
    but just imagine a beowulf.... never mind.

  • Something I became aware of years ago was that other people had a certain knack for plowing through the drudgery and getting done things I that I would have found painfully boring and avoided. Learning to be a contributor as a big asset and when I interview people I look for that kind of attitude first. Saves trouble later.

    --
    All your .sig are belong to us!

  • When the manager finally decided he'd tolerated enough shenanigans, he confronted a loss of face and credibility with his superiors. Why? Because he had to tell upper management: 'I want to get rid of the most talented person I've got.' And his bosses thought he'd lost his mind.

    "They're very smart," Andretta says of prima donnas. "And they know who their audience is - upper management - and they play to them very well."

    Why use your powers (with upper managment) for Evil, of course, and get the middle layer drone out of the way first. They should have nuked her the moment she went upstairs... Smart, but not smart enough, I guess.

  • ALL good IT people need to have the "swagger"... That means that you KNOW what you are doing, and project the confidence that you do.

    Swagger means you don't BRAG about it, or praise yourself, it just means you "have it". Praising yourself and making unreasonable demands is boorish..

    Swagger is cool.
  • As a primma-donna programmer (yes, I do have the "31337 H4X0R" bumper sticker, and a yellow post it above my monitor that says "THE MAN" with a small arrow pointing downward which I raise up and down the wall depending on how well my code is running that day), I can say this: management, we are not your problem. Sure, sometimes we act like we know everything and take on too much responsibility, but there's a difference between us and other employees: we DO know everything (or can learn it quickly) and can get it all done. It may take longer than you'd like, but then again, in some cases the last time you've brought your touchpad to a debugger was in the ways of terminals and mainframes. What you have to worry about is the prima donna IT folks...folks who like to act like WE are the cause of all of THEIR problems. Now, I'm not perfect...sometimes, I catch an exception I should have thrown, or forget to tell a thread to sleep and it takes up 99% of the CPU. But that's easily reparable. The IT folks around my company love to call us up when something breaks, wake up the ornery QA guy to back off the code at 2am and call us at home to drive in and fix stuff. We're expected to be johnny on the spot with information about every aspect of the application -- even ones we've never touched -- and to know how to fix any problem. We're architects, contractors, electricians and maids to the applications we build, and if we ask for even a moment of assistance from a monitor or official -- be it a password, a new directory, or even the version number of a server we're running -- it's "go away, we're busy, go break some more code."

    Look, coding is not a job for the faint of heart. Real coding is an intensive process that requires you to learn and relearn concepts on the spot, to merge technologies designed by guys like us but packaged by moron marketeers and locked down by paranoid "systems engineers" (who, by the way, are as much engineers as my brother is with his Lego Castle set), disparaging technologies that do almost what you need them to (but not quite), and to do all of this admid pressure from all sides (customers, management and our own sense of impending deadlines). It's a process that keeps you away from your family and friends, working on something which has enraged you to the point of disbelief, a process which saw me afront a monitor at nine PM on my birthday, repairing a server which some IT dipshit had patched with a new kernel before testing it (or asking if it might break everything). It's an exciting process, stressful at times, and yet perfect for the obsessive tinkerers and puzzle solvers of the world because every day offers new challenges and new possibilities to advance your knowledge.

    And the fact is this: we make your applications sing. Even the worst of us has the power to really make technology do what we want, instead of merely making it do what it was told. If you want to label us as egomaniacs, primadonnas or whatever, that's fine. But the second you start using your position as a prybar to make us operate mindlessly like a fry chef or a gardener, you start destroying the specialness of a good programmer. And, we will resent it. That resentment will surface in a decreased willingness to go beyond the call of duty, to exceed the 8 hour work day, or to throw in free hours to customers when we make mistakes. I'm not saying I'm a dick to other people in the company; just that I'm an idiot for spending as much effort on work as I do, and I won't spend it if treated poorly for my efforts. I take joy in the solutions I create, and the fact that I do create solutions...and not just additional problems for customers and co-workers. This joy surfaces in extreme zeal for work customers have complemented me on, interfaces that I've made more utilitarian than necesary, code that is well commented and efficient, and all those other simple things that make a coder a good coder.

    By the way, I mean no offense to fry chefs...I respect people paying their dues in fast food. I do mean offense to IT primadonnas.
  • by alcmena ( 312085 ) on Tuesday July 10, 2001 @09:24PM (#93330)
    Prima donnas will hang themselves, given enough rope.

    The important question is: did they wrap the rope around everyone else's neck before they jumped?

    Letting prima donnas roam free will hang them, but how many others go with them? The better idea is to stop the before they get out of control. Have checks to see if documentation is up to date. Have checks to make sure at least a few other team members can understand what the coder did.

    If neither of those are being done, that is now the fault of the manager. The prima donna made have been the cause, but the manager is at fault for letting it get out of hand.
  • by JubJubb ( 318098 ) on Tuesday July 10, 2001 @02:44PM (#93331)
    I'm pretty sure they're not talking about the scourge of IT, the loathsome College Grad ;)...

    From the article:
    "...the most talented person I've got..."
    "...They're very smart..."
    "...the best programmers' drive for excellence can leave them understandably curt when others seem less committed..."

    etc...

    Sounds like the Prima Donna is an exceptionally talented programmer, and not, as you say, a one-trick pony. Ego problems aren't confined to young people, you know. But maybe I should just shut up and let the older, wiser and bitter speak.

    Can't let those young 'uns get all uppity now!

  • by Anonymous Coward on Tuesday July 10, 2001 @01:43PM (#93332)
    (are we allowed to do this?)

    http://www.itrecruitermag.com/magazine/display-man agement101.asp?ContentID=603

    Let's stipulate from the outset that programmers are allowed to be quirky. Expected to be eccentric. But we're not talking about the idiosyncratically intelligent or the interestingly offbeat. We're talking about the insufferable egotist who can't or won't Play Nice.

    The syndrome often is found in someone like this: a young and brilliant software developer who lives and breathes IT. A true geek, "Hal" spends a lot of work time in techie chat rooms engaged in in-depth UNIX conversations, sharing code and discussing programming challenges. Despite his inclination to partake in on-the-job recreation, Hal is a prolific and productive programmer. So far, so good. Just another proud member of the hacker tribe, right? But unfortunately, Hal has another side. He makes rude and disparaging comments about his coworkers. If he doesn't like a project, he'll let it slide. In particular, he resists the drudgery of correcting or upgrading "someone else's ugly program."

    Hal also challenges managerial authority and expresses his contempt for his position. He tosses out statements like, "I could be making $200 an hour doing security work," and makes other muscle-flexing gestures to show that he can do what he wants, when he wants.

    Liz Rosenberg, IT director for Driehaus Capital Management [driehaus.com], an investment management firm in Chicago, recalls the Hal-type she managed a few years ago. "He seemed to feel that he was this all-knowing programming god," she says. Brilliant but bratty, though, because for every technical problem he solved, he created a personnel problem for the team.

    Like Hal and like most wizards, prima donnas really do have talent and a true love of IT. But, the prima donna combines this passion and expertise with arrogance or lack of concern for others. With Hal, it was constant complaining and carping. Other symptoms of prima donna syndrome include an obsessive desire for control, the attitude that the world revolves around them, and the conviction that the regular rules don't apply to them.

    CONTROL FREAKS
    Ed Wojchiehowski, CIO of Menasha Corporation [menasha.com], a conglomerate of manufacturing and services companies headquartered in Neenah, Wisc., recalls an individual who created a very innovative logistics software package. Impressed, Wojchiehowski asked the programmer to work with others on the team to expand and modify the package to make it, oh, actually useable to the corporation.

    But the programmer, call him "Spock," refused to share information with other programmers. Spock claimed his innovation was too complicated to explain and that by the time he was done explaining, he could have changed the program.

    Wojchiehowski concluded Spock's real agenda was control. "Prima donnas hold back information or work 80 hours a week so they don't have to share information with anybody," the CIO says. "I've discovered in many cases, it's almost physically painful for them to give it up."

    ALL ABOUT ME At other times, prima donnas give the impression that they believe the world and the project revolves around them. Early in the beginnings of Perseus Development Corp., [perseusdevelopment.com], a provider of Web-based survey software and services in Braintree, Mass., Jeffrey Henning, president of the software division, was managing a developer who took the attitude of, "I'm the most important person in the company, and without me, you couldn't exist." "Angela" refused to help other programmers with their work, yet expected them to drop their work to help her.

    This developer was very valuable: She'd written most of the early versions of the company's products. "Nevertheless, she was close to being more trouble than she was worth," Henning says. Her exclusive focus on her own needs was a constant obstacle for the department.

    "The term 'prima donna' comes from a difficult leading woman soloist in an opera," Henning reflects. "I think 'soloist' is a key word. A lot of prima donnas act like soloists - they don't work well with the team, and they think their voice is the most important."

    BEYOND THE RULES Some prima donnas behave as though ordinary rules, such as work schedules, don't apply to them. Andy Andretta, a senior partner with Daprex [daprex.com], a software evaluation firm in Stamford, Conn., recalls a prima donna who found just showing up to work regularly a problem. The employee, who held a second-level support position for a software product, often worked magic fixing bugs - when he was there. "But," as Andretta points out, "he's not too valuable if he's not there, which was quite a lot."

    The situation only deteriorated as the manager continued to accommodate the delinquent, Andretta says. To complicate matters, the prima donna had a shrewd sense of timing and organizational politics. Like the Lone Ranger, he'd ride in just in time to play the hero in emergencies and take the credit. "He'd put the bow on the package," Andretta says.

    When the manager finally decided he'd tolerated enough shenanigans, he confronted a loss of face and credibility with his superiors. Why? Because he had to tell upper management: 'I want to get rid of the most talented person I've got.' And his bosses thought he'd lost his mind.

    "They're very smart," Andretta says of prima donnas. "And they know who their audience is - upper management - and they play to them very well."

    Seeing it from the prima donna's perspective The trick for the IT manager is that some of these charges could also be made, to a lesser extent, against positive, contributing employees. For example, playing games or spending time in techie chatrooms is common and can help many programmers to be more productive. As Peter Seebach, a member of the technical staff of BSDI.com, a firm providing Internet infrastructure-grade systems, software and solutions in Berkeley, Calif., writes at his Web site "The Care and Feeding of Your Hacker" [http://web.demigod.org/~zak/geek/hack.shtml], "Hackers, writers and painters all need some amount of time to spend 'percolating,' that is, doing something else to let their subconscious work on a problem."

    Menasha's Wojchiehowski agrees that this kind of putzing around while searching for an idea is perfectly acceptable. "I don't worry if they're playing a game," he says. "And, I don't have any problem with walking into somebody's office and finding them with their feet on their desk staring at the ceiling. They may be thinking about the problem."

    It's also true that the best programmers' drive for excellence can leave them understandably curt when others seem less committed. Eric Haddan, a self-described "recovering prima donna," has been frustrated when working with team members who seem more motivated by opportunism than a true love of programming. "The market is flooded with a bunch of people who just took some classes, but they're not really into it," says Haddan, a software development manager for eSynch Corp. [esynch.com], a Tustin, Calif., firm which provides video delivery tools, streaming media services, and software utilities. "They have a degree and they've heard the money's good."

    As for the charge of "arrogance or rudeness," some hackers argue that it's just as big a failing for others to be too tender or defensive. "I used to be a lot meaner to co-workers than I am now," Seebach, the hacker translator, reveals. "People say, 'They worked hard on it, so don't trash it,' but on the other hand, would you like to drive over a bridge with the assurance that people worked hard on it? Or do you want to know they got it right? A complete refusal to acknowledge either side of that constitutes failing to play well with others."

    SIGNS THAT THEY'RE GOING PRIMA
    So how do you tell the difference between someone who's just creative and frustrated and someone who's suffering from a bad case of prima donna syndrome? The true prima donna, according to managers, won't work with you or for you. Andretta believes that prima donna syndrome is marked by denial. "They do not accept the fact that they are wrong," he says. "It's not them, it's everyone else."

    As a result, a prima donna often leaves havoc in his wake. Not least is the damage to morale. Seeing someone else, no matter how talented, disregard the rules that others must follow can be dismaying to employees who are working hard and playing by the book. "Once you start with favoritism you turn good people sour," Daprex's Andretta contends. "It's never worth it."

    Besides seeing someone get away with murder, colleagues may wind up doing the prima donna's work, which really causes resentment. In Andretta's situation, other employees often had to pick up the work of the AWOL programmer, delaying the completion of their own assignments. "It affected our work load and morale," Andretta recalls.

    CIO Wojchiehowski points out other hazards. The controlling prima donna who holds onto information will eventually move on - leaving others to figure out what the blazes they were doing. Not surprisingly, such an event can delay or even doom projects completely. In either case, the company loses face with its clients. "It's just negative in all aspects," he says.

    HOMING IN ON THAT GIANT EGO
    If you've determined that you've got a true prima donna on your staff, the next step is figuring out what to do. Sometimes you can make some management moves that rein in the runaway ego. But you must move quickly. "I can assure you, prima donnas only get worse with time," warns Wojchiehowski.

    If the individual is productive, but lacks elementary social skills, telecommuting may be an option. In other cases, selective delegation and assignments may give the individual enough challenge to keep them out of too much trouble. The best programmers, prima donnas or not, dislike repetitive tasks. Designing prototypes, for example, can be a good assignment for many of these very bright individuals. But Henning stresses that they are best assigned to prototypes, not actual products. "Products," he points out, "require team input."

    Former prima donna Haddan suggests keeping a regular flow of applicants coming in for interviews. In other words, keep the feet of difficult techies to the fire. "If you do find someone good, move her in and start weeding out the bad ones. I am willing to bet you would have to do this only one time," he says. "If the attitude persists, repeat the process."

    STRAIGHT TALK EXPRESS, TECH-STYLE
    But, sooner rather than later, the employee will have to be confronted directly. Perseus' Henning had been on the verge of firing Angela, but gave the situation one last try with a blunt performance review. He catalogued and congratulated her strengths and also described explicitly where her performance was failing. The review seemed to help Angela settle down. "I think part of her behavior was insecurity," Henning says. "She was afraid that she wasn't really valued."

    Angela's successful turnaround appears to be rare, however. In the end, most managers aren't optimistic about salvaging prima donnas. Instead, they aggressively rid their staffs of them as quickly as possible. "I'm a strong believer in people and am willing to invest in their development," Wojchiehowski explains. "But, frankly, as soon as I understand that it's a prima donna situation, I work to eliminate it. You work with those who are team players. And those who aren't, well, in the most loving manner, you help them exit."

    Daprex's Andretta dismisses the idea that a prima donna's talent makes the extra grief worthwhile. "It doesn't matter how smart they are, they will hurt you," he warns. "And, the smarter they are, the more they can hurt you." He believes that it's better to invest in bright - but not brilliant - people and train them to be more productive. "You can buy talent," he says. "Personality, by which I mean a good attitude, really can't be bought. I'll take a team player any day."

    Sears (searscomm@aol.com) is a contributing writer in Washington, D.C. Know a prima donna? Tell us your most unbelievable anecdotes at editor@itrecruitermag.com.

  • by msuzio ( 3104 ) on Tuesday July 10, 2001 @04:31PM (#93333) Homepage
    I couldn't agree more. I went through a similar course -- I was under-motivated in my job at a Big Three AutoMaker That Rhymes With "Bored", and I was sure I was, without a doubt, God's very gift to programming.
    Then I went to another company, where I was swiftly reduced to average. There were about 8 of us handling a boatload of Web programming, and in that pressure cooker I learned how to really program.
    I left when the stress got to be too much... to find that now I really was one of the best people I could find at what I do. But somehow, the cocky attitude didn't come with me. Now I'm a manager and technical lead, and I have confidence. but I also know how to lead and mentor others.

    Of course, I'm here at 9:30pm working late because I know I can code these servlets better and quicker than my team members can -- but hey, sometimes the cocky attitude is the best thing to have :-).
  • I can tell you haven't worked with surgeons.

    That IS pretty much how they can be in the OR.

    Some are nice, but all will give you crap about the quality of your stitches until you turn 50.

    ---------------------------------------------
  • by Pedrito ( 94783 ) on Tuesday July 10, 2001 @03:57PM (#93335)
    Someone else mentioned that age is the cure. They're right, at least in my case. I was definitely a primadonna programmer. I started programming when I was 10 years old and I was probably 25 and had been doing it for a living for at least 7 years before I even met a programmer who came close to my skills.

    Then I started a job that had at least 3 programmers who were much better than me. They became my mentors. The system architect was one of those very bright guys who told you to do things one way, but wouldn't tell you why. You couldn't get it out of him by asking. I finally realized that if I just refused to do it his way and said something like, "I'm going to do it this way because blah blah blah.." He would say, "That won't work because blah blah blah..." And hence, I learned from him, despite his best efforts to the contrary.

    Now, I'm in a company where I am the best programmer (I'm also the architect and the manager), but I'm not the primadonna I once was (I don't think, maybe my programmers would differ in opinion). It's kind of strange, I had lunch today with one of those mentors of mine, and he may be looking for work, and I'm way ready to hire him. For one thing, he'll be able to be the best programmer on the team. It's not a good thing to be when you're the manager. It takes up too much of your time dealing with technical problems.

    But, I'm digressing in many directions. I think the point I'm making is that age and experience (particularly, experience with programmers who are as good or better than you), will fix the problem in most cases.

  • by Fjord ( 99230 ) on Wednesday July 11, 2001 @04:34AM (#93336) Homepage Journal
    Have *you* tried reading code?

    This, I find, is the major problem: people don't *try* reading the code. They just assume it will be too hard to understand and bitch and whine and then reimplement the same things over again because it's not theirs(tm).

    I have tried reading thers code, and to me, it looks like code. We all code in the same language here (Java). All code follows the same conventions of instantiating objects and calling methods. If I really wondering about the state of the program, I can put in a println or use a debugger (I find printlns are easier, because they aggregate and I can better compare the state of the program at different times).

    It's like merging files in CVS. Wherever there's a conflict, it shows your code and their code right where the conflict is. Just figure out how to merge it. It should be in a language you understand.

  • by Animats ( 122034 ) on Tuesday July 10, 2001 @08:00PM (#93337) Homepage
    On on March 17, 1986, Autodesk ran an ad for "super programmers". [fourmilab.ch] The company subsequently became a billion dollar company, and most of those "super programmers" are now multimillionares.
    • Are you one of those rare software people whose productivity is hundreds of times above average?

      Autodesk, Inc., the leader in computer-aided design, founded by people like yourself, invites you to join us.

      We're The Best: You're The Best

      Our company was built by people who never said, ``I can't do that.'' If you're the person we're looking for, you'll be able to design, implement, test, and debug complex software, both alone and collaboratively. The code you write will meet the highest standards of efficiency, maintainability, and modularity. You'll know how to integrate changes in large, complicated programs, and you'll combine design and implementation skills with an intuitive feel for the evolution of the product as a whole and for its position in the marketplace.

      You'll be able to find or develop the theory you need to get your job done. You'll be literate, and able to communicate complicated technical concepts in simple and readable language. Your work documentation will meet the standards of the best tech writers and be suitable for immediate inclusion in our user manuals. You'll be able to express yourself clearly and persuasively, whether in a design session or while speaking with prospective customers at a trade show. And you'll take personal responsibility for all your work, as a matter of course.

      You'll care enough for the commercial success of your programs that you'll work effectively with marketing and sales people, contributing ideas to best promote the benefits of the products you'll be developing. You'll take an active interest in the work of other people in the company, and be willing to apply your expertise to help with their problems and develop their skills.

      We Don't Want Less Than The Best

      What will we do? We'll pay you more than anybody else in the industry. Your pay here can start as high as $60,000 and rise as high as your contributions justify. There's no ceiling on the pay scale for technical people here; you can earn $100,000 if you're worth it and prove it to us. We give our workers stock options that mean something. Unlike companies that look at options as a way of enslaving employees, we intend our options to let you share in the success you'll be helping to create. If we do our job, you won't want to leave. And since we're a public company, your options represent real stock with real value, not funny money.

    They were quite serious about this. Note the criteria. Autodesk insisted on people who were literate. All their key programmers wrote well, often for publication. And a strong interest in theory was expected.

    Then around 1990, Autodesk got "adult supervision" in the form of Carol Barth, the new CEO, and proceeded to underperform the Dow for a decade, after being the fastest growing company of the 1980s and profitable from the first months.

  • by Sheepdot ( 211478 ) on Tuesday July 10, 2001 @01:59PM (#93338) Journal
    The number of capitalist bashers on /. seem to think the US is a capitalist society. It's more akin to a odd breed of socialism-capitalism, where the only chance one has of becoming a "capitalist" entails copyrighting or patenting a product, suing those that use it, and using the government to impose regulations on competitors in the name of "public good".

    I have yet to hear any economist call that capitalism.
  • by gentlewizard ( 300741 ) on Tuesday July 10, 2001 @02:12PM (#93339)
    To some extent, prima donna behavior is tolerated depending on the scarcity of the person's talent, and the general market for talent in the IT industry.

    We've all heard the story of the third shift computer operator who demanded -- and got -- his entire floor locked off during his shift because he liked to work in the nude. And as long as he was the only person who could do that job, the company went along with it. But people like that are the first against the wall when the market frees up.

    Any tech job is only 15% technical. The other 85% is people skills. Over the long term, the 85% catches up with you if you neglect it over the short term.

  • by MSBob ( 307239 ) on Tuesday July 10, 2001 @04:00PM (#93340)
    Get them to program in pairs. Primadonnas thrive in the environment where they can hoard their own code. They get territorial about their work and don't let anyone else near it. If all programming is done in pairs noone has a piece of code that they own exclusively. It works miracles at eliminating primadonnas. That's one of the main reasons why eXtreme Programming recommends the practice.
  • by freeweed ( 309734 ) on Tuesday July 10, 2001 @03:01PM (#93341)
    One of the aspects of XP is that all coding is done in pairs, know as pair programming. This type of programming creates better code in about haft the time

    No wonder the OfficeXP warez that I snagged was 3 fscking cd's!. Oh wait, he said 'better', not 'more' :)

  • by Anonymous Coward on Tuesday July 10, 2001 @02:50PM (#93342)
    Certainly. To put it in the level of detail of the article, there are 2 types of programming projects, and 2 types of programmers: 1. projects that can be done by 1 person 2. project that require a team 1. people that work best alone (prima donna) 2. people that work best in a group Obviously the truth is in between for both, and personal chemistry is usually a big factor. Yes, Alan Cox could head up and probably finish your kernel group's project in a week alone, and no, you don't have a working relationship with him so you better make sure the guys you do have a working relationship with work together and stay on track to get you to the finish line. To me, this looks like really airy-fairy wisdom regarding talent - and what the MMM says about coding (problem-solving) applies here too: there is no silver bullet. Not in the code, not in managing the coders (yes, managing us beasts requires talent).
  • by Ian Bicking ( 980 ) <ianb@@@colorstudy...com> on Tuesday July 10, 2001 @06:50PM (#93343) Homepage
    Those things you are talking about aren't programming, they are system administration. I agree that a mediocre system administrator can be good -- at least, mediocre as in not very creative or perceptive. Reliability is more important for an administrator -- computer or otherwise -- than innovation.

    But that's not the case for programming.

    I would concede that certain maintenance chores can be handled by mediocre programmers without much risk. At worse you just go back to the original version. And there is some grunt work to programming too, some boring code that needs to get written. But if you have so much junk code you aren't abstracting right. One of the nice parts about computers is you don't have to solve the same problem over and over again.

    But I still pretty much stand behind my original proposition. For programmers, not all the other tasks associated with programming.

    In the end you actually have to make something. Teamwork isn't about making anything. Competence, intelligence, and skill are what make things. Teamwork helps those things. But someone who's all teamwork and no skill isn't someone you want programming. I'm not defending prima donnas, I'm just saying that a prima donna who is competent isn't all bad. One who isn't competent is obviously a double loser.

  • by LunaticLeo ( 3949 ) on Tuesday July 10, 2001 @02:00PM (#93344) Homepage
    I have dipped into bad behavior before. Now I manage techies.

    First of all, those who won't comment code and document design should be beaten severly about the head with a LART. That is bad coding/design practice and is completely unacceptable. Put them on undocumented code. When they bitch have them explain why it is bad and how the company should fix it. Listen to the response and implement. And you might notice their attitude changing. If it doesn't replace them.

    Second, give them responsibility. I was once a camp counseler. I took the jokers/ring-leaders and put them in charge; small things at first then bigger things. They dig the power and are usually the most effective leaders. Again, if it doesn't work replace them.

    Last, and most imporant. Have a frank conversation with them and respect their opinions. There is nothing as powerful as a little respect. Small reasonable acts of control and general respect are the best way to get people with the program. If it doesn't work, what's left? Fire them.
  • by Katravax ( 21568 ) on Tuesday July 10, 2001 @01:50PM (#93345)

    In a nutshell, the article offers these solutions:

    1. Let them telecommute
    2. Have them design prototypes rather than production apps
    3. Let them know you're interviewing others
    4. Be honest in a review
    5. Fire them

    As a full-time programmer, I have to admit, I don't see a slew of other options. I've dealt with prima donnas, and have probably been one myself at some point. Frankly, the best cure I've seen for it is age: Almost all prima donnas I know are under 25 and haven't worked more than one or two jobs. They haven't yet come into contact with those that are more skilled yet, or haven't been given a big enough challenge yet. A good programming butt-kicking goes a long way.

    I also have found that most places suffering from prima donnas are also suffering from a lack of older, good programmers. This tends to reinforce the attitude of the troublemaker -- they think they're the best because it might be true where they are. If possible, pairing them off with a mature, more experienced programmer might give them a dose of the Total Perspective Vortex.

    The one last suggestion, and it's mean and may be counter-productive: Make them code in a language they don't know yet. Most prima donnas I know are one-trick ponies, and a tough task in an unfamiliar language may show them they're not infallible.

    That said, and the part that will get me modded down into hell, is that every prima donna I've met was a recent college comp-sci graduate at the time. They're only great because their world is so small, and they haven't had to deal with real-world programming and real-world people yet. I guess it goes back to my earlier suggestion: the best cure is age.

  • by tmoertel ( 38456 ) on Tuesday July 10, 2001 @01:51PM (#93346) Homepage Journal
    Suggest to your local prima donna that he enter the ICFP Programming Contest [inria.fr]. Muse aloud that, since he's such a brilliant programmer, he has a pretty good chance of winning. Tell him that the bragging rights ought to be priceless around the office, and I'm sure that he'll bite and actually enter.

    Then, let the contest do the work for you. Watch as your prima donna gets functionally mauled and then garbage collected into oblivion by some of the most talented programmers in the world. Most likely, your elite coder boy won't even understand the challenge task. (Anybody remember the '99 task [virginia.edu]? Ouch.)

    From that point on, subtle reminders of his contest performance will keep your boy in check. "Gee, I thought you would have managed to finish the first part of the challenge task, at least. You must have been sick or something. Well, there's always next year's contest!"

    Try not to chuckle aloud when he mentions that he won't be entering next year because of vacation plans.

  • by drivers ( 45076 ) on Tuesday July 10, 2001 @02:12PM (#93347)
    If possible, pairing them off with a mature, more experienced programmer might give them a dose of the Total Perspective Vortex.

    "You've been in the Total Perspective Vortex?"

    "Yes."

    "And you've seen your true perspective relative to other programmers?"

    "Yeah..."

    "and?"

    "Hey man! I'm John Carmack!"

  • by weave ( 48069 ) on Tuesday July 10, 2001 @06:49PM (#93348) Journal
    Everyone Is Replacable

    As a tech manager of 25 I find this statement can be pretty damaging. Maybe true, but practically and easily? I'm tired of being reminded this when I'm trying to push for benefits, concessions, perks, or whatever, for my staff.

    Unless you're permitted to offer what the market will bear salary wise and can step around silly H.R. rules, this is not entirely true. Losing a talented person can be a real hit, and the smaller you are, the bigger the overall hit.

    I work at an educational institution. There are a lot of non-salaried perks here including job security (our "owner" is the state which is unlikely to go out of business or be bought out), college atmosphere, etc. But the pay isn't "market" either. Furthermore, in the realm of trying to be fair and non-discriminatory, I'm restricted in recruiting methods. For example, I had the hardest time getting approval to give out a skills test to applicants since it might be biased (yeah, it is, against stupid people and tech buzzword bullshitters).

    All of this adds up to making it a bear to replace people and increasing the risk of hiring a mediocre person. And in government, firing mediocrity is almost impossible. You have to be really bad to get the sack.

    So the noble goal of trying to increase the value of my unit's function to the institution, I need to try to maximize the talent on board and minimize the need for some staff to carry others and hence decrease overall productivity and effectiveness. This is not as easy as it sounds.

  • by QuantumG ( 50515 ) <qg@biodome.org> on Tuesday July 10, 2001 @04:15PM (#93349) Homepage Journal
    Man, you are onto something there. I have often thought, "you know, if I'm willing to donate money to Freenet, why dont I send a few call girls round the Theo da Raadt's place?" Now there's a guy who needs to chill out.
  • by Marasmus ( 63844 ) on Tuesday July 10, 2001 @03:10PM (#93350) Homepage Journal
    I'm the stereotypical candidate for prima donna syndrome: a few days shy of 21, dropped out of the engineering program at a state University because it was unchallenging and mediocre on its very best days, and dove into the IT field. I'm a Unix Sysadmin for a little company with scrambling and confused management - a glorified dot-com.

    Since it's a small company, I'm essentially also the DBA, network admin, Cisco guru, neurotic PERL geek, and so on. I get frustrated quickly with people. I word my sentences carefully to provide the most clear and concise meaning possible (management calls these 'very curt' responses!), and attempt to usher the questioning coworker out of my line of attention as quickly as possible. I tell programmers that their idea on implementing this or that is "like an ostrich - it's got wings, but there's no way in hell it's gonna fly." I'm a young, cocky asshole.

    But WHY? It seems that no one has asked WHY we prima donna types are this way. My explaination is that I'm a die-hard perfectionist. I'm very interested in the architecture of things... both concepts and actual structures. I'm big on using available standards, or creating thoroughly documented standards if necessary. I'm big on harmony. I don't like solutions that plug one hole in a leaking boat, just so the water can come in through another large crack. I'm a die-hard perfectionist. Though I'm more than willing to throw really bastardized hacks into place when they do not create new problems.

    If a programmer who specializes in socket programming comes to me with an idea on how to do task X, and I can think of multiple more efficient and more effective ways to do task X (NOTE: I am NOT a socket programmer, nor a specialist at socket programming), I will point the weaknesses that I see in their idea and offer the ideas that came to mind. I'm always constructive and ALWAYS offer alternative solutions, though my thoroughly-learned tendency to be concise with my words sets them on the wrong foot. Half an hour later, my supervisor calls me in and asks me about the 'incident'. He's actually quite understanding and open-minded. I love explaining my reasoning to him - he remembers it and often uses it productively. I explain my reasoning, he's happy, and I'm back to work. However, upper management (2 people, it's a small company) slowly builds an image of me being unfriendly and not helpful. Bad situation for me.

    Management looks at things in terms of investment, risk, and a few other things that I'm not overly attentive of. Technical people often look at things in terms of efficiency and merit of design. However, only a small percentage of techies I know also disassemble ideas and concepts into security and liability to their company. Well, then again, most techies probably work in an environment where the management (at least) has liability already covered before ideas/problems/customers get down to them.

    The merits of design are not the merits of finance and profit. The two sides oftentimes dislike thinking about the other's point of view, or are unfamiliar/afraid of it to some degree.

    The bottom line: I am a prima donna because my point of view of any given situation is very different than management's point of view. I am not excessively willing to look at their point of view, and likewise they are not excessively willing to look at mine. I accept that and try my best to work with them on sharing our points of view. However, a 100% technically-oriented company cannot survive with a 0% technically-oriented management running the show. The components that make the company work aren't going to be properly filled in the right proportions. There's only so far I can stretch to make such things work... after that point, I'm called a prima donna and management holds their noses high. That's fine by me - my self esteem isn't hurt by other peoples' opinions (that i consider misconceptions)... that sort of behavior would not allow me to function well in the technical manner that serves my employer.

    It's a problem of point of view causing frustration.
  • by crashdavis ( 69986 ) on Tuesday July 10, 2001 @05:18PM (#93351)
    I run a consulting firm that specializes in this type of "prima donna" coder to some extent, and no comment I read (including the useless recruiting website article) really explains how to handle them or channel them. Everyone is suggesting that you muzzle them or get rid of them. We should be trying to RAISE the talent level in organizations, not lower it.

    Here's what I've found about how to do it:

    1. Give them what they want and let go of the things that aren't essential. Set some groundrules about overlapping hours but let them come in late. Who really cares if they are in at 8:00am? Some roles in an organization require regular hours, but coding isn't one of them.

    2. These do typically want the hairiest most complicated problems in the organization. Give those problems to them. The mundane shit will bore them and they will quit even if you can tolerate them. The hairy stuff will get done; it will work; and it will get done faster than if you give it to your average IT guy.

    3. Some don't work well in teams at all. We call them "Cowboy" coders. They want to ride in on the white horse and save the day by themselves. Look for ways to carve that kind of work out. If no solo work is there and they have to be on a team, don't put them in charge of architecture, which takes a lot of communication with a team. Put them in charge of an entire vertical section--not a horizontal one.

    4. Most of them want to be accountable for results, not methods. So HOLD them accountable. Don't manage their hours or how they get something done, but agree on an acceptable deadline and bust their ass if they don't make it. Bust their ass by managing their hours and making them write status reports on the next project!

    5. Give them other smart people to work with. Others have already made the point that these guys don't cost 10x as much. For another $10K, you can replace the average guy sitting next to your prima donna with another prima donna. They'll probably get along better and work together better.

    In other words, just go WITH the grain instead of always against it and they will produce amazing things for you. It is a lot like the open source movement. You can get amazing production from people by just staying out of their hair and letting them prove whose dick is bigger. If you can find ways to let them do it their way, your organization will be the richer for it.

    Crash
  • by Jailbrekr ( 73837 ) <jailbrekr@digitaladdiction.net> on Tuesday July 10, 2001 @01:37PM (#93352) Homepage
    These people are absolute geniuses when it comes to programming, but lets face it. No matter how good these programmers are, if they work against the corporation that is paying them, their genius is *useless* when compared to a good/mediocre programmer who has the capacity to communicate and document his/her work.

    Flame on!
  • by jjwahl ( 81757 ) on Tuesday July 10, 2001 @02:35PM (#93353) Homepage
    I've worked with technical types all of my professional life, and I too used to think that I was the ultimate shit. The one that not only knew it all, but had the capacity to learn something I didn't know faster and more thoroughly than anyone else. For the most part this is true, but what I came to realize is that while I am exceptional, I am held in generally high regard because of a couple of things:
    1. I am in a field that is relatively new. The general populace hasn't gotten a chance to even begin to understand computers, what they *really* do, or how to use them to do their bidding. This will change in a generation.
    2. This is (now) a fairly high profile field - lots of press is given to computers and those that master them.
    What computer "geniuses" fail to realize is that the computer field is like any other to an extent. To gain expertise in a subject, you have to spend a great deal of time working on it.

    How many of you can write a pro-forma tax return for even a small corporation? How many of you can set up a filing system for a law office that works? How many of you can set up the business processes necessary for a 10 million dollar company to handle shipping and returns? I think that we would all agree that individuals that can do these things are intelligent and talented, but when one of these otherwise talented, intelligent people can't manage to understand some computer concept, you think of them as stupid. Well if you're that short and narrow sighted, you're probably not that bright yourself.

    There are always exceptional people within any field and many of them tend to be pompous about the fact - it's not a character flaw limited to programmers. Doctors, lawyers, chefs, interior designers, woodworkers, etc... In any of a these professions, you will find people that are arrogant because they're the best and know it, or because they aren't and they don't know it. By definition, the majority of arrogant people fall into the latter category. They've deluded themselves into thinking they're great. And in the computer field, this thinking is often reinforced because they're praised and looked up to by "mortals" for merely knowing what many other computer "geniuses" know.

    Do yourselves a favor and do an honest assessment of your level of knowledge in the computer field you happen to dabble in. Are you *really* in the top 1% of all people that dabble in the same area? If not, give your ego a break and come back down to earth. You're not all that. And if you are, give your ego a break anyways. Nobody likes an asshole. If they appear to, they probably talk behind your back.
  • by Carnage4Life ( 106069 ) on Tuesday July 10, 2001 @01:52PM (#93354) Homepage Journal
    Management calling good coders Primma Donnas always gets on my nerves for a variety of reasons. Many people (including Phil Greenspun [arsdigita.com]) have quoted the confounding statistic that an excellent programmer is typically 10 times more productive than an average programmer.

    Yet I'm yet to hear of a coder who brings in almost half a million dollars in salary. Instead I hear of good coders making about $10K or so more than mediocre HTML jockeys and VB h4x0rs. It continually astounds me that the U.S. claims to be a capitalist society but in this one area we act like everyone is equal when they clearly are not.

    Bruce Perens, Linus Torvalds, Bill Joy and Alan Cox could probably code in one weekend what it would take a team of coders a week to do, yet they at best are not even making twice what an intern at a Fortuen 500 makes. Then to add insult to injury the overpaid MBAs who have wrecked the tech industry now have the nerve to call them Primma Donnas.

    *spitting noise*

    --
  • by cluge ( 114877 ) on Tuesday July 10, 2001 @04:08PM (#93355) Homepage
    Since I can't read the article (Slash Dotted) I'll have to take a wise ass guess at what it said. SO here is my view (for what little it's worth)

    The number one job that you have (unless you are a consultant or outside contractor) is to do/help your company do what it does. If your company sells widgets, in the end, you are a cog in the wheel that sells widgets. (Don't loose site of this now, it gets complicated soon)

    The problem many IT people see is that they forget that they are "selling widgets".

    EXAMPLE

    IT Dept reviews a request from sales dept, spits it back "We can't do this for at least 2 years, this doesn't make sense, you don't know what you are talking about, you fools why do you need this"

    Sales really needs the ap so they go to an outside consultant (Who built the entire app in under 2 weeks) Now sales are running more effectively and the consultant is paid, and the companies IT dept didn't have to lift a finger (And of course notified 30 people in writing that they would NEVER support this outsourced ap)

    The Prima Donnas
    The programmer and the head of corporate IT dept are both Prima Donnas, here is how it breaks out.

    The one programer working alone and un-aided is spurred on by the challenge. He/She has been given a problem, and told that many professionals in a large fortune 500 corporate IT dept. couldn't do it in 2 years time. He/She doesn't care about widgets, sales or corporate IT policy, he/she cares about the challenge and how to meet it. Therefore unconstrained he/she goes about his/her work. His/Her work and the ability to brag about it makes him/her a Prima Donna.

    The corporate IT manager has a fiefdom to manage. After all many many people rely on his judgement, and he is now looked at as the great problem solver for many of the companies troubles. He is insulated by his company, and he fears no reprecussions because he knows too many people rely on him. He gets to dictate policy, and his policy is to make his life easier. He is the corporate Prima Donna. He will be saying "You can't do that" or "That won't work" or "we can't possibly do that on our budget". He is the be all end all of IT in his mind. He listens to input from no one (although he may fake listening to people from time to time) and is easily suprised when people think that he isn't doing a good job. In the end, HIS problem is that he forgot, he's just selling widgets.

    If the corporate IT guy really wanted or thought he was so good that he deserved to cop the "Prima Donna atitude" he should be a consultant. He won't be, he's not secure enough in his own knowledge or lack thereof to venture out on his own (some excuse about personal responsability)

    Prima Donnas exist in every facet of the corporate structure. The thing I worry about is the Prima Donna IT exec, the Prima Donna programer can actually be useful if the management team around him/her has any skill.
    "Science is about ego as much as it is about discovery and truth"

  • by sanemind ( 155251 ) on Tuesday July 10, 2001 @01:36PM (#93356) Homepage
    There is a lot of truth to the usefullness of having a singular person architect a large ammount of code. Software development isn't like many other forms of work; you ususally can't get more output from hiring more software engineers, even good ones. People can talk as much as they like about having good use-case diagrams and using well documented abstract procedure call interfaces, but in software development there are always additional inefficiencies in bringing other people up to the task.

    Even coding on one's own, there is so much to keep track of that all nighter jolt cola inspired images are not mere flights of fancy, but often a real part of the real coders lifestyle. Handling that kind of hierarchical thinking and concern over so many issues often dosen't readily subdivide into multiple people.

    How does this relate to primmadonnas? I don't know. I'm rambling. I've been up coding all night! ;)


    ---
  • by EraseEraseMe ( 167638 ) on Tuesday July 10, 2001 @01:41PM (#93357)
    My parents, for the longest time, due to my burgeoning ego, impressed on me several rules for life that I follow to this day...even if my ego continues to grow ;)

    The rule that applies most here is EIR

    Everyone Is Replacable

    No matter how smart you are, how valuable you think you are, how good at your job you are, how much you can do, there will ALWAYS be someone standing right behind you, ready to take your place, and you should treat each opportunity you have as though the person behind you is going to jump in at any second.

    Invariably, this philosophy led me to be overly concerned about my job security,never share information on projects, not work well with other potential competitors and despise middle management but supremely suck upper-management ass but I love my parents and I think their advice may come in handy for someone else :)

  • Indeed, and is it not written in the Book of Corporate Wisdom, (Tao of Programming 7.2), written by the venerable Yong Yo Sef and translated by Geoffrey James:

    In the east there is a shark which is larger than all other fish. It changes into a bird whose wings are like clouds filling the sky. When this bird moves across the land, it brings a message from corporate headquarters. This message it drops into the midst of the programmers, like a seagull making its mark upon the beach. Then the bird mounts on the wind and, with the blue sky at its back, returns home.

    The novice programmer stares in wonder at the bird, for he understands it not. The average programmer dreads the coming of the bird, for he fears its message. The master programmer continues to work at his terminal, for he does not know that the bird has come and gone.

  • by ackthpt ( 218170 ) on Tuesday July 10, 2001 @01:46PM (#93359) Homepage Journal
    Long ago, far away, I used to be a bit of a prima donna. Mostly wanted control, wanted to add bells and whistles no-one asked for, didn't comment to hide my stuff. Then it came back to haunt me and I was enlightened. Projects belong to users, do what they ask, turn it over, don't allow them to expect me to know everything about how it works (it's theirs, after all, look in the docs I provided) The best revenge for prima donnas is to give them what they want until the choke. The stress of maintaining their own code can be quite enlightening to the worst offender.

    Revenge, however, isn't very sweet when they leave and you're sitting there with a pile of arcane code written by someone in a fit of cleverness (which may actually be really, really badly writtend and/or inflexible.) Dealing with this on the current clock. Probably looked like sweet code to who put it together, but it's awful. Best thing to do is break the bronc, but not it's spirit.

    --
    All your .sig are belong to us!

  • by wrinkledshirt ( 228541 ) on Tuesday July 10, 2001 @02:44PM (#93360) Homepage
    One of the suggestions, to make a prima donna feel replaceable, makes me nervous. I think management's got to play a little more of a careful game than just bringing in new people to keep the current difficult ones in check. What it often does is send that same message to ALL the employees.

    At one office I worked with, I finally reached my threshold in terms of being handed additional tasks over and above my job requirements, and the way I ended up would probably tag me as a prima donna if my former manager looked at this article and shared it with the hr department -- I became somewhat aloof to the common good, and became a little harder to contact, but trust me, it was a defense mechanism because the harder I worked for her approval, the more I was congratulated and "rewarded" by being given additional tasks.

    To make matters worse, they already had the steady influx of additional talent that kept people in other departments paranoid about losing their jobs. It was an office of around 50 people, with 25 core people in the "replaceable" category, with close to a dozen additionals brought in each year. I'd thought that perhaps I might be immune to this because I'd already proven myself to be valuable to the office, but in the end, my complaints about getting too much work weren't really dealt with. They just hired a couple more people, and when I couldn't take it any more and quit, they just brought in someone else. A year later, now, the lower-level staff is finally getting close to getting a union together, but the revolving door policy that was put in place to deal with those who didn't fit in well had already taken its toll on many people who no longer work there.

    I guess the point is, if an employee is getting difficult, don't feel that a diagnosis of the problem the EMPLOYEE has is necessarily the first step. It might just have something to do with the environment. Yeah, you don't want one person terrorizing the office because of a lack of common good, but the complete opposite end of the scale can be just as bad, also on office morale.

  • by whjwhj ( 243426 ) on Tuesday July 10, 2001 @03:45PM (#93361)
    After 18 years of programming professionally, I've finally learned of tough lesson: Customers don't care so much about brilliantly designed and executed computer code. They want two things more than anything: 1) Willing compliance to their every wish, and 2) Timeliness. In other words, as long as your willing to do whatever the hell the customer wants and you get it done on time, you can deliver half-ass code and the customer will still love you to pieces. Brilliant code might be noticed and appreciated, but only if it's exactly what the customer wants and it's delivered on time.

    Which is a HUGE problem for us hackers in general since 1) we're likely to think we know more about what the customer really wants than what the customer asks for, and 2) customer's should be grateful they receive our masterful creations at ALL, much less on time.

    Bottom line is this: Although the skill and creativity required to create outstanding code is significant, it's real impact on the real world is marginal, at best. It doesn't matter if it's brilliant, really. It matters more if the customer was stroked properly.
  • Yeah, but God forbid he actually wins - then there will be NO dealing with him!
  • ... a techie Prima Donna to fix their dang website.
  • by Ayende Rahien ( 309542 ) on Tuesday July 10, 2001 @06:54PM (#93364)
    Have *you* tried reading code?

    Code is much more compressed than normal english.
    You need to keep a lot of things in your head at once, and a lot of stuff that you do because it's smart/improve performance/cool can make reading hard.

    Basically, the hard part about code that there is so much information packed into a single line. And you need to decode it, translate it to an algoritm, and re-tranlate it to code that works your way.

    --
    Two witches watched two watches.
  • I once knew a really nasty, bitter programmer who did good work, but played mean, disruptive pranks and talked about everyone behind their backs.

    Why? Because he was treated like absolute shit.

    In this company, he was the lowest-paid programmer, because he was the least "qualified," with no university degree. He was also the most productive programmer, and could do in days what other programmers would take months to do.

    They often set him to work debugging worse programmers' code. He knew he could do the same work in one tenth the code or less (in some demonstrated cases, a hundredth the code; replacing months of team effort with a few hours' work), and it took him much longer to debug their crap than it would to rewrite it from scratch.

    The management perspective? He was a pain-in-the-ass second-rate programmer, an example of why they should only hire "qualified" personnel. Presumably they didn't replace him because he had years of experience with their systems.

    He couldn't leave, because nobody else would hire him. He looked terrible on paper: most of his project experience was maintenance of failing software, he was never sent for the expensive and useless 2-day certificate courses the good programmers were flown out to every few months, and he never received a written commendation for the rabbits he pulled out of hats on the rare occasions desperation drove project managers to let him do things his way (after all, if he did it, it must have been easy). Just some debugging monkey, who never worked except under close supervision.

    I don't think his type is rare.

    Just look at job postings: "We need someone with a BS in CS, at least X years experience with language A and Y years with language B, a close familiarity with Buzzwordica and FAD-17."

    Those things mean nothing. I have met so many useless idiots who look great on paper that it makes me sick. Degrees are handed out to anyone who puts in their time and money, and they don't have to learn things if they don't want to. Having worked in certain areas does not mean having done useful work in those areas.

    The real killer, though, is the tendency to stick someone in a role when you hire them, and never move them, regardless of ability. That's insane, and very common. Promotions and demotions should both be common, with none of this creeping promotion based on time-in-role bullshit. People should be hired on a trial basis, and you should reject 4 out of 5 trial hires in the first month. That's the only way to get decent people, because the whole industry is messed up and no amount of "management" of incompetents is going to get good work out of them.
    --

Top Ten Things Overheard At The ANSI C Draft Committee Meetings: (1) Gee, I wish we hadn't backed down on 'noalias'.

Working...