Success through Failure

May 24, 2005

I found this Will Wright quote, from a roundtable at last week's E3, rather interesting:

Will Wright said he's learned the most from games that seemed appealing on paper, but were failures in the marketplace. "I actually ask people when hiring how many failures they've worked on," he said, "and I'm actually more likely to hire someone based on how many failures they've experienced. I think it's the best learning system."

As a developer, the likelihood that you're working on a project that will fail is high. Every failure should be considered a rich opportunity for learning what doesn't work, and why. As Thomas Edison once said:

I remember thinking, rather bitterly at the time, about the story of Thomas Edison's early attempts to come up with the right material for a lightbulb. He had tried a thousand different elements and all had failed. A colleague asked him if he felt his time had been wasted, since he had discovered nothing. "Hardly," Edison is said to have retorted briskly. "I have discovered a thousand things that don't work."

In fact, the difference between success and failure can ultimately hinge on how you handle failure-- as illustrated in this New Yorker article about predicting the success or failure of surgeons:

Charles Bosk, a sociologist at the University of Pennsylvania, once conducted a set of interviews with young doctors who had either resigned or been fired from neurosurgery-training programs, in an effort to figure out what separated the unsuccessful surgeons from their successful counterparts.

He concluded that, far more than technical skills or intelligence, what was necessary for success was the sort of attitude that Quest has -- a practical-minded obsession with the possibility and the consequences of failure. "When I interviewed the surgeons who were fired, I used to leave the interview shaking," Bosk said. "I would hear these horrible stories about what they did wrong, but the thing was that they didn't know that what they did was wrong. In my interviewing, I began to develop what I thought was an indicator of whether someone was going to be a good surgeon or not. It was a couple of simple questions: Have you ever made a mistake? And, if so, what was your worst mistake? The people who said, 'Gee, I haven't really had one,' or, 'I've had a couple of bad outcomes but they were due to things outside my control' -- invariably those were the worst candidates. And the residents who said, 'I make mistakes all the time. There was this horrible thing that happened just yesterday and here's what it was.' They were the best. They had the ability to rethink everything that they'd done and imagine how they might have done it differently."

This should always be a key interview question when you're hiring. Software development is difficult in the best of conditions. You should always be failing some of the time, and learning from those failures in an honest way. Otherwise, you're cheating yourself out of the best professional development opportunities.