(edit: I mean that in the sense of making your code more efficient)
--Blaise Pascal (http://en.wikiquote.org/wiki/Blaise_Pascal)
"Write one to throw away" is the quote I remember reading from someone, and I find it applies well to some of the code I write (thankfully not all).
[0]: http://www.dklevine.com/general/software/tc1000/jarnal.htm
[1]: http://www.amazon.com/Wacom-Bamboo-Create-Tablet-CTH670/dp/B...
Sure, writers need practice, but such extreme conditions are not conducive to practice at all.
Well, with NaNoWriMo you have a whole month. So some days you may in fact have 0 words, and other days you'll have 4000. But in general, the more you do this, the easier it is. Are weekly 2000 word essays from college students who don't really care about English or Sociology or whatever class the essays are for too much to expect? Maybe. I know that after a few months of blogging 1000+ word blogs on a relatively frequent basis, those school essays are trivial.
> Second, the requirement that the project start from zero is also a deterrent—it encourages a “starter” attitude when what’s needed is a “finisher”.
The idea is that at the end of the month you evaluate what you have and decide if it's worth finishing and revising. Your work is not supposed to be "perfectly good". This is the same philosophy over at the Ludum Dare 48 hour game programming competition ( http://ludumdare.com/compo/about-ludum-dare/ ) where you start from scratch and see what you can do. Many people have taken their finished entries and continued to work on them, eventually selling them for real money. Most people don't, they abandon the project, and that's fine. They learned something along the way that will help them be a better game developer the next time around or in a context where they have more time.
Tossing out work would be counter-productive, but I think rewriting your material from an outline would be within the letter and spirit of the rules. Boxing the project into a fixed time period (aside from any preparatory work) is good for motivation: you won't throw good time after bad in a project that is getting stale (when working knowledge and motivation have dwindled), you'll just reuse the same abilities you were cultivating the first time but with a bit more ease; you'll be communing with a large group of people sharing your joys and trials and egging you on.
For either approach you find great writers using them. It seems to be a question of personality.
Creating Short Fiction by Damon Knight changed the way I write—it puts special emphasis on being able to clearly state, in a sentence or two, precisely what your story is about. And there’s hardly a better way to find out than to know at the outset!
But, I also can't help but think of the dilbert cartoon where the PHB insists that the most important thing is the name of the project, before you even know what the project is.
Personally I think that there's some overlap here as both techniques seem to be trying to show how to start from a single idea and bring it into something more complete.
[0] http://thisblogisaploy.blogspot.co.uk/2011/09/how-i-plot-nov...
"Things come and go, but Ampere's Law will always be current."
"Several things were immediately clear. First, my productivity was at its highest when I was in a place other than my home. That is to say, a place without internet. The afternoons I wrote at the coffee shop with no wireless were twice as productive as the mornings I wrote at home."
The internet is now the most powerful distraction in the universe.
Here's one from 2010. http://www.freelancewritinggigs.com/2010/03/how-i-improved-p...
On one's own, simply using a VCS with a high enough commit frequency would let you infer something about lines added per hour. Perhaps an editor's undo stack could also be committed to store finer-grained metrics.
With detailed metrics and impressive data analysis there's the opportunity to uncover useful insights into how we debug and learn. That's probably more than a weekend project, but worth it in potential future payout IMO.
http://www.jukie.net/bart/blog/save-everything-with-git-wip
But it doesn't look like he describes the result of this experiment.
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.
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.
Just don't make volume the metric to go for for any production artifacts (like the published novel or published software).
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.
I am curious because it happens to me usually, and I like to discover and explore as I go along instead of doing careful initial planning.
However, there are also times when you have a larger goal in mind - say to build something of immense scale and power. In that sense - the micro level picture takes a backseat.
To me - shipping is the ultimate goal, so I don't see planning as taking the joy away from programming - it only gives me more satisfaction.
This thrill of creation, when you've got the design (momentarily?) cracked and all that's left is the small matter of putting to disk what's there in your mind already, describes some of the most exciting experiences I've had writing code.
Edit: To clarify, I mean anxious associated with "anxiety", not "with great anticipation"
I already cry inside when I see the same design pattern repeat itself, twice, in my code. I just have to re-factor it, to avoid waste. And she's writing 10,000 words a day, that won't make the next 10,000 any more efficient? I literally cringe in fear.
I should probably take a break.
Just a bad joke anyway, nothing to see here.
Ah, fantasy author, of course.
Words per session for an author does not translate into lines of code for a coder - they're different beasts.
Thanks for a great post (even though it was written a while back).
A rough outline created in advance also helps.
I am also talking to myself - a lot. Before writing something down for my book I explain it to myself.
This is exactly the same concept as doing customer validation before creating the product.
It's the same idea as whiteboarding a complicated program before starting to code.
It's the same as creating a prototype before you code out a full-fledged product.
Using a top-down approach of creating "shells" before fleshing out details has been my single biggest productivity gain over the last year, and it's definitely worth applying to nearly every intellectual aspect of your life.
I wish more writers would recognize this. It may be the most important revelation she makes in this blog.
Paralleling 9diov's comment (http://news.ycombinator.com/item?id=3755826), it would be great to come up with a way to think about app development that captures its essence.
