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.
Same. And actually, having used this method without knowing it had a name, I can say it’s a great way to write. Crystals grow naturally, but distillation is laborious.
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!
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"
I know the feeling, and the reason why I start feeling anxious in the same way you do is because I know that afterwards I am going to be in a lull again, that I will be bored to tears and will have the hardest time concentrating and getting done what needs to be done until there is another hard part that needs to get done at which point I am flying again...
"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.
Internet isn't the new TV until people start bragging about how they've canceled it completely and we're all idiots for remaining beholden to "Big Internet."
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.
You must be extremely good at predicting any challenges in your designs. I'll sketch out my data structures in advance, but implementing the algorithms for processing them is rarely as straightforward as anticipated. Sketching it out helps me solidify the high-level ideas - but then I like programming by the "meet in the middle" model: a combination of bottom-up and top-down. I know plenty other programmers who prefer one or the other.
It really depends. If you see programming itself as something that gives you joy - then planning something out of course will remove some of the exploratory joy out of it.
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.
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).
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)"
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.
There are a few significant problems with NaNoWriMo. First, while a challenge must be challenging, it should also be realistic. For many writers, 1666 words a day, every day, is a bit too much to expect. 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”. Finally, the unrealistic deadline in combination with the start-from-nothing requirement makes people throw away their perfectly good work from last year. You wrote 80 pages? Toss it!
Sure, writers need practice, but such extreme conditions are not conducive to practice at all.
> For many writers, 1666 words a day, every day, is a bit too much to expect.
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.
NaNoWriMo isn't a reasonable goal for everyone (and not for me either), but it's a meaningful badge of honour. I think there are other events with a similar recipe but an investment that would suit you better (some LJ communities, blog festivals, etc).
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.
I'm of the opinion that the "100,000 words of crap" you mention applies to just about every single skill. Not a huge believer in "natural talent", I'd wager that practice and getting that crap out of one's system is the only way to get good at anything.
I've never heard the low hundred thousand words figure before. I've only ever seen the million words figure. I agree NaNoWriMo can be useful, so can frequent blogging about whatever's on your mind.
I'm probably wrong about the figures; mostly I find it interesting that these different crafts praise different virtues. I'm very happy to render swathes of code useless and kill those lines, but the writers are on to something when praising effort. Productivity is harder to measure for programmers, but the insight still works.
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.
Yeah, that's what I was thinking. It seems the principles could be applied well. Though I think, the principles are definitely directed toward an introvert's preferred style of working.
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.
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!
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.
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.
Turns out I'm already collecting this data… Vim has recently added a persistent undo feature (enable by setting 'undodir' and 'undofile'; 'undolevel' can also be raised from the default 1000); there is a Gundo plugin that displays the undo tree like a DVCS commit graph.
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.
Probably my fault that I wasn't clear. It's just an analogy to my world and how I usually deal with problems as a programmer. If I had to write 10k words a day, I would write a bot to do it. And any more planned, intelligent way of doing that, manually, would just feel like bandaging a brute-force solution instead of looking for an elegant one.
A hundred thanks for the Rescuetime mention. I had no idea that I could get something like this for free (lite version, good enough for me, for now) and so easily (I think it took less than a minute to download and set up).
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