Quantity over Quality. Jeff Atwood wrote about this contentious maxim back in 2008. The crux of the argument being, unrelenting creation always leads to improvement. Jeff backed it with an allegorical tale of a ceramic teacher from the book Art & Fear —
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.
Evident from the comments, most found the idea to be terribly delusional. And there is good reason for that. I have seen innumerable programmers who barely improved a notch despite writing thousands of lines of code. But, then again, there are many cases of aspirers who progressed remarkably by shipping continuously. Like everything, programming is hardly an innate skill; programmers get better as they write more code. What, then, is the key reason behind the two largely different trajectories?
External Feedback
When I look back at the code, or an article, I wrote months back, I am often embarrassed about the visible mistakes that I made. Of course, feeling bad about your past code is a significant sign of advancement over your earlier skill-level. However, when it comes to a different skill, playing chess, for instance, I can note how my progress has been laughable. I have lost hundreds of beginner-level games to computer without any improvement in my ability.
The difference highlights the contrast between good practice and a terrible one. Playing chess the same way every time is hardly beneficial, irrespective of hours you spend playing. Practice makes perfect but not all practice is equal. The factor separating the two, however, is smaller than you think. It’s the absence of external feedback.
I am getting better by writing more code because my time is also spent in going through other people’s projects, their coding style, and advices on blogs and forums. I don’t take conscious effort to assimilate that implicit feedback; for the most part, it’s an automatic process of understanding what can be a better way and noticing the mistakes you’ve made. Lacking external feedback, I don’t have anything better to look forward to, which makes the progress unlikely.
It maybe the reason why pair programming, or having a mentor is so effective. People who can pin-point more mistakes creates a stronger feedback loop that catalyses the learning process.
There is something common in people whose experience rarely manifests in their work. They are incredulous to even the idea of improving at writing code. They keep repeating mistakes without searching ways to do better. For them, it’s the matter of what works and what doesn’t. It’s similar to what happened to me when I played chess. I never made an effort to understand the game, or observe how professionals play it. In short, I was barely making random moves that abide by the rules.
Utilising external feedback is synonymous to learning from others. And it happens invariably when a practitioner regularly goes through excellent work. When a writer is reading a riveting fictional story, she is also subtly noticing the clever things that the author did. Even though lacking the same level of skill could be dismal, her work is slowly heading in that direction, precisely how Ira Glass, host of the popular National Public Radio show, put it:
All of us who do creative work, we get into it because we have good taste. But it’s like there is this gap. For the first couple years that you’re making stuff, what you’re making isn’t so good. It’s not that great. It’s trying to be good, it has ambition to be good, but it’s not that good.
But your taste, the thing that got you into the game, is still killer. And your taste is good enough that you can tell that what you’re making is kind of a disappointment to you. A lot of people never get past that phase. They quit.
Everybody I know who does interesting, creative work they went through years where they had really good taste and they could tell that what they were making wasn’t as good as they wanted it to be. They knew it fell short. Everybody goes through that.
And if you are just starting out or if you are still in this phase, you gotta know its normal and the most important thing you can do is do a lot of work. Do a huge volume of work. Put yourself on a deadline so that every week or every month you know you’re going to finish one story. It is only by going through a volume of work that you’re going to catch up and close that gap. And the work you’re making will be as good as your ambitions.
It’ll indeed if you aspire. Creating same kind of work without motivation, however, would hardly lead anywhere.
Quantity Over Quality
The idea is terribly erroneous if “quantity” is taken as act of repeating things. For skill improvement, the output needs to be coupled with cues of better work and external feedback. If present, work starts sucking less without deliberation. For that reason, it’s vital to stick to a schedule and do things. The more you’ll do, the better course your work will take. I imagine that’s how Jeff meant it.
There is a simple rule of thumb to assist you: are you dissatisfied what you did a while back? If not, then there’s something amiss.