Slashdot Mirror
How To Deal With (Techie) Prima Donnas
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.
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).
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.
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.
-- I am not a fanatic, I am a true believer.
In a nutshell, the article offers these solutions:
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.
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? 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.
Easy, automatic testing for Perl.
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!"
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.
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.
How we know is more important than what we know.
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.
.... um, i lost you after "0110100001101001".
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
"The difference between theory and practice is small in theory and large in practice..."
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!
Feed the need: Digitaladdiction.net
- 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.
- 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.
You need people like me so you can point your fucking fingers, and say "that's the bad guy."
Management calling good coders Primma Donnas always gets on my nerves for a variety of reasons. Many people (including Phil Greenspun) 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*
--
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"
"Science is about ego as much as it is about discovery and truth " - I said it, so sue me.
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!
---
---
the pen is mightier then the sword. the sword is mightier then the court. the court is mightier then the pen.
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 :)
"Anybody who tells me I can't use a program because it's not open source, go suck on rms. I'm not interested." (LT 2004)
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:
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.
-- .sig are belong to us!
All your
A feeling of having made the same mistake before: Deja Foobar
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.
--------
Bleah! Heh heh heh... BLEAH BLEAH!!! Ha ha ha ha...
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.
... a techie Prima Donna to fix their dang website.
'Same speed C but faster'
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.
--
Two witches watched two watches.
Which witch watched which watch?
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.
--