Iterative learning on Coding Horror
August 7th, 2008Jeff Atwood had an interesting post over the weekend entitled “Quantity Always Trumps Quality” where he quotes a story from a book called “Art and Fear”, a curious scenario from a pottery class:
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.
And Jeff’s summary:
Where have I heard this before?
1. Stop theorizing.
2. Write lots of software.
3. Learn from your mistakes.
I couldn’t agree more. The ideas behind my recommended techniques for making yourself easier to be scheduled is based on this exact premise. Want to get good at something? Do it a million times. You’ll make a ton of mistakes early on but that’ll help you refine your processes to produce a better result. That doesn’t mean there’s never room for theorizing, but there comes a point where you can’t let things play out in concepts any more and you need to get your hands dirty.
Are you kidding me? Take a look at my picture. If I’m not a genuine, bona fide nerd I’m not sure who is. I'm currently employed as the Marketing and Internet Platform Solutions, Portals and Applications Chief Architect at Hewlett Packard (try saying that 5 times fast) and write here about career best practices for techies. Why? Because I wish I'd had this kind of free advice earlier in my own career and now I'm trying to "pay it forward". See more in