Journals by RSS
Journals by Email
You may have noticed that I’ve been missing in action lately—at least on Gryphon Mountain, anyway. A couple of related factors have contributed to this.
First, I’ve devoted a lot of my attention in 2011 to fiction. I’m most of the way through my second draft of a novel. During my two-week Christmas vacation a year ago, I wrote over 27,000 words of the first draft. This last vacation, I edited and revised my way through almost the entire second half of it in my second-draft effort. I’m trying to perfect my storytelling skills. Once I complete the second draft, I’ll be reading through it in as few days as possible, just making notes as I go as to what needs fixing. Then I’ll go back and make changes accordingly.
Those who have followed the Gryphon Mountain Tales may think this strange, seeing as I haven’t posted a new tale in months. I did promise an experiment, and the experiment proved that I’m not good at serial fiction. I don’t do well when I have defined only a vague overarching storyline. I’m not saying that the Tales have died; they’ve just taken a big break.
Focusing on a novel, not to mention trying to spend time with my daughter, has left much less time for blogging here than I’ve had before.
Second, I haven’t had as much to say about tech comm this year, or at least during the last several months. As I said, I think this is related to the first cause. My mind hasn’t been on tech comm as much as before, so I haven’t had as many ideas for blog posts.
I used to have this “blog lens” through which I would view much of my professional experience. Multiple times throughout the week, I would think, “That topic would make a good blog post,” and I’d make a note. However, in much of 2011, my subconscious has been working out kinks in my novel instead.
With all of that said, however, I do have something to blog about today. 
Part of the User Education team’s goals in 2011 was to have a team style guide finalized. I became the driver behind that effort. Mainly because of that, and probably because I’ve been doing a lot of writing and revising, the topic of concise writing has been on my mind.
A lot of the problem with common English usage these days is the padding. People insert words that don’t need to be there. Our wording isn’t precise. People feel like they have to add modifiers to their words to add importance or clarity when they don’t need to, resulting in redundancy and the weakening of the core idea.
Writers know that putting together a concise, clear message takes time. But I believe the first try would be closer to the mark—not to mention the final version—if we truly understand the language and use words precisely.
I’m sure you’d like an example. I’ll give you a couple.
“Return again.” What’s wrong with this phrase? Nothing, if it’s used correctly. Return means to come or go to a place you’ve been before. If you’re talking about returning the first time, the word already includes the idea of “being there again.” If you then leave a second time and come back, you are then in fact returning again. But most of the time, when I hear or read the phrase “return again,” the speaker or writer isn’t talking about a second time coming back, but rather the first.
“Each one.” This phrase is redundant. Merriam-Webster’s even shows one of the definitions of “each” to be “each one,” drawing on one of the other meanings of “each.” But when people say or write “each one,” they’re generally using “each” in the sense where it can stand alone meaning “each one,” making that “one” unnecessary.
I’m getting dizzy going in circles like this.
Anyway, my point with this example is that I don’t know if there’s ever a reason to say “each one” in speaking or writing. “Each” suffices.
These examples illustrate how easy and common it is in English, and perhaps other languages, to tack unneeded words on to other words.
To be precise in our writing, we should understand these nuances and then write, and edit, for them.
For technical communicators, precise language isn’t about persnickety grammarians with yardsticks ready to rap knuckles. Precise language means clear communication, less content for our audiences to sift through, and lower translation costs (where every word is an expense to the organization).
Precision is concision.
Note: If you find any unnecessary words in my post, let me know.
I wonder if there’s a tech writer out there—in the software industry, anyway—who would argue that being involved in the design stages of a project is a bad thing. 
When I was in elementary school, I learned that it’s pretty much guaranteed that when answering true-and-false questions, if the statement contains any absolutes, it’s false. Notice I hedged there a bit.
As you’re developing a help system and updating content, it sometimes becomes necessary to delete a topic file because the information is out of date or should be combined with other information. When you’re using both RoboHelp and Subversion, it’s easy to mess things up doing this. It’s important to delete the file in RH first to maintain its version of reality and lessen the hassle. But things have to be done correctly in Subversion too.