On Being Quite Unprofessional
Sarah from Monash posted an interesting essay on being professional, to which friend "Tony" mocked her knowledge of SQL. Here is my full response to "Tony".
Part of professionalism unmentioned by Sarah is something that makes programmers uncomfortable and this is that interprofessional solidarity and courtesy, seen amongst lawyers and doctors, that makes the professional assume that another professional is, as a member in good standing, "innocent before being found guilty".
That is: something that annoys people outside the law and outside the practice of medicine is the way in which lawyers will BY DEFAULT speak well of another member of the bar.
People outside these professions take this prima facie as evidence of a City Slicker conspiracy against Good Honest Plain Folk and at times it is...other times it is not.
But most working people, including programmers, lack something that Sarah I am afraid fails to mention, something beyond the control of the programmer, and within the control of the lawyer/doctor: the ability to say who is and is not a lawyer/doctor/professional.
This default protection of the career, which is of course taken away by the peer group in the case of proven malfeasance or misfeasance, gives the boys and girls in the Doctor Hut or the Lawyer Lodge their ability to by default speak well of each other. Generally speaking, it makes it possible for them to manifest at least some of the qualities, including self-education, that Sarah mentions.
I also noticed this at Princeton. Since "getting into Princeton" is so hard, the community tends to accept you without trying to find fault. That's why they gave John Nash the run of Fine Hall during his delusional phase. To be accepted, by default and until proven otherwise, as something other than a Chicago computer consultant in it for the money, was for me refreshing to say the least.
In an artisanal trade or job, Job One, from the interests of the tradesman or employee, is staying employed...usually by assuming the REVERSE of what is assumed by the "real" professional, that his mates are screwups.
Comes now the Tony man to insert something of what I speak, and this is his sarcasm concerning SQL.
Note that he's made what I call above a default assumption, to wit, that most programmers, whether or not they have a Web site, or have written a frigging book, or have coded a compiler, or have won the Nobel prize or invented a cure for cancer, are PROBABLY ignorant and defective characters.
As a cultural meme this is probably a subclass of Baby Boomer self-hatred, filtering down into Generation X, in which overconcentration of economic power teaches people that they are second-rate shop-soiled goods by default and until proven otherwise, in exhausting on the job handstands. It pisses me off, because as a result, wealth and power are today overconcentrated in American life, Bush is President, and Social Security may be destroyed...all because my generational cohort can't stand up for itself, or for its fellow human beings.
But in a highly competitive society, this is what the employee class DOES. It is forced above all to "compete" all the time, whence the eagerness in programming and the other paraprofessions, to establish one's bona fides by trashing another in a zero sum game.
Too often, especially outside universities, "I yam a great programmer" is established not by actually sitting down to CODE (for that would raise the interesting question as to why you didn't find or steal some tool) but by trashing the reputations of others by seizing on specific sound-bytes emitted by one's victims, and putting the WORST possible interpretation by default on that text.
Now, it is not the case, of course, that lawyers and doctors never do this. They will indeed turn on a member who is disfavored and expel her from the loghouse with that savagery which characterises humanity as such.
But they DO so, generally speaking, only after knowing some facts about the scapegoat, not as a default operating assumption.
In a mocking tone of voice, "Tony" here says "keeping up to date by learning SQL" as a default, knee-jerk gesture that's familiar among programmers, who in our economy are forced to "compete", and set thereby each against the other in such a way that they have to be sent to "teamwork" classes at the age of fifty and beyond, who as a result of an economic brutalization ever-present are like King Lear, old before they are wise.
The fact is that you better learn SQL every year, because absent a frozen SQL, SQL considered as a real language KEEPS CHANGING.
"You've got some bigger issues". Nice: the snap judgement, the snap put-down, on someone who knows her trade, but whom "Tony" must perforce trash, taking a few seconds out from his busy schedule doing 1974 vintage SQL and honking through snapshots while the data merrily changes on the server, because in the zero sum tradesman game, there is no PROFESSIONAL committment to the advance of knowledge as a whole, no sense that there might be a need to relearn SQL, perhaps to write a book about "How to Know SQL Independent of Microsoft and Oracle".
Hell's Bells, you can't "know" SQL in Head Hunter Land, because the Hunter of Heads wants an ORACLE guru or an SQL pundit.
I'm afraid as against what Sarah said that owing to factors that are well beyond the capabilities of individual programmers to redress, at least in the USA (Sarah writes from Oz), programmers are not professionals in the sense that no protection is given to the truly skilled programmer (who uses SQL Server and Oracle with equal facility, who is a team player because she's a Good Person, not for any selfish reason, and who does the dirty work with a smile, like, I can well imagine, Donna Davis, who even puts up with me from afar).
If it so suits the company, she is unprotected against the Tonys of the world who snigger in the back of computer classes, alternatively and as it suits them when the instructor recommends they learn what they think they know, or when the instructor actually knows something they do not, which is of course "academic" and "useless" for the oh, so studly Tonys of this world.
Isn't it.
Professionalism demands self-respect and self-esteem, the sort which Sarah exhibits and Tony does not, any more than the poster to the Apress Web site who posted one word in response to my announcement of the package for MS-DOS commands, that being "idiot".
[I won't post at Apress any more until its Web mistress does something about the spam and garbage at the site].
I am very glad to have button-cute Chinese children up to university level breath Goat Flu on me while I help them get into Princeton because I no longer and at long last have to sit in a lunchroom hearing boy wonder programmers snipe at each other, for knowing something they don't, or not knowing something they think they do. And hats off to the Donnas and the Sarahs of this world, wimmen who learn their trade and teach it to others. They are the real pros.
"Tony" was an idiot
He was so completely a troll, as previously mentioned, and your comments about SQL as an evolving language were 100% correct.
I've known and worked with SQL for a number of years now, and I'm still learning lots, as I've just moved into a shop that is mostly Oracle, and my background is in M$ and MySQL. Also, we have plenty of programmers here who wouldn't know a SELECT statement if it smacked them in the head, so the idea of someone being a programmer, or a coder, and not knowing SQL is entirely plausible. In larger shops, this kind of specialization yields higher-quality software. UI designers, for the most part, could care less what gets them the data, and that's fine with me, as they just need to work with I/O.
Good for us that we can't all be like "Tony".
Specialization and SQL
However, even UI designers need to know the physics of SQL, because when the rubber hits the road, their misdesigned calls can bring a network to its knees.
I am referring to client-side elaborate calls in code rather than stored procedures, and/or the "structured" splitting of an n-way Join where n>2 into a series of 2-way joins.
SQL may have arisen from an inability, strikingly common in my experience, to code a two-way sequential match merge algorithm correctly in the era of tape, and sequential disk, files...coupled with a perception that an n-way join, where n>2 or a parameter, was rocket science.
In my experience, the inability was based on a failure at the time to disambiguate the concept of a set from that of a list.
I've made my own share of SQL boners. In the 1990s I proudly constructed a five way join as client side code. It was as such optimal and correct: but, as my homey Sundar pointed out with that courtesy I have always received from India developers, that I was hosing the network, and I needed to make my nice join into a stored procedure.
It is a programming gesture to specialize, and dismiss entire zones of technical culture as deadweight. But my experience with SQL was that you need to know the history of tape, and early disk, processing, you have to know why C. J. Date is so smart, and you have to know modern network "physics". You have to listen to your homeys and you have to advise others without bitch-slapping them, metaphorically or in reality.
Otherwise, the culture of coding fear obtains, in which we each lurk alone in cubicles using our favored method and expect the whole thing to come together. Which it doesn't.
Amen, SQL Brother
The nice thing about SQL is that some flavor is persistent through the years. I don't see how you can walk across the street as a programmer without some understanding. However, folks are graduating (and interviewing for positions, ahem) every day with very little grasp.
Having said that, I amen Mr. Nilges' notion of sharing the wealth. In Software Conflict 2.0 Robert Glass says, "There are enormous differences between software developers, ranging in magnitude up to 30-1." This has been very true in my experience and sometimes as the coworker or supervisor of someone on the low end of that spectrum, you are tempted to throw out the baby with the bathwater. Cut off that dead weight like a diseased limb. Yet, I try to remember (and still can, when I strain) how relatively clueless I was during my undergraduate years and shortly thereafter. I know what I do today not only from my own digging, but from senior coworkers taking the time to explain something that was blooming obvious to them. I still remember the uncomfortable feeling of having to ask for help...and as such I coach our senior staff telling them they are *expected* to train and encourage the junior staff. It's a way they show their leadership and team skills. I tell junior staff they are *not expected* to plop their problems in the laps of senior staff to fix for them, but are encouraged not to struggle alone. They are resources for them.
Of course the trouble is this: At the end of the day, one can pretty much tell who has the potential to be a 30 and who is going to languish in the low digits their entire careers. Sometimes we have had the uncomfortable task of reassigning a programmer to non-programming work when years of training attempts demonstrated that their talent was elsewhere. The high-end programmer tends to grow weary of the sustained expectation to "prop up" a coworker who just doesn't get it.
Back to SQL: Just this week I emailed a "SQL Challenge" to my group after one of the programmers asked for help on some particularly difficult syntax. I knew it could be solved more than one way, but the variance in responses was astounding. Trouble is, like Mr. Nilges said, many folks are happy to settle for syntax that executes, never pushing further for syntax that executes most efficiently.
30-1
This variance in knowledge and productivity has been remarked on for a long time, Donna: thanks for mentioning it.
The question is why it exists. Wouldn't the 1..10 people have long been removed from the profession?
The easy answer is that there is such a "demand" for programmers, but this rings hollow. In fact, and in my experience, this big "demand" has deflated like a balloon in every US recession.
In 1970, Time/Life in Chicago was paying high school dropouts as programmer trainees. But when I graduated in 1973, I was informed that programmers were a dime a dozen, and even if I got a haircut, with no experience I could not get a programming job, even as a trainee. I was sent to an interview as a mainframe computer operator at Rusty Jones.
[Big future there. "Rusty Jones" and Zeibart were flourishing at the time because American car manufacturers saw no point in permanently rust-proofing cars, as did the Japanese, by dipping them in electrically charged paint, which would bond the paint to the car such that rust would never be a problem. Fortunately, I refused the interview.]
No, there is no big "demand" for programmers. Instead, management in America has always been willing to pay a certain premium to white collar labor, and to sacrifice raw productivity, for CONTROL: cf. Harry Braverman, Labor and Monopoly Capital.
The very idea of a programmer who knows his trade admonishing another is therefore under something of a cloud, and typically, in my experience, the experience and knowledge of a truly qualified programmer is seldom input to the human resources evaluation process.
It's replaced by something more slippery, the peer group's least common denominator opinion of the person in question.
From this LCD opinion, anything specific is removed. Some of the programmers may write stored procs with n-way joins where n>2, but usually, too many loyal and obedient employees avoid this practice because of anxiety and uncertainty.
Furthermore, Personnel wouldn't understand the issue.
Either removing nonproducers, or improving their productivity so that the range is 5-1 rather than 30-1, is NOT something that can be done by quarterly performance reviews. Instead, it's done in a group of people who have a group identity and group solidarity, as in certain Extreme shops...and, in machine tools, in UNION shops.
A characteristic of these shops is the fact that the mutual evaluators have self-esteem and self-respect based on job security, including formal procedures for termination which management cannot bypass.
Of course, American white collar jobs are dominated by "employment at will" where the programmer can be terminated "for a good reason, a bad reason, or no reason at all". In this context, the employee may very well afraid to disclose (by asking questions) her ignorance of some aspect of SQL: she may be afraid of a sudden "flame" on the corporate intranet from a "Tony" who mocks her for not knowing something "we" (the regular guys) already "know", and under employment at will, this "flame" can be the bad reason, or nonreason, for terminating her...for her apparent ignorance (which Personnel, and her manager, takes at face value from "Tony") or for briskly firing back at "Tony".
I noticed in Red China that these games don't occur. This is because while it is rather easy for a modern Chinese manager to terminate, the law does state that it has to be for some sort of good, and documented reason. The result? The language translator was done on time and it worked, because new employees were brought up to speed rapidly on the right way to parse by employees unafraid for their jobs.
I conclude that the productivity "gap" that Donna mentions is strictly an American artifact, in which nonproducers aren't encouraged to improve, instead to work mega-hours while being very loyal to the system of management control.
Their code, after all, eventually works, same as classy code. Upper management really doesn't care that it uses bad techniques. If it's slow, we can buy faster hardware or up its priority.
I conclude that programming, unlike skilled, blue-collar labor, necessarily includes helping American management Manufacture Consent to unilateral control.
The American sociologist, C. Wright Mills, saw this in 1954. In White Collar, he shows how the rules are very different for the white collar employee (whether skilled or unskilled) than the skilled and unionized blue collar. As part of management, the white collar of 1954 had by dress, deportment and speech always to assert a narrow spectrum of values, centering around the virtues of competition and the wisdom of managers. It's the same today.
Sure, you can be a "bad boy". You can wear countercultural symbols. But if you're a badass, then you have to spread the mythos that your tech skills are unique and irreplaceable.
Oops. As soon as you do this, they are also "proprietary".
Management uses this buzzword, "proprietary" with even more sloppiness than it uses other tech buzzwords: I once had to listen to a manager say "don't talk to me about C++! It's proprietary! We need to stick with VB!"
Because (as Braverman shows) management control is ultimately more important than "efficiency" or even "profit", the game is universally (as Phillip Kraft pointed out in 1978, in his study PROGRAMMERS AND MANAGERS) "deskilling the deskillers": once the programmers have gotten rid of the proud and skilled nonprogrammers, as much as possible, by forcing the truck drivers to drive premapped routes, the programmers themselves are fair game.
This is the reason for the productivity gap. There is no need for the higher producers in the long run.
This is a dark and tragic vision. It's why I am teaching law, computer science, history and English in China, and not programming. But there is a chance of a happy ending.
I did remain in the programming business far longer than most programmers: more than thirty years. I did so by continually reinventing my skillset, from assembler to Cobol to C to VB to C++.
Despite Braverman, there were real challenges because human beings can make meaning in work where no meaning exists: Hegel, who was a deeper thinker in some ways than Marx, saw our need for pure Recognition as more fundamental than material survival.
Although in the long run, management doesn't care about Code, it is still an excellent joke, an Hegelian jest, when in fact they need you TODAY, for example to reengineer a telephone accounting system to an accurate version that simulates the entire goddamn switch in a table driven state machine.
In fact, were it not for the fact that Hong Kong programmers need for the most part to speak both English and Cantonese, I might even have gotten some sort of fun coding job in Hong Kong.
Coding is delightful, coding is fun, coding is sweet agony. If I could afford a replacement for my totally smoked Vaio I would be coding instead of writing this (and, Dan, in view of our readers' response to the MS-dos thing, I need to get back to coding for this forum).
But, I need to wait until I can afford a new laptop. I can get a second hand job, buzzing with Chinese viruses, in the Chung King Mansions, but I am not up to that. Should happen in a month or so.
30-1 is nothing new
I'm of the opinion that the 30-1 ratio of run-of-the-mill (or possibly useless) workers to 'real', highly-productive workers is not unique to programming. As is typcial for me, I'll go back to a couple of previous jobs to support this.
When I was ran a shovel for a living, there were always 1 or 2 of us that did the bulk of the work. Correct posture, thoughtful technique, and good pacing made it possible to do 5-10 times the work of anybody else that stayed the course and at least 20 times the work of anybody that we found other work for. Believe it or not, the top shovel-jockeys actually discussed and compared techniques and you could tell who was destined to become a '30' by whether or not they were willing to learn something. Most people thought that discussions of technique were more than a little ludicrous--it's just a shovel, right?.
When I was a welder, I was again in the '30' zone with a rate of defects that rounded nicely to zero (.5-1 per 100 welds in a field where 15-20 was the norm).
When I was a trucker, I was solidly mid-range. I could do as well or better than a lot of my collegues, but I certainly couldn't back up a train of 4 pups, something that a guy hauling for Sears did so nicely that you'd think it was the easiest thing in the world. He was defintely a 30.
Now I'm a programmer. Or at least I call myself one. I love this job better than any I've ever had, but I'm nowhere near being a 30. I hope that I'm not a 1, but I certainly wouldn't put myself higher than 5 or 6. I have fun, I keep pushing to learn more and get better, and the software I write has become indespensible to my employers.
We can't all be 30s, but the 30s can bring the 1s up a notch or 5. Once my employer realized that I was a '30' welder, they made sure that I never stayed on any single gang for more than a few weeks. By the time I'd headed up a dozen crews, we had a whole region running with a defect rate of fewer than 10 per 100 welds.
I think that the key to identifying 30s (and 1s!) is measurement. I could never have been identified as a 30 if there weren't lots of measurements. Managers want to know how to identify the great ones, the good ones, and the useless ones, and it's up to the 30s to figure out how to perform the necessary measurements.
I think the key to getting rid of the 1s is to turn them into 5s. I suspect that programming is like most other human endeavours in that a few fundamentals carefully mastered make the difference between a 1 and a 5. If that is true, then proper training, mentoring, and support will create enough 5s that we can get rid of the 1s. Of course that means we end up with a 5- or 6-1 ratio, something I think we can all live with.
Mentoring in Action
Great post, Ron--and this is a great thread overall, surely a Top 10 thread on this site (a rating system I just now made up). I think managers everywhere should read this whole thread.
I also wanted to comment that this is a great anecdote illustrating mentoring in action:
We can't all be 30s, but the 30s can bring the 1s up a notch or 5. Once my employer realized that I was a '30' welder, they made sure that I never stayed on any single gang for more than a few weeks. By the time I'd headed up a dozen crews, we had a whole region running with a defect rate of fewer than 10 per 100 welds.
Ron, I would love to hear more about how you managed to have such an effect on each of these crews. How do you correct the mistakes or refine the techniques of your crewmates without making them feel like you're micro-managing their work? Or was it more leading by example? Did the boss set you up as someone others on the crew should listen to, giving you a mentor's "posture," if you will, with the rest of the crew? Or was it more subtle?
Also, Ron, on the topic of measurement, you might enjoy Quality Software Management, Vol. 2: First-Order Measurement by Gerald Weinberg. Not a cheap book, but worth it. I personally, though, have never worked in a shop with a comprehensive and ingrained measurement program/culture. I've always had to take other people's word for it that such a thing exists.
Thanks,
Dan
How to mentor a welder
1. Be willing to stand up to people higher on the org chart. This can get you fired unless you have either a high-level sponsor or a combination of official, documented processes and a union. I got the attention of a sponsor because there were official processes and a union (translation: I had an attitude problem).
2. Be willing to suffer the ridicule of your co-workers. Once again, we have the attitude problem. This one, at least at the time, was physically dangerous. Your co-workers won't fire you, but they might arrange for a beating (literally!). I'd like to think that beatings are a thing of the past, at least for me personally. (And people wonder why I prefer to work solo!)
3. Do the job and keep accurate logs for everything in sight, not just your own work. Criminy, there's that attitude problem again :) Eventually, however, people start to get it and word spreads, thus simplifying things as you move from team to team.
I'm not sure how much of this is directly transferrable to mentoring in other kinds of jobs. There was a lot of screaming, physical intimidation, and the people with the power to do something about it were often halfway across the country. Some things just don't translate all that well, and I find that my 'attitude' is quite a bit different without the backing of documents and unions.
Thanks, Ron!
You tell it like it is, Ron.
Led me to respond with Mentoring is Kids' Stuff.
Thanks, Tom
Thanks for the pointer to your post and blog, Tom. Good stuff. I've added your blog to my RSS reader.
Best,
Dan
Welders, chemists, programmers
I agree with Ron, wholeheartedly. My husband, a chemist-turned supervisor, deals with the same thing. While my experience is limited to the USA, I also find it difficult to believe that it is a distinctly American problem. It's a human problem. I would add that as far as firing people on a whim, in all my places of employment (under normal circumstances) one had to have a trail of documentation (and just cause) before firing. I say "normal circumstances" because if the company is downsizing or a merger is taking place then that, in itself, can be the reason. It was during these times that I saw the dead wood being severed.
The challenge for me is finding ways for the lower performing folks to contribute effectively. If we were only talking about newcomers, that would be different, but unfortunately, some just don't transition to the new technologies well. Then you are dealing with a "good" and "loyal" employee who shows up on time, doesn't call in sick, deals well with clients, but just can't program worth a doodley. The thing to do, then, is to transition them into project management or some related discipline where they can put their experience to use. Trouble is, sometimes these same folks don't like project management, or documentation, or the various other duties that come with the profession.
I also would add there seems to be a sentiment that the developer's supervisor (the one conducting performance reviews) is oblivious of the day-to-day work of staff and is completely unable to administer an accurate performance review. On our team, we conduct project reviews in our staff meetings and I must say that is pretty obvious who is producing and who isn't.
Performance Metrics, Etc.
In small to medium sized teams, everyone pretty much knows who's a producer and who's not. But it is hard to have a reliable metric for measuring the productivity or proficiency of a programmer. Management lacks the technical skill or time to know who writes good code and who is a hack. And developers don't like to rat one another out or they are simple loudmouth knowitalls that smart folk know to ignore.
You can set up a peer review/rating system in which developers review one another's code and rate them for management, but that's pretty subjective, isn't it?
One solution that's pretty heavyweight it to require all development to have an associated issue in your issues tracking system--whether it's a bug fix or new development. Then you can track developers based on how many of their issues went to a failed status or how quickly they were completed. But then this assumes that all issues in the system are equal, and that would be impossible. Is fixing the text in a column header in a report the same as developing a new rules engine? Both might be represented as a single issue.
What to do with those who don't measure up? Well, as I mentioned in another post, the world needs bolt tighteners. Give them the cruddy low-level tasks you don't want to do.
Still, I suspect that in most cases, when a developer does not perform to expectations, there is a management problem at the root of it. Has the developer recieved the training required? Has he been given too much responsibility or automomy too soon? Has he been given reasonable requirements and processes so that he can complete his work?
But if the fit is just not there, people can be "let go". It is good for management to keep a thorough paper trail in such cases. The reason they do so is, regardless of the requirements of the law and the fact that much of the USA is "right-to-work", employers are scared of being sued. And that is as it should be. Fear of being sued often prevents corporations and other employers from behaving badly.
Of course, (my old hobby horse) this is why there are so many who would like to see the right to sue restricted or even eliminated.
Performance "metrics"?
First of all: the right to sue for job termination outside of collective bargaining agreements and protected EEO categories (OTHER than age) no longer exists. I thought I made this clear. USA-wide, job dismissal may be for a good reason, a bad reason, or no reason at all, and the employee is wasting his time if he is not a union member or a member of a protected racial or sexual category, assuming that he has the financial resources to sue, which, of course, many employees do not.
The image of America as lawsuit happy is an Urban Legend. Sure, the absence of protection for consumers and employees means that in cases of egregious unfairness, the courts will be used as a "last resort", but how many people do you know have sued for termination?
Not many, I am willing to bet. Furthermore, to do so renders the ex-employee a radioactive malcontent who is abandoned by his former coworkers, so all those people actually suing in defiance of employment at will are an unknown form of radioactive dark matter.
Furthermore, the perception that there are nonperformers on the team is logically based on global software nonperformance: late deliveries, the inappropriate use of packages (such as "graphics" packages) to do overly simple tasks, and hidden agendas. The very idea of a nonperformer is a REIFICATION of the bad conscience of software and that it has taken programmers fifty years to get their act together.
In an effective team, no time would be wasted on individual performance metrics, for two reasons. The first reason is that in terms of hard and ethical science, "measuring" the performance of intelligent agents who either know or suspect they are being measured creates Heisenberg uncertainty in the large, at the level of microsocial research: yet while a responsible physicist states that an electron "is" a cloud of probable locations at any one time, managers and their programmers persist as if a programmer's numeric "productivity" could be a known integer.
The second is that individual productivity doesn't matter, only results.
[My productivity was in the range 25..30 when I reengineered a Cobol program to simulate a switch. A month later, my marriage having been wrecked by an undecidable combination of my defective character and my wife's untreated and undiagnosed post-partum depression, my productivity was in the range 0..5. So what's my "real" productivity?]
Here's my "Turing" test.
If a programmer knows what a Turing machine is, he's probably a great programmer and can learn Java overnight. If he doesn't, there's the door.
Non-performers
I'm sorry...I hate to dispute...but I must say I have worked with non-performers who were provided all the training and coaching one could cough up. Coworkers acted as mentors but the person(s) lacked the aptitude to connect the dots, despite the fact they had worked in the profession for many years. I'm not talking about someone who is capable but just doesn't put out. That sort of person can be prodded. The kind of person I'm talking about would eventually produce something...and it worked (minimally) but if you looked under the covers, you'd be horrified. To say that managers don't know enough to tell good code from bad...where do you think managers come from? I, for one, haven't kept up enough to be able to whip out a great system in .NET myself on the spot, but I have some idea what to look for. Ideally one has "technical leads" and certainly they are in the trenches all the time. I think over-measuring distracts good people from the goals at hand; however, there needs to be some mechanism for rewarding those who deserve to be rewarded AND ensuring quality. If you have quality assurance measures in place, the obvious programming flaws (and programmers) will present themselves. In the past the "buddy system" was such a problem that I believe the move to metrics was an attempt at fairness and objectivity.
I trust that Mr. Nilges is correct about labor law (knowing how intelligent he is about many subjects), but that doesn't mean some corporations and government do not make some effort at "fair and just treatment," (whatever that may look like). I don't see how one can describe the *entire country*, with one sweep of the keyboard, as falling squarely in the same bucket. I don't believe every American (by virtue of our nationality) is exactly the same flavor as we are often portrayed.
However, I am delighted by the Nilges/Turing test because I pass! I can also testify that he is probably right...the nonperformer mentioned above would not have passed it. Yet, I know some good developers who apparently don't read much or care about history who still seem to have their acts together.
Sue You, Dude!
Fear of being sued absolutely does affect the behavior of employers, though Edward is absolutely right that such lawsuits are unlikely and even more unlikely to succeed for the reasons he points out.
However, I do know of someone who did sue for wrongful termination, and in Florida, no less! This was a special case because the employee in question actually had a contract and the employer egregiously violated the contract for their own nefarious purposes. It got extremely ugly with the employee in question falsely accused of every disgusting act imaginable. Yes there was a lawsuit and a quick settlement for not nearly enough money because the employee in question and his/her family were not willing to get nearly as ugly as the employer was.
Of course the only reason they got so ugly was because of this contract. Otherwise they would have just fired the guy/gal. (Yes, I'm going to great lengths to maintain anonymity.)
As for age discrimination, you can still sue for that. But, thanks to a lawsuit lost in the Supreme Court of the USA by my father in law (no, I am not kidding) it is an established legal fact that you cannot sue a state (he was a professor an a state university) in federal court for age discrimination. Private employers can still be sued, however.
[A Nilges-like aside here. One of the grounds for the Supreme Court finding was that states enjoy sovereign immunity in Federal courts. This is a bizarre concept and is nowhere in the US Constitution, oh you strict constructionists. That document, but beginning with the words "We the people" makes it quite clear who the true sovereign was supposed to be.]
Regardless of all this, it's been my experience that in most organizations it is very difficult to get fired for cause. Getting "laid off" because the company wants to show better profits is another matter entirely. Getting fired because someone thinks you're not performing, that is very rare in my experience. I've only seen it happen twice, and in both cases, the non performers (oh, I had to agree with management here) were given a year or more to get it together, but they just didn't have it in them.
One of these two was a writer who simply could not think for herself. If I told her exactly what to do, she could do it fine. But she could never apply the same lesson to the next problem.
The other was a developer and he was just the nicest guy in the world. I really liked him a lot on a personal level and so he often came to me for help when he couldn't figure something out (several times a day, this was). He even praised me as a guru (though I had very little experience at the time). Sadly, the guy never learned anything and he just could not cut it no matter how much help he got.
As for me, Edward would have to show me the door. I could look it up easily, and I've heard the term many many times, but I couldn't tell you off the top of my head what a Turing machine is. So much for metrics . . .
Age discrimination
The problem with age discrimination is that in the heyday of fair employment, the 1960s, employer organizations lobbied Congress to ensure that a wide class of "bona-fide" reasons could remain by means of which an employer "in good faith" could fire an employee.
These exceptions were used to establish, in the 1990s, that a fat guy with a hairy tummy could not get a job as a waitress at the Hooters chain, wherein, in good faith, the Hooter's organization's business plan is that guys will be served by smiling and affable girls with abbreviated tops. We have much here to be thankful for, I suppose. I think I look cute in Hooters attire because I am thin and do a lot of aerobics but it's questionable whether many normal guys would agree.
The problem with age discrimination is that in certain fields, among them programming, there is a perception and a reality that in fact you overlearn during the high intensity code-o-ramas of your youth lessons that you are unwilling to "let go".
For example, I may overemphasize the need for an inspect() method because as a kid I learned that early computer software was making undetected mistakes all the time.
However, there is a difference between an engineer who learns the minimum to get by and is unwilling as he ages to do more, and the engineer who in fact learns important lessons in his youth and is unwilling as a result to do LESS.
GM automotive engineers "learned" that it was unnecessary to paint cars in a rustproof way because owners would buy rustproofing, or dealers would throw in free rustproofing. But Japanese engineers did not have this "lesson" and naively used electrostatics to bond the paint to the car surface, and the American consumer was pleasantly surprised to save so much money as a result, creating a perception, which exists to this day, that rice rockets are the best buy.
Whereas other engineers learn things that they are never able to put into practice only to have the industry "come around" to their way of thinking. I always felt that live software should continue to error check but never received reinforcement until I read Bjarne Stroustrup, who compared getting rid of self-check to getting rid of life boats when you set out for the open sea: the received wisdom has always been that error checking beyond a minimum is "inefficient".
The legal system is overdetermined by predominant myths, and one of them in America is the myth that youth has better ideas than old fogies: note that calling the story a myth is not to call it false.
Thus the court, thinking under the sign of myth and hoping, in a subconscious way, to score a point with the Goddess of youth and beauty, decides against the old fart despite the fact that judicial tenure means that the officers of the court are also long in the tooth.
Paradoxically, in the dream-haunted world of the 1960s, the myths dissolved for a second and to see the world as it actually was, to imagine there's no heaven as John Lennon said, was unbearable. One of the illusions lost was the idea that past 40 a man was worthless (they said we said don't trust anyone over 30: this was a journalistic lie: what we didn't trust were phonies hag ridden by myths).
One result of this was the fact that I experienced NO age discrimination past 40, and never felt in the least inclined to sue anyone.
Professionals
I read a nice paper some years back about professionals and the IT. It compared IT to the professionals as doctors, lawyers, and civil engineers and it touched a lot of what you have mentioned here. But the one thing that was presented was the time the profession has had time to evolve and the organizations and standards that have been created. IT has some time to go before all are professionals, but there will be a ladder of different levels for different people in IT, like not all programmers has the same education/experience.
Trolls will be trolls...
But your comments about the difference between us and the lawyers/doctors is right on.