The same survey showed that turnover is nearly three times higher among those working long weeks. Consider that a headhunter might charge a third of a year's wage to find a replacement, and before retraining costs, each person lost represents $30,000 or more out the door.

Absenteeism is twice the national average at companies that routinely resort to long weeks. Stress leads to sickness, and even people shackled to the desk need free time to get all of the routine activities of life done.

Although overtime will always be part of the fabric of our profession, some toxic companies use it as a cost-saving strategy. Unless fairly compensated, that's servitude we should all reject. Engineers sell their skills to their employer, and their inventory is time. The company strategically translates their inventory into revenue. So should we.

Superprogrammers
What about superprogrammers? They are the folk that some companies rely on to defy all productivity statistics and crank a lot of code fast. I've been fortunate to work with some brilliant developers who hole up in their office and create wondrous products, fast, and without a fuss. They love to build stuff, eschew office politics, and take great pride in their work.

In a private study conducted for IBM in 1977, Capers Jones found that the best developers are about six times more productive than the worst.³ That's a pretty impressive number, but holds only for small (1,000 lines of code) projects. The difference decreases quickly as projects grow in size, till, at half a million lines of code, the best and worst developers are equally awful. Big systems require a lot of collaboration, so we spend much of our time on meetings, e-mail, reports, and more meetings. A superprogrammer and the worst person on the team attend meetings at exactly the same speed.

There's another breed of superprogrammer, though. Some deeply believe they are the best engineer in town when, well, they might actually be among the worst. In fact, in "Unskilled and Unaware of it: How Difficulties in Recognizing One's Own Incompetence Lead to Inflated Self-Assessments," the authors show that those in the bottom 12% of performers estimate they are in the 62nd percentile.⁴ And those who are very competent tend to accurately estimate their own abilities.

It sounds almost like an evolutionary effect meant to protect one's ego: at least everyone feels good about their skills, whether warranted or not.

The study was hopeful, though: training that boosted the bottom group's abilities also improved their ability to access themselves.

I've worked with more than a few self-described superprogrammers who couldn't code their way out of main(). All were resistant to training efforts. The very ego that led to bloated self-assessment blinded them to their flaws and inoculated them from any attempt, however softly presented, to bolster their skills.

Tom DeMarco looked at superprogrammers. In Controlling Software Projects, he suggests that developers should specialize, an idea that somewhat mirrors IBM's old concept of structuring a team around a chief programmer.⁵ Although Joe might be an incredible designer, that's no reason to suspect he's any good at debugging. Perhaps Jill can crank code at a dizzying speed but is awful at testing it. Every other discipline specializes; isn't it logical that we should, too?

I've seen no data that suggests such specialization works, though it does tickle the common-sense bone. But organizing people into specializations requires quantitative data about how each person performs in different roles, which can be hard to get. And I suspect most of us would reject the idea simply because it takes much of the fun out of the job. Hey, I like doing it all, and take enormous personal satisfaction out of building much of the system.