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.
Posted by Jeff Atwood
James Dyson on Living a Life of Failure
I made 5127 prototypes of my vacuum before I got it right. There were 5126 failures. But I learned from each one. That’s how I came up with a solution. So I don’t mind failure. I’ve always thought that schoolchildren should be marked by the number of failures they’ve had. The child who tries strange things and experiences lots of failures to get there is probably more creative…
We’re taught to do things the right way. But if you want to discover something that other people haven’t, you need to do things the wrong way. Initiate a failure by doing something that’s very silly, unthinkable, naughty, dangerous. Watching why that fails can take you on a completely different path. It’s exciting, actually. To me, solving problems is a bit like a drug. You’re on it, and you can’t get off.
Living a life of failure reminds me of the biography of Bernard Palissy in the Samuel Smiles's Victorian classic Self Help, where Palissy burns everything in his kiln, including his own furniture and his house's floorboards, in his attempt to rediscover the secret of Chinese porcelain.
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."
Edison never learned from his failures. His quest for the light bulb was an equivalent of a brute force search, trying every possible filament possible, including ones which should have been obvious would fail. A little more attention to the scientific method or just a glance at a periodic table would have saved him months of experimenting.
RE: Marquis Wang
Yes. I agree. The concept of learning through mistakes is nothing more than justification of trial and error. While that can garner quick results, it is also foolhardy to throw accumulated knowledge and experience out of the window. A moderate combination of utilizing existing knowledge and research principles as well as a little trial and error where there is no knowledge at all would be more likely to be successful.
"Only a fool learns from his own mistakes" (Otto von Bismark)
"Only a fool learns from his own mistakes" (Otto von Bismark)
I assume this is referring to how one should learn from others' mistakes. However, what if no other fool has attempted your future mistake and you are essentially breaking new ground!? 8^)
In a domain where no wisdom has yet been gathered, all are fools.
Marquis Wang -
Periodic table probably wasn't all that popular or widely available at the time. It was only invented/compiled 10 years prior to the light bulb, it wasn't complete, it wasn't definite, and probably wasn't given all that much credence when Edison was developing the light bulb. Also, Edison didn't really invent the light bulb, but developed the first commercially practical light bulb. (courtesy of wikipedia). He probably had plenty of information to work off of, so it wasn't really like stabbing your wife in the dark.
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.
At the place I work, we are definitely failing more often than not. I work with a bunch of knuckleheads. PMs who can't or won't take the time to know the project thoroughly, developers who are overly reliant on snippets from the Internet to build their enterprise apps. And the politics...
I'm not sure about the effectiveness of using the interview question you suggest. I've had plenty of failures, have learned from them, and understand that those have served me well. If an interviewer asks me about my failures, I'm not sure I'd reel them off. Maybe he's never heard of this concept and thinks he's evaluating my honesty by asking me if I'm a shit developer.
Of course then there's the question of whether or not I want to be working for someone who doesn't get that concept; whether or not I should be gaming the interview technique once I've groked it, etc., but the point remains.
For this job I was unscrupulously honest, it was noticed in the right way, and everything is groovy. For my last job I was unscrupulously honest and it went against me for my entire time there because the boss, while appearing sensible and having a very good memory for the exact dialogue used in my interview, was actually a moron of the highest calibre.
only a fool learns from his own mistakes... the rest learn from fools.
Software development is tough, but so is bridge-building and we would not accept it if over half of all bridges crashed.
Over a period of several months, the members of the CIO Linked In Forum shared their centuries of experience in a discussion on why software projects fail and how to ensure success.
The results are collated in this document:http://docs.google.com/View?docID=0AedaAVWt3nfCZGdzY3JyN3NfMGZzZ3pjeGQy