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.
Paul Graham said something very similar about figuring out a program:
"I was taught in college that one ought to figure out a program completely on paper before even going near a computer. I found that I did not program this way. I found that I liked to program sitting in front of a computer, not a piece of paper. Worse still, instead of patiently writing out a complete program and assuring myself it was correct, I tended to just spew out code that was hopelessly broken, and gradually beat it into shape. Debugging, I was taught, was a kind of final pass where you caught typos and oversights. The way I worked, it seemed like programming consisted of debugging.
For a long time I felt bad about this, just as I once felt bad that I didn't hold my pencil the way they taught me to in elementary school. If I had only looked over at the other makers, the painters or the architects, I would have realized that there was a name for what I was doing: sketching. As far as I can tell, the way they taught me to program in college was all wrong. You should figure out programs as you're writing them, just as writers and painters and architects do."
As a CS student currently at university, my experience has been identical. I also can't help but notice a similarity between these ideas and the methods of agile software development, where at each iteration you produce a working approximation of the final software, taking into account new information and new specification changes as you go.
The people who taught you to architect programs before coding were also aware of this trade-off.
It's a lot easier to write the small programs assigned in college that way, than the large programs you will write in the real world.
This is not the top-down vs. bottom-up debate; both top-down and bottom-up design architect first.
It is related to the concept of waterfall/iterative/incremental design; incremental designers can paint themselves into a corner.
I've written a lot of big programs, and I've never regretted the time spent architecting them. I have som... (read more)