Looks like a good argument for the Snowflake method [0]. This method is basically to "develop" a novel, by starting with a single sentence and gradually expanding it into the novel. In contrast, the other method (pansing) is to start writing the first chapter immediately.
For either approach you find great writers using them. It seems to be a question of personality.
Thanks for the Snowflake link. When reading a novel, I sometimes try the reverse to crystallize my memory of the story. I imagine summarizing a page with a sentence, then a chapter with a sentence, then the book.
I know this probably works and when described like that it sounds like a good idea. It seems basically you start with a single idea and write around it to make it bigger.
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.
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.
"But that's the great thing about going this fast, the novel starts to eat you and you find yourself writing any time you can just for the pure joy of it. Even better, on the days where I broke 10k, I was also pulling fantastic words-per-hour numbers, 1600 - 2000 words per hour as opposed to my usual 1500. It was clear these days were special, but I didn't know how."
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.
I have a strange reaction to my epiphanies. When I've cracked the puzzle mentally and it's time to put the code in the text editor, I start getting extremely anxious. No clue why.
Edit: To clarify, I mean anxious associated with "anxiety", not "with great anticipation"
"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.
When I wrote my first novel I spent a lot of time at my neighbours house using their old 486 and notepad. They didn't have internet access and the places was quiet other the cat that I was cat sitting. Needless to say, the situation turned out to be very productive and without distraction.
The part about knowledge applies for programming too. I have noticed myself being far more productive when I have sketched out the general approach I am going to take with a problem on a paper first before actually writing any code. Once you start coding, you get lost in the low-level intricacies and this sometimes makes you lose sight of the overall goal.
True, but don't you find the sketching out process taking whole fun out of the process? I mean, once you know what you are going to code (or write), doesn't your motivation to (mechanically) implement it go down a bit?
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.
Fun quote from the article: "This is not a choice between ruminating on art or churning out the novels for gross commercialism (though I happen to like commercial novels)"
The most interesting part of that post, in my opinion, was how she claimed each of her discoveries were -- trivial. That really hit home with me because I've felt the same feeling before. I've learned to stop, step back, look at the problem, and just solve it.
Thanks for a great post (even though it was written a while back).
I feel it's worth mentioning that, while word count alone isn't an indicator of quality, the #1 most common hurdle most writers (and developers, and anyone pursuing a creative art) are facing is producing. Real artists ship. 10,000 words might not all be good, but you're a hell of a lot more likely to spit out a few good ones in that pile versus a pile of 500 words. Make it work, then make it work well, right?
Writers swear by practice, and the discipline that enables it. Churning out words is practice; there's a saying that you need to get the first hundred thousand words of crap out of your system before the quality of your output improves. See also NaNoWriMo — No plot? No problem! — where the winning condition is simply to turn in forty thousand words at the end of the month.
It's interesting that the goal is to increase the amount of words written rather than their quality. I suppose which of those matter more depends on the type of work you are writing.
Don't get too hung up on words written as being considered a metric of quality - for authors, it's a metric of productivity, quality or otherwise. Unlike (most) code, a novel generally has a roughly intended length when it's started (compare harry potter 1 vs 7; the light novel vs the must-service-my-fans). It can take you a few years to reach that, or a few months.
Words per session for an author does not translate into lines of code for a coder - they're different beasts.
I have written a few technical books together with a co-author. From my experience "Side 1: Knowledge" is king. Before I explain a technical topic in writing I prepare every sample project beforehand. Complex sample projects are prepared in different versions (starting with the sample immediately after it has been created by an IDE, …) up to the final version. This has two benefits: I, as a writer, can offer the sample (step by step) for download to the readers so they can use them as a reference when something goes wrong - but more importantly: It helps to structure the writing process because I know the steps I have to describe. I know when something essential has happened (because I have created an additional version of the sample).
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.
Yes, absolutely. Especially with side 1, knowledge, this just translates to using a combination of a top-down and bottom-up approach as opposed to a pure bottom-up approach.
This is really important-the author is talking about starting with high level, easily modifiable structures, vs starting with all the details at once.
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.
Late to the party, but I felt I had to share that this post directly inspired my brain (definitely my _brain_, as opposed to _me_) to create and start writing a story. The night after reading and thinking about this, I woke up with characters, a world, a plot, conflict and resolution, a whole novel (actually a whole set of them). It's been quite a week for me, especially because my sudden surge in writing fiction led me to try giving my iPhone app away for free and then suddenly finding some unexpected success there, for the first time since that app launched!
If I had scenes that were boring enough that I didn't want to write them, then there was no way in hell anyone would want to read them
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.
The folks at cloud9 IDE or Codecademy are in a good position to collect and expose patterns in programming efficiency.
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.
The probability of such a program being developed is diminished by how depressing its results would likely be to its own author. It would be interesting, though, wouldn't it... now you've got me thinking.
zed shaw's peepcode one on one goes into something similar. By hooking into the make command, he builds up a nice stats database of similar information
Am I the only one who reads about this huge inelegant approach to increasing your "productivity" by simply brute-forcing more words per day. And can't avoid to think "woa, such a huge waste, she should just use all that energy to write a bot that does all that writing and save time in the long run"?
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.
Brute-forcing? What she was originally doing was brute forcing. She's changed to a more planned, intelligent way of writing, the opposite of brute-forcing. It's a classic 'work smarter, not harder' article.
[+] [-] beza1e1|14 years ago|reply
For either approach you find great writers using them. It seems to be a question of personality.
[0] http://www.advancedfictionwriting.com/art/snowflake.php
[+] [-] cpeterso|14 years ago|reply
[+] [-] simcop2387|14 years ago|reply
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.
[+] [-] thalur|14 years ago|reply
[0] http://thisblogisaploy.blogspot.co.uk/2011/09/how-i-plot-nov...
[+] [-] aristus|14 years ago|reply
"Things come and go, but Ampere's Law will always be current."
[+] [-] rauljara|14 years ago|reply
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.
[+] [-] jamie_ca|14 years ago|reply
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.
[+] [-] spindritf|14 years ago|reply
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.
[+] [-] eru|14 years ago|reply
Just don't make volume the metric to go for for any production artifacts (like the published novel or published software).
[+] [-] aiscott|14 years ago|reply
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.
[+] [-] kroo|14 years ago|reply
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.
[+] [-] RegEx|14 years ago|reply
Edit: To clarify, I mean anxious associated with "anxiety", not "with great anticipation"
[+] [-] sien|14 years ago|reply
"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.
[+] [-] realschool|14 years ago|reply
[+] [-] evincarofautumn|14 years ago|reply
[+] [-] sitkack|14 years ago|reply
[+] [-] karterk|14 years ago|reply
[+] [-] paraschopra|14 years ago|reply
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.
[+] [-] johansch|14 years ago|reply
Ah, fantasy author, of course.
[+] [-] mvzink|14 years ago|reply
[+] [-] darxius|14 years ago|reply
Thanks for a great post (even though it was written a while back).
[+] [-] 54mf|14 years ago|reply
[+] [-] obtu|14 years ago|reply
[+] [-] zeroonetwothree|14 years ago|reply
[+] [-] vacri|14 years ago|reply
Words per session for an author does not translate into lines of code for a coder - they're different beasts.
[+] [-] LinaLauneBaer|14 years ago|reply
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.
[+] [-] shepbook|14 years ago|reply
[+] [-] jmonegro|14 years ago|reply
(edit: I mean that in the sense of making your code more efficient)
[+] [-] will_lam|14 years ago|reply
[+] [-] unknown|14 years ago|reply
[deleted]
[+] [-] SatvikBeri|14 years ago|reply
[+] [-] SatvikBeri|14 years ago|reply
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.
[+] [-] alanfalcon|14 years ago|reply
[+] [-] dhimes|14 years ago|reply
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.
[+] [-] 9diov|14 years ago|reply
[+] [-] jorgem|14 years ago|reply
[+] [-] bcjordan|14 years ago|reply
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.
[+] [-] evoxed|14 years ago|reply
[+] [-] apu|14 years ago|reply
http://www.jukie.net/bart/blog/save-everything-with-git-wip
But it doesn't look like he describes the result of this experiment.
[+] [-] ramblerman|14 years ago|reply
[+] [-] vibrunazo|14 years ago|reply
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.
[+] [-] vacri|14 years ago|reply
[+] [-] anarchotroll|14 years ago|reply
[+] [-] kolya3|14 years ago|reply
[+] [-] unknown|14 years ago|reply
[deleted]