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.
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.
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
It's a strange world -- let's keep it that way
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.
---------------------------------------------
Recursive: Adj. See Recursive.
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.
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.
-no broken link
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.
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.
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.
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.
Your pizza just the way you ought to have it.
No wonder the OfficeXP warez that I snagged was 3 fscking cd's!. Oh wait, he said 'better', not 'more' :)
Endless arguments over trivial contradictions in books written by ignorant savages to explain thunder in the dark.
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.
--