[HN Gopher] You might as well be a great copy editor
___________________________________________________________________
You might as well be a great copy editor
Author : dannas
Score : 65 points
Date : 2020-06-24 17:27 UTC (1 days ago)
(HTM) web link (blog.regehr.org)
(TXT) w3m dump (blog.regehr.org)
| fennecfoxen wrote:
| I would like to add a third recommendation to the list of two,
| and recommend "Style: Towards Clarity and Grace". (Alternatively,
| use any similar book by Joseph M. Williams featuring the words
| Style, Clarity, and Grace in the title).
|
| This book discusses the information architecture of clear and
| coherent phrases, sentences and paragraphs in the English
| language, and a few passes through its contents will leave you
| able to reason about the way you lay out ideas and information in
| your writing.
| Tomte wrote:
| There is a fantastic section that shows why the passive has its
| uses, and that "avoid passive voice" can be harmful.
| fennecfoxen wrote:
| Oh, yes. The passive voice is not simply dismissed in this
| work as a tool to avoid responsibility. Rather, it takes its
| place as an important tool that can make paragraphs more
| coherent, by structuring the sentences to elevate the parts
| that really matter. The subjects of sentences in this
| paragraph, for instance, are all strongly related to writing
| concepts. This paragraph itself would be weakened if I were
| to begin, "Joseph M Williams promotes the passive voice." Our
| communication would only be hindered if we were to highlight
| the incidental matter of his authorship.
| tom_mellior wrote:
| That's not a strong argument. The natural "translation" of
| your first sentence would be something like: "This work
| does not simply dismiss the passive voice as a tool to
| avoid responsibility."
|
| The author's name doesn't come into it, and there is no
| reason to transform "does not dismiss" into the much
| stronger "promotes".
| yesenadam wrote:
| > "Style: Towards Clarity and Grace"
|
| As I was typing in "Style: Towards Clarity and Grace" I was
| thinking _Huh? Wouldn 't "Toward" be much better?!_ And indeed
| that's what it is. Made me feel good about my copy-editing
| potential.
| awillen wrote:
| Back in high school I was the copy editor for the paper (and the
| minutiae of AP style are still seared into my brain), and it's
| definitely been a useful skill. My first job was doing developer
| marketing, and we had a lot of devs that were happy to contribute
| to our blog but didn't feel their writing was great - a lot of it
| was just little grammatical and style stuff, so my being able to
| clean it up really encouraged them to work with me on creating
| content.
|
| That said, I think that reading a book on copy edit just to be
| able to edit your own stuff is a little bit of overkill. You
| don't need a deep, sophisticated knowledge of grammar - something
| like Strunk and White's Elements of Style will cover the grammar
| stuff you need while also helping to offer a little bit better
| sense of bigger-picture writing style.
| CapitalistCartr wrote:
| Strunk and White's Elements of Style is trash; don't buy it,
| don't read it, don't follow its advice. Read this first:
|
| http://www.lel.ed.ac.uk/~gpullum/LandOfTheFree.html
| WilTimSon wrote:
| Knowing how to tighten the screws on a text is essential for a
| lot of workplace communication, especially if you're trying to
| get something from your higher-ups. Don't think everyone is going
| to take their time to become a _great_ copy editor, but it pays
| to learn the craft at least a little.
| staysaasy wrote:
| My team went through a major shift a number of years ago, moving
| most complex discussions to written documents (with commentary!)
| wherever possible. The outcomes were great and fwiw we had a
| minimal remote culture pre-pandemic, people would write things
| down even if they were sitting next to each other. In particular:
|
| - It's much easier to track the provenance of complex decisions.
|
| - Deciding in docs reduces meeting bloat.
|
| - It's harder to get pissed at someone based upon a document.
|
| - Anecdotally, points of view seem to be better thought-out.
|
| This article made me think of how we should remember to try as
| hard as possible to adjust for variation in writing skill. I also
| wonder whether we're inherently biasing against people who are
| _slower_ writers.
| kqr wrote:
| As the joke goes, "an author is someone who wasn't good enough at
| writing to become an editor."
| cafard wrote:
| You need to be the reader's advocate, to try to set aside your
| ego and read your work as if someone else wrote it. This is not
| substantially different from adjusting your code. One might argue
| that with code you have also a very demanding reader, the
| computer, which might fail to run it or wreck something. Still
| you are writing for a human audience.
| msla wrote:
| Computers demand formal precision, which is different from
| conceptual clarity. Every obfuscator (including optimizers)
| relies on this fact.
|
| Good code has both formal precision and conceptual clarity.
| mewest wrote:
| I was lucky enough to have Prof. Regehr in my masters program. If
| he says these are good books to look into to improve your
| editing, trust this guy, he is as good as they get. _Now edit
| this comment for practice!_
| aaroninsf wrote:
| Pro tip, from an actual pro: you can't copyedit your own copy.
|
| Lots of reasons why, including, your inability to recognize
| problems you are unaware of; the inexorable fact of reading what
| you think you wrote, not what is on the page; inability to see
| logical problems, missing assumptions, etc. Ad infinitum.
|
| There are line-level hacks which can help with some of this, e.g.
| reading backwards to find typographic and spelling error...
|
| ...but there is no general solution.
|
| Suggested fix: find a professional peer and become their formal
| editing buddy. Define terms and scope, this is not peer review-it
| is simply copy editing.
| gaogao wrote:
| I actually use the backwards hack for code review too.
| velosol wrote:
| I agree but have found that I'm better at copyediting my own
| copy the further I am from it. If I wrote something in the last
| week I might as well be a spellchecker. If I wrote something
| last month I will catch more things but not as much as if it
| were someone else's writing. A year or more and I start to ask
| "Who on earth wrote this like this?!" :) .
| eequah9L wrote:
| > reading backwards to find typographic and spelling error...
|
| Ha, nice, I will try this out.
|
| > find a professional peer and become their formal editing
| buddy
|
| Yeah, teams should have a review system for documentation, like
| they certainly have one for code review.
|
| In practice, with many non-native English speakers in the team
| (100% in my case), this is something of an issue. But we do
| what we can :)
|
| What tends to help me with long-standing documents in
| particular is to reread them after some time passes. A couple
| months down the line, I have lost much of the context, which
| makes it easier to spot problematic bits. I am also not
| invested in the text as much, which makes it easier to rip out
| the parts that have not aged well.
| chadly wrote:
| Something I've known for a while (but have really come to terms
| with more recently) is just how important writing skills are even
| for technical people (even coders). It's hard to get anything
| done if you can't convince people why they should listen to you.
|
| Especially in this increasingly remote-connected world, writing
| skills are key.
| carlmr wrote:
| >how important writing skills are even for technical people
| (even coders).
|
| Especially coders. Writing clear programs is a lot like clear
| writing. A function is like a paragraph of a text. It should
| meaningfully abstract one concept of your higher level logic.
| It should be introduced by a clean input from the previous
| "paragraph", and produce an output that is the input for the
| next "paragraph".
|
| If your higher level function becomes too large, you can create
| larger structures like sections in writing.
|
| Having this ability to mercilessly copy edit, paring down your
| functions to their core concept and putting them into
| meaningful context is really useful if you want others to
| understand your code.
| tom_mellior wrote:
| All this that you write about code is correct, but I think
| you are missing the parent's point. Coders also need to be
| good at writing _non-code text for humans_. There is
| documentation to be written, and bug reports, and proposals
| for new features, etc. I have colleagues who are brilliant
| developers, and when they propose something I 'm sure their
| idea is technically sound, yet often I don't understand what
| they are trying to say because their writing is much poorer
| than their coding.
| carlmr wrote:
| I wouldn't say I'm missing the point. I agree that coders
| need to know how to write text. My point was that for
| coders writing is not the thing you do on the side, coding
| itself IS writing.
|
| That's why I said that "even" should be "especially".
| [deleted]
| Wistar wrote:
| NYT's "Copy Edit This" quizzes are quite good.
|
| https://www.nytimes.com/search?query=%22copy%2Bedit%2Bthis%2...
|
| https://www.nytimes.com/interactive/2016/11/11/insider/copy-...
___________________________________________________________________
(page generated 2020-06-25 23:00 UTC)