From there it is only a small step to measuring "programmer productivity" in terms of "number of lines of code produced per month". This is a very costly measuring unit because it encourages the writing of insipid code, but today I am less interested in how foolish a unit it is from even a pure business point of view. My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger.
Putting such a great emphasis on word count strikes me as a terrible idea. Who wants to read 10,000 words? No one. What you want to read is a good story, or an interesting argument, or beautiful language. If the writing isn't any good, more words just mean more annoyance.
If you want to boost a specific metric, you almost always can. But that doesn't necessarily mean that the whole picture improves along with it.
She makes a point of saying in point three that she's taking a critical look at what she intends to write, and makes sure there's good content in the scene, or she scraps/reworks the scene.
Admittedly that doesn't say anything about the quality of her prose, but one perspective is that the sooner you're done your first draft, the more time you have for editing.
Publishers, apparently, and there are reasons, you be the judge of how good are they, to aim for certain volume(s): http://www.antipope.org/charlie/blog-static/2010/03/cmap-5-w... I found this article very illuminating because in general, as a reader, I completely agree with you.
Yes. But a focus on volume might produce better things in the long run than a focus on quality. You can and should also rewrite your prose, cut and edit.
Just don't make volume the metric to go for for any production artifacts (like the published novel or published software).
It seems like you didn't actually read the article. Maybe you did, but she addressed the pure wordcount metric.
Her motivation for increasing her word count was the reduced number of days per week she could write on, trying to balance family life and professional life.
Her desire wasn't simply to have reached some arbitrary count, it was to increase her productivity so she could meet her deadlines while working fewer days.
From there it is only a small step to measuring "programmer productivity" in terms of "number of lines of code produced per month". This is a very costly measuring unit because it encourages the writing of insipid code, but today I am less interested in how foolish a unit it is from even a pure business point of view. My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger.
Putting such a great emphasis on word count strikes me as a terrible idea. Who wants to read 10,000 words? No one. What you want to read is a good story, or an interesting argument, or beautiful language. If the writing isn't any good, more words just mean more annoyance.
If you want to boost a specific metric, you almost always can. But that doesn't necessarily mean that the whole picture improves along with it.