Quantity Always Trumps Quality
codinghorror.com
codinghorror.com
Iteration (which is what he's referring to when he says "quantity") is an essential part of quality software. But "quantity over quality" suggests perpetually producing lots of crap without regard to outcomes.
Still, his call to prefer working, shipping code over paralysis-through-analysis is very good.
Our options are:
1) Too much thinking, not enough doing
2) Balanced thinking & doing
3) Too much doing, not enough thinking
As often is the case, the middle path is best.Is it narcissism when authors believe their readers are so stupid that they'll drink everything they write ? Don't we deserve at least some sort of credible example, even if it's obviously made up and exagerated to fit the author's narrowed perception of reality ?
If not, would you like to see me make one? :)
The best way to learn is by doing, and the best way to get better is to (happily) make mistakes and learn.
Nobody/nothing is perfect, and often (perceived/contextual) perfection is derived from iteration. And the hardest part about iteration is often making the start.
More accurate: Quantity Causes Quality.
Focus first on playing all the notes in the right order. Don't worry about the timing at all, even if it takes several seconds to move from one note to the next. Once you can play all the notes, then you start to work on the timing, playing gradually faster and faster until you have both the melody and the rhythm mastered.
The idea is that once you have memorized the correct movements, it's much easier to work on the timing. If you start playing too fast and make mistakes, you'll start to memorize the mistakes.
"Slow, well done, steady."
[as opposed to aerobics shake-it-all with music "gymnastics"]
It's a misleading statement written as-is.