Followup to: Don't Fear Failure
In the same theme as the last article, I think that failure is actually pretty important in learning. Rationality needs data, and trying is a good source of it.
When you're trying to do something new, you probably won't be able to do it right the first time. Even if you obsess over it. Jeff Atwood is a programmer who says Quantity Always Trumps Quality
The ceramics teacher announced on opening day that he was dividing the class into two groups. All those on the left side of the studio, he said, would be graded solely on the quantity of work they produced, all those on the right solely on its quality. His procedure was simple: on the final day of class he would bring in his bathroom scales and weigh the work of the "quantity" group: fifty pound of pots rated an "A", forty pounds a "B", and so on. Those being graded on "quality", however, needed to produce only one pot - albeit a perfect one - to get an "A".Well, came grading time and a curious fact emerged: the works of highest quality were all produced by the group being graded for quantity. It seems that while the "quantity" group was busily churning out piles of work - and learning from their mistakes - the "quality" group had sat theorizing about perfection, and in the end had little more to show for their efforts than grandiose theories and a pile of dead clay.
Where have I heard this before?
Quantity always trumps quality.
When it comes to software, the same rule applies. If you aren't building, you aren't learning. Rather than agonizing over whether you're building the right thing, just build it. And if that one doesn't work, keep building until you get one that does.
The people who tried more did better, even though they failed more too. Of course you shouldn't try to fail, but you shouldn't let the fear of it stop you from tyring.
I wouldn't go as far as to say that quantity always trumps quality, but where the cost of failure is low lots of failures that you pay attention to is a pretty good way of learning. You should hold off on proposing solutions, but you also need to get around to actually trying the proposed solution.
I'm normed such that I'll spend more time talking about if something will work than trying it out to see if it works. The problem is that if you don't know about something already, your thoughts about what will work aren't going to be particularly accurate. Trying something will very conclusively demonstrate if something works or not.
Note:
I originally had this as part of Don't Fear Failure, but that post got too long.
I'm a bit incredulous about the experiment. The students' quantity of production can always be maximized by decreasing the quality. Why wouldn't they? (Even if the students maintain quality, how could the teacher justify assuming this in advance.)
Evaluating the study formally as an experiment, attention to quality is confounded with spending time on the work. (Reiteration is a different story, but in this case we seem to be talking about moving on to a different project, rather than perfecting a single design.) Did the students evaluated on quality produce lower quality because they spent time thinking rather than working; or because they spent too much time on a single item, trying to perfect it?
In writing, it's important to write rather than plan to write, but it doesn't follow that it's important to produce a great number of products rather than ones of high quality. From personal experience, one's writing improves by producing polished work, not by producing an abundance of it.
I agree - mere quantity is not enough... but the act of creating quantity gives a person the chance to gain the experience needed to learn how to improve the quality.
Very few people can get to Quality without going through the quantity...
Quantity is a necessary, but not sufficient condition of quality.