I have heard that many times over the course of my adult working life. I tend to agree with it mostly, although I doubt that it applies equally to all types of work, and it may have been more true in the past than it is in today's economy and with today's technology. I would think that it could vary wildly between say a position such as "Office Manager" and that of "Newspaper Reporter". The reason(s) for leaving would matter a great deal as well. Leaving a job for a much better job (better pay, more prestige, etc.) is quite different than leaving a job due to personality clash or poor work performance. There also could be a big difference depending upon the values of the employer in charge of doing the hiring. The person(s) with decision-making responsibility might place more emphasis on other traits and accomplishments, and not care terribly much that the employee left a job or jobs after a short time of being employed.

Just Try It: Quantity Trumps Quality

by atucker 1 min read4th Apr 201183 comments


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?

  1. Stop theorizing.
  2. Write lots of software.
  3. Learn from your mistakes.

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.

I originally had this as part of Don't Fear Failure, but that post got too long.