How to Write(nytimes.com)
nytimes.com
How to Write
http://www.nytimes.com/2012/07/29/books/review/colson-whiteheads-rules-for-writing.html?src=me&ref=general&pagewanted=all
43 comments
Some editorial comments:
1) "Please read this" is redundant because if they got that far in your post, they've already read it. 2) "Repeat it to yourself every day" is trite and can be made more interesting by substituting "day" with "hour" or something else. 3) You use "this" but refer to an abstract and ambiguous antecedent. 4) If they can remember to repeat it to themselves each morning, then it must have already stuck, so yours is a nonsensical sentence.
Here's my stab at something more creative:
Tech bloggers, make an effort to follow this advice each time you write, until it becomes effortless.
Or something shorter:
Tech bloggers, sharpie this quote onto your keyboard.
1) "Please read this" is redundant because if they got that far in your post, they've already read it. 2) "Repeat it to yourself every day" is trite and can be made more interesting by substituting "day" with "hour" or something else. 3) You use "this" but refer to an abstract and ambiguous antecedent. 4) If they can remember to repeat it to themselves each morning, then it must have already stuck, so yours is a nonsensical sentence.
Here's my stab at something more creative:
Tech bloggers, make an effort to follow this advice each time you write, until it becomes effortless.
Or something shorter:
Tech bloggers, sharpie this quote onto your keyboard.
Or clearer:
Tech bloggers: be concise.
Tech bloggers: be concise.
It wasn't nonsensical at all, you just completely missed its point.
There was noting ambiguous about the antecedent.
There was noting ambiguous about the antecedent.
Tech bloggers have quotas.
Most tech bloggers also don't know how to write.
Most tech bloggers also don't know how to write.
Good writing takes time and resources, unless you are really good. Writing a good (academic) paper that is concise and coherent takes me a few weeks along with eyeball help from colleagues to point out what I didn't smell myself. I usually don't have those resources to spend on a blog post or even a short hacker news post; its in a different league.
[deleted]
Tech bloggers need way more help than the fundamentals provided in this article. In fact, they are hopeless and should all just stick to writing code.
Uh, don't they blog precisely because they cannot code?
I don't believe that anyone is "hopeless" as a writer. There are people who may never be great writers, but if someone's capable of writing code competently, there's no reason they can't be a good writer.
This is a humor piece, not a guide (for HN readers who click on comments first).
I disagree. There be much good advice in there; all stuff I learned in writing college.
My favorite? Rule No. 10: Revise, revise, revise.
I can't tell you how many times I've written something, had it published (through the newspaper I work at), then read it 2 weeks later and thought "DAMN! I should have changed that!!"
My favorite? Rule No. 10: Revise, revise, revise.
I can't tell you how many times I've written something, had it published (through the newspaper I work at), then read it 2 weeks later and thought "DAMN! I should have changed that!!"
You disagree that it's a humor piece and not a guide? Yes, revising is incidentally a good thing for writers to do, but this is quite obviously satire if you read beyond the first sentence of each rule.
I took it to be an exercise in sarcasm to emphasize the point being made. Admittedly, though, I didn't read many of the points through all the way ;)
I do have a habit of reading partially through an article and then commenting ...
I do have a habit of reading partially through an article and then commenting ...
If you do not read something carefully, you will never learn anything new. The habit you have gives too much weight to your internal biases and not enough to what you're reading.
The key is, if possible, to go off and do something else for a while before revising. What seemed perfectly clear when first written will often seem a little off when reviewed with a cleared head.
It's both. The form of the writing rather than the content per se is what's meant to illustrate his points.
The points are pretty well-worn; I think he is making fun of advice to writers. Do you really think he thinks keeping a dream journal is a good idea?
Sorry, I meant: THE ARTICLE ITSELF is the lesson, not necessarily the points within.
For example, "Rule 8. Is Secret" is (possibly) illustrating #6, #4, and the humor of it #3.
It's making points, meta-points, and doing it with a sense of humor. There are good lessons at each of those levels, and it makes you think "Wait, really? Did he really mean that?"
For example, "Rule 8. Is Secret" is (possibly) illustrating #6, #4, and the humor of it #3.
It's making points, meta-points, and doing it with a sense of humor. There are good lessons at each of those levels, and it makes you think "Wait, really? Did he really mean that?"
Rule No. 1: Code and Tell. Most people say, “Code, don’t comment,” but I stand by Code and Comment.
Rule No. 2: Don’t go searching for a project, let your project find you. You can’t rush inspiration. How do you think Linus came to “Linux”? It was just an ordinary day, and there it was — fate.
Rule No. 3: Program in domains you know. Listen to your heart. Ask your heart, Is it true? And if it is, let it be.
Rule No. 4: Never use three LOC when one will do. Be concise, use macros. Don’t fall in love with the gentle trilling of your mellifluous commands and blocks. Learn how to “kill your darlings,” as they say. With but a few deft strokes, pare it down to create: “(help land shark)”.
Rule No. 5: Keep an open source dream diary.
Rule No. 6: What isn’t said is as important as what is said. In many classic systems, the real action occurs in the API calls. Try to keep all the hard yakka out of the code. Some “real world” practice might help.
Rule No. 7: Developers’s block is a tool — use it. When asked why you haven’t upped your LOC lately, just say, “I’m cutting out unneeded blocks.” Since most people think that developing is some mystical process where code is always created, cutting out blocks is the perfect cover for when you feel like refactoring.
Rule No. 8: Is secret. Yes, check out other jobs.
Rule No. 9: Have adventures. The Algol/C mode was in ascendancy for decades before it was eclipsed by trendy fabulist “objects.” The pendulum is swinging back, though, and it’s going to knock these object eggheads right out of their Stroustrup chairs. Keep ahead of the curve. Get out and see the language landscape. You’ll be glad you did.
Rule No. 10: Refactor, refactor, refactor. I cannot stress this enough. Refactoring is when you do what you should have done the first time, but didn’t. Get that draft counter going. Remove a semicolon and then print out another copy — that’s another draft right there.
Rule No. 11: There are no rules. Except the ones you learned during your Code and Comment days. Have fun. If they don’t want to be friends with you, they’re not worth being friends with. Most of all, just be yourself.
Rule No. 2: Don’t go searching for a project, let your project find you. You can’t rush inspiration. How do you think Linus came to “Linux”? It was just an ordinary day, and there it was — fate.
Rule No. 3: Program in domains you know. Listen to your heart. Ask your heart, Is it true? And if it is, let it be.
Rule No. 4: Never use three LOC when one will do. Be concise, use macros. Don’t fall in love with the gentle trilling of your mellifluous commands and blocks. Learn how to “kill your darlings,” as they say. With but a few deft strokes, pare it down to create: “(help land shark)”.
Rule No. 5: Keep an open source dream diary.
Rule No. 6: What isn’t said is as important as what is said. In many classic systems, the real action occurs in the API calls. Try to keep all the hard yakka out of the code. Some “real world” practice might help.
Rule No. 7: Developers’s block is a tool — use it. When asked why you haven’t upped your LOC lately, just say, “I’m cutting out unneeded blocks.” Since most people think that developing is some mystical process where code is always created, cutting out blocks is the perfect cover for when you feel like refactoring.
Rule No. 8: Is secret. Yes, check out other jobs.
Rule No. 9: Have adventures. The Algol/C mode was in ascendancy for decades before it was eclipsed by trendy fabulist “objects.” The pendulum is swinging back, though, and it’s going to knock these object eggheads right out of their Stroustrup chairs. Keep ahead of the curve. Get out and see the language landscape. You’ll be glad you did.
Rule No. 10: Refactor, refactor, refactor. I cannot stress this enough. Refactoring is when you do what you should have done the first time, but didn’t. Get that draft counter going. Remove a semicolon and then print out another copy — that’s another draft right there.
Rule No. 11: There are no rules. Except the ones you learned during your Code and Comment days. Have fun. If they don’t want to be friends with you, they’re not worth being friends with. Most of all, just be yourself.
I heard someone suggesting going through the mechanical process of writing (even if just random uncoordinated phrases), when faced with writer's block, to get the brain in the mood.
This is a well known technique: http://en.wikipedia.org/wiki/Free_writing
Since this is mostly satire--what are some actually good articles/blog posts about how to write better? I'm familiar with "Writing, Briefly". Any other suggestions?
I think George Orwell's Politics and the English Language has some good advice on writing clearly and precisely, albeit later in the essay.
Elmore Leonard's 10 Rules of Writing.
The rules: http://www.writingclasses.com/InformationPages/index.php/Pag...
The book: http://www.elmoreleonard.com/index.php?/weblog/more/elmore_l...
The man: https://en.wikipedia.org/wiki/Elmore_Leonard
He's written a lot of books-to-movies that you've probably seen, or that your dad has.
The rules: http://www.writingclasses.com/InformationPages/index.php/Pag...
The book: http://www.elmoreleonard.com/index.php?/weblog/more/elmore_l...
The man: https://en.wikipedia.org/wiki/Elmore_Leonard
He's written a lot of books-to-movies that you've probably seen, or that your dad has.
Most of those 10 rules read like of a list of his pet peeves rather than rules for good writing.
"On writing well", William Zinsser
http://www.amazon.com/Writing-Well-30th-Anniversary-Edition/...
http://www.amazon.com/Writing-Well-30th-Anniversary-Edition/...
Try "The Elements of Style." Classic book on writing well.
And a terribly overrated one that won't go away...
http://en.wikipedia.org/wiki/Elements_of_Style#Criticism
http://en.wikipedia.org/wiki/Elements_of_Style#Criticism
'Stein on Writing',
'Bird by Bird',
'The Writer's Portable Mentor',
and 'On Writing', are some books on writing worth reading.
"On writing well" was previosuly suggested here, it's still in my queue though.
I find that being active on forums and debating stuff like religion (agnostic-atheist) has really made my persuasive and argumentative writing better.
I was going to write something; writer's block.
> Rule No. 5: Keep a dream diary.
I wasn't expecting that one.
I wasn't expecting that one.
It is, of course, satirical. For a non-satirical example, see:
http://www.nybooks.com/blogs/nyrblog/2012/jun/15/why-i-hate-...
http://www.nybooks.com/blogs/nyrblog/2012/jun/15/why-i-hate-...
I dunno, it seems like it might be useful.
Tech bloggers: please read this and repeat it to yourself every day until it sticks.