I currently work on a team of people that are all PrimaDonna
s. Interesting thing is that they all know their own (and each other's) strengths and weaknesses, and have worked together long enough that ego is not a problem. The team is very productive, and is given the elite assignments in the company. Trouble is, though, that it is hard to integrate new people into the group.
So, what is a good definition of a prima donna, anyway?
If ego isn't a problem, they may not meet the colloquial definition, and almost certainly they don't meet the primary definition. ;->
- (n. slang) A temperamental, conceited person. One who considers oneself such a virtuoso that one's skills are too deep, superior and critical to waste working trivial details, such as mowing lawns or writing UnitTests.
- prima donna
- (n) (It., lit., first lady) 1. the principal woman singer; as in an opera. 2. [colloq] a temperamental or arrogant person.
-- Webster's New World Dictionary
"As soon as we implemented ExtremeProgramming
, we knew who our prima donnas were, because prima donnas can't survive in an XP environment," --DamonHougland?
uh, you couldn't tell beforehand?? -- PhlIp
Some signs you might be a PrimaDonna
programmer: note that several of these must be true; if only one or two is true, you're probably just a good engineer. :)
- Highly talented programmer, and know it. (Most PrimaDonnas are; after all a mediocre programmer who makes an ass of himself is generally not tolerated).
- Makes sure everyone else knows it too.
- Consider one or more of the following to be a personal affront (when applied to designs or code that you have created - the PrimaDonna is always happy to make suggestions - solicited or not - about the work of others): design reviews, code reviews, UnitTests, commenting, joint ownership of code, or even coding itself (see ArchitectsDontCode). One PrimaDonna I used to work with abruptly quit his job due to new management he didn't like. He was subsequently brought in as a contractor to assist his former team with finishing the project - he had quit close to the ship date. Upon returning, he was rather incensed to find that another developer, the most senior developer on the team remaining after the PrimaDonna had left, had added comments to his (uncommented) code. A nasty missive was sent out and cc'd to all and sundry proclaiming that his code had been "urinated" on, or something like that. The contract was soon ended after that, not sure whether by him or by the rightfully-pissed-off engineering manager.
- Have strong dogmatic opinions on all matters of technology (whether or not you are an expert or not), frequently dismiss as incompetent any who disagree with you on these matters.
- Have ever had the following phrases said about you: "He's a great programmer, but..."; "I'd love to have him on the team, but..."
- Engage in GoldPlating because you think the product definition team (which you may or may not participate in) is a committee of morons, who can't possibly know better than you what the customer really wants or needs.
- Often threaten to quit (or do quit) over technical disputes. (Quitting over working conditions, not getting along with the boss, or ethical concerns doesn't count - but many PrimaDonna's confuse their personal technology preferences with bedrock principles with ethics - see PersonalChoiceElevatedToMoralImperative. Many folks here on Wiki utter things like "use of C++ in a project is inherently unethical because C++ is crap". An AlarmBellPhrase, if you ask me).
- Demand perks or privileges outside the ordinary for programmers - especially those which are visible to others. (Arguing for a better salary doesn't count; demanding an office with a view when the rest of the programming staff is in interior cubicles does indicate PrimaDonna behavior).
- Hold most (or all) of the others in your organization in contempt (save for a select few whom you view as "enlightened").
- Dislike PairProgramming, as there is nobody in the department worthy to pair with you.
I used it to mean: someone who thinks they are indispensable, and who expects special treatment as a result. Not a team player. Thinks that rules don't apply to them. Thinks that the normal chain of command doesn't apply to them. -- DaveHarris
Ah! Americans. No seriously. We in the U.S. like to believe those things about ourselves. Sometimes secretly, sometimes not. You can make the argument that the resulting friction is counter-productive and messy, but it is advantageous at times.
I've come not to agree with the anonymous para above, though I might have in the past, and still cause friction often. Having worked in a well-functioning team environment that mostly works without high friction, I find it to be better than the well-functioning ones with high friction. The reason is that most people really don't work better under stress, and screaming at each other leaves at least one of the participants feeling rigid, stepped-on, unheard, or just plain pissed off. I wish that more techniques for effectively reducing friction came naturally to me.
Further, I've definitely learned that no one is indispensable, and if you have someone that you think is, your best strategy is to dispose of them ASAP. No amount of superior lone-wolf cowboy hacking will make up for breaking the build every week by releasing untested stuff on top of other people's work. Teamwork is better.
Most of the virtuoso stuff we used to do may have been necessary then, but isn't necessary now. Maybe we really needed to relabel pages out from under ourselves and drop into code in another page, or read a page from the disk on top of our code, or code 5 skips in a row. Today we need to make complex problems simple enough so that they can be solved in predictable time and cost. Oh, I'm still a PrimaDonna
, but now I'm sorry. ;-> -- RonJeffries
I don't think I'm indispensable, but I do think I'm damn useful and I expect allowances to be made for my eccentricities as a result.
People have called me a PrimaDonna
. Nobody's ever fired me though. -- WilliamGrosso
With all due respect, an interesting question might be whether an individual would be more or less effective if people didn't have to make so much allowance for his eccentricities. (Please allow for one of my eccentricities, which is drilling down on certain ideas.) -- RonJeffries
In any case, the answer is "I don't know." I think what comes to the fore when you ask such questions is the conflict between
- What is in the interest of the individual?
- What is in the interests of the immediate group that the individual works for?
- What is in the interests of the corporation employing the individual?
There are tensions there and, as Al Pacino said in TheDevil?'s Advocate
, "we're always negotiating."
I've often thought that had I exercised fewer of my eccentricities (or at least not identified my personal goodness with them), I might have done better. For sure, I can identify individual times when suppressing the eccentricities would have gotten me further along some particular path. Overall, my life has been so great, it's hard to imagine that a strategy change would really have been better. Today, however, as I look to accomplish this or that thing in a conservative organization like <name of auto company here>, I've noticed that it doesn't help to say things like, "I'm trying to look at this from your point of view, but I can't get my head that far up." -- RonJeffries
An amusing (to you, maybe, not to me) sidelight: no sooner had I saved this gem of support for the mild approach than MartinFowler
started a chat with me and ChetHendrickson
in which it came up that "many" people around the company think we come on too strong and that we come across like fanatics, etc.
We're going to kill the bastards. -- RonJeffries
That's only funny for its irony. Is XP a RunawayReligion
? Are you a methodologist
(ugh!) or a professional? Zealotry indicates you aren't listening, which says to me that your methods are failing. -- SunirShah
I'm currently working with a PrimaDonna
. The guy is smart, but unfortunately not as smart as he
thinks he is. He makes life miserable for his partner during PairProgramming
, and his style is uniformly confrontational, rather than cooperative.
The team is suffering. What to do? ParkingLotTherapy
? -- AnonymousCoward
, to protect the guilty
If and only if he is too dense to empathize with the rest of the team... assign him a task to do himself he can't possibly accomplish by himself. If he does it, bonus! If he can't, it will break him enough to admit he isn't clever enough to do everything by himself. Then have the whole team solve the problem. If you succeed, he might be humbled. If you don't, you're screwed. -- SunirShah
Sunir, thanks for the suggestion. In my opinion, however, that would be admitting defeat: I think this person does not, in fact, want to be part of the team. Taking him out of the PairProgramming
loop would essentially make him a team of one, and then we'd have to maintain his code. The reason
we do XP is so that we can see each other's code as it gets written!
I'm hoping he will soon be removed from the team by peaceful means (i.e. "promoted" to some "more important" position). It still burns me, though. -- AnonymousCoward
Breaking him is actually a terrible solution. Usually after horses are broken, they are sold for stud because they are functionally useless. As for XP. Well, it doesn't matter what XP says. You won't have to maintain his code if he fails. Just delete it and rewrite it as a team. But then, you will have to transfer him out of the team because that kind of insult would be a little too much to heal.
Try reading When your Star Performer Can't Manage
in Harvard Business Review, July-August 1997. But that suggestions there aren't likely to help you much. Most deal with the ignorant CEO, not the egoful engineer in question. One suggestion I liked, though, was to find him a mentor either inside the company or elsewhere that could coach him through dealing with teams despite his soaring intellect.
Really, the point is to show him that he can get more done dealing with other people than by himself. Then again, if he really can get more work of higher quality done by himself, perhaps your team really is dragging him down. That can be legitimately frustrating. In that case, you should ask yourselves what's wrong with the team. Perhaps you don't have a good enough mix of talent.
I don't mean to insult you. Just trying to help you avoid jumping to blame without any reflection. -- SunirShah
Sunir, there's definitely no insult taken. I've thought about these issues deeply. The team is small (five) but quite talented, IMO. This guy is the best one from a purely technical standpoint, but no higher than 3rd in domain knowledge. He clearly needs to cooperate with us to be able to function productively. He joined the team half way through project, we were well on our way and productive. He is definitely not
indispensable. He's smart, I'm sure he knows
he's not indispensable.
The fundamental problem, I think, is he does not share our (the rest of the team's) core values - i.e., business value first. He gets into terrible fights about "technical correctness". But if the tests are passing, aren't his "better", but more expensive (in time) solutions a conceit, a luxury? As team leader, I have to explain to management how I spend their money (i.e. programmer time).
I know I sound like I'm whining, but I feel that there just isn't any good solution out of this. Thanks for listening, though, it does help me think things through. -- AnonymousCoward
Thinking more about this. Have you talked to him about this? If he really doesn't like the team, it's best to let him go. But if he wants to keep his job, then he might be willing to behumble himself. I really should have looked at the the http://usemod.com/cgi-bin/mb.pl?ConflictResolution
strategies first. Apply
- Assume good faith
- Ignore malice
- Name the conflict
- Open discussion
- Superordinate goal
- Change the people
(although at the time this was written, those haven't been detailed; sorry.)
If you sat him down, pointed out how disruptive he's being, described the team's goals to him (i.e. BusinessValueFirst
), said what you expected of him (http://usemod.com/cgi-bin/mb.pl?PygmalionEffect
) and asked him if he was willing to take a mentor to coach him into the team culture, maybe that would work. Ask the person you most respect on the team (other than yourself!) to if he or she was willing to mentor the PrimaDonna
Note that when you sit him down, you shouldn't tell
him what you expect, but discuss
the difference between what your goals are and what you perceive his goals are. Remember, assume good faith
! He might be trying to do the best job he can. He might just not agree or understand your philosophy.
If you can agree there is a difference, and you can make him agree to at least try to understand your philosophy, then the world would be a better place. The team would have its programmer (instead of a severance penalty), the PrimaDonna
would learn The One True Way, and maybe
you'd ship. ;) -- SunirShah
Perhaps the problem is your "well hell, the tests are passing, so why spend 5% more effort doing it the Right Way?" philosophy, not the perfectionist programmer who finds himself disgusted by your trench warfare programming culture?
Not saying you or your team is the problem at all. I happen to feel the problem is a larger one than all of us, and it boils down to the inadequacies of the primitive tools at our disposal. I mean, when you write code in a so-called "modern" language like C++ or Java, this isn't "engineering" like building a bridge is engineering. Not even at the highest levels. The whole "testing" methodology as a means of ensuring software reliability is a joke. Don't believe me? Wait 10-20 years and watch as these primitive methodologies are exposed for the buggy whips and wooden spokes they are.
It is a basic fact of psychology that our surroundings dictate our comfort level and our attitude. When NYC cleaned up the graffiti from their subway system in the early 90s and started cracking down on petty crimes, violent crimes plummeted city-wide. Likewise, I'm fully capable of programming in a language like Lisp, a language whose ideas I greatly admire. The problem is I would never touch the language EVER, because I am that offended by its over-use of parentheses. Same thing goes for Python with its mind-numbingly stupid idea of using spacing as part of syntax. Don't get me started on C++.
Other programmers are content to use these languages despite their flaws. I cannot. Once I see too many flaws in something, I simply cannot bring myself to waste energy on it. I would wager that everyone in the world feels basically the same way, if they really broke things down and thought about it. The only difference is in the strictness of our standards. Think of how off putting it is when you're working on some crap SpaghettiCode
. That's how I feel x1000 when I look at some C++/STL genericized multiple inheritanced cluster fuck. Not touching that with a 10 foot pole, for any price. No thanks guys. I'd just about rather shovel shit for a living.
You might say I'm an over-perfectionist; I would say you fail by settling for mediocrity. You say I'm a poor team player; I might say you don't understand programming. You know that poor, average, and rockstar programmers exist; I know the reasons *why* they exist, and how to fix the problems you don't even realize exist. I could never hold a job as a commercial programmer, working for someone else on some broken language on someone else's horrible design. I basically HAVE to be the boss of my own company in order to be happy.
I would wager a lot of these other guys you are having problems with, are unhappy for the exact same reason, whether anyone realizes it or not. They were born to lead; not follow. The problem is our society provides absolutely no help or training or information to encourage people to "go it alone". Nobody is taught how to lead. Instead it's all about how to be a cog in the machine, how to follow orders, how to compromise and accept the status quo. There are those of us who are simply genetically incompatible with that way of thinking, and being in such surroundings makes us miserable.
The real solution: put this guy in charge of something. Try *encouraging* him for a change...and watch him soar.
At least that's what the way I see it.
PS: I find it interesting how this talk about "talking" with the guy you're having problems with, all revolves around the idea of getting him to see YOUR point of view. Never once have I seen you or anyone else responding here expressing interest in finding out HIS point of view. Why is he upset with and conflicting with your team? There is a reason for everything. Maybe he has some valid concerns. Why are people always so concerned about suppressing someone who speaks out, rather than listening to what the guy has to say and reasoning about it before you dismiss him as a troublemaker?
, as I call them, make sure everybody already knows his PointOfView
See also: HighMaintenanceEmployee