Blemished—but better—tech comm?
Consumers’ demand for perfect things drives a lot of pesticide use….Ninety percent of pesticide use in apple crops is to get the last five percent of quality of the fruit.
That comment near the end of an On Point podcast confirmed that accepting a few blemishes on an apple treated with fewer or no synthetic insecticides is a compromise I am willing to make. It also made me think more about a tech comm–related post I saw last week.
There have been more than 100 responses to a LinkedIn post in the Technical Writer Forum about whether one or two spaces follow the period at the end of the sentence. I suppose I should be happy that the tech comm community has active social media networks, but my response was a lot less positive:
100+ comments about # of spaces after period in #techcomm. http://t.co/Mn1BuKRfys Let’s get this fired up about biz aspects of content.
— Alan Pringle (@alanpringle) August 27, 2013
I’m skeptical that end users of technical content are that concerned about the number of spaces of following a period. The technical writers’ desire for writing that perfectly adheres to a rule is what’s “driving demand” in the case of that post. Tech writers are not the true consumers of technical content. The end users are.
I’m not advocating style guide–free writing here. Style guidelines are important because they are the foundation of consistent writing, which is easier to understand and translate. But style guides are a small part of what makes good technical content. Stylistically pristine content is useless if it is technically inaccurate or doesn’t address the audience at the right level. It’s also a waste if it’s locked away in a PDF file that end users can’t find online, for example.
flickr: ollesvensson
Technical writers are generally better writers than most, but we can’t let our writing skills be our primary defining factor. Being a good writer is just a prerequisite in tech comm today; you can’t sustain a career in this industry by focusing on writing ability and style guides as your areas of expertise. (Besides, there are now tools that can automatically enforce style guidelines. Keeping a solitary focus on style is particularly foolhardy when a tool can do it for you.) We also can’t project our need for excellent writing on the audiences for technical information. For them, stylistically “good enough” writing is often plenty enough.
Move beyond the mechanics of writing and ensure your content reaches your audience and gives them the answers they need. If the time it takes to make your content more accurate, accessible, and intelligent means there are a few stylistic blemishes—many of which end users won’t even notice—so be it.
I think it’s a worthy compromise.
P.S. I have a degree in English and worked as a technical editor for years. Style guidelines are probably floating around in my bloodstream.
About the author
Larry Kunz
Alan, from one English major to another: I absolutely agree with you. Perhaps part of the problem is human nature: we (tech writers) feel like we have a good grasp of the craftsmanship part of our work. The other stuff — Is it audience appropriate? Does it support the goals of the business? — is harder, perhaps scarier. Not to mention hard to quantify. (How do we ever know whether we’ve succeeded?)
The solution is to think like professionals rather than like craftspeople. When we write to support the goals of the business and the needs of the customers, we take our eyes off the tiny blemishes and see the big picture.
Tim Bombosch
Hi Alan,
I agree 100% with your comments, but I’d like to address the cost and time factor involved in that remaining 5% of quality. We tie up our resources far too long getting that final 5%. A tech writer’s value is not in the two spaces behind a period or the final Oxford comma in a series, but in the ability to communicate technical information. I want my writers adding real value, not style points, to an organization. The planned review processes required to get that last 5% (or worse, the endless unplanned reviews) are burdensome and wasteful.
One way to address this is through a quality management plan. This doesn’t mean “how do we achieve the most perfect quality,” rather, what is the quality standard we set for ourselves and what is the process to assure we meet that standard. Falling short or exceeding that standard is problematic. And I don’t see content organizations handling this dynamic well. The ironic thing, though, is that most product development organizations truly understand quality management, but they have not extended the concept to the technical communications.
Emma Harding
I agree with your post, and with your commenters. 100% perfection is not a goal worth striving for in an online age. TCs have got to stop tying up their egos in their opinion on the Oxford comma, and start paying more attention to important issues such as intelligent content that meets user needs, and enterprise content reuse. I don’t like style errors and spelling mistakes, but perfection comes at a ludicrous cost of both time and money.
And it’s one space after the period, period!
John Garison
I remember Bill Horton saying years ago: “A good document today is better than a great document some time next month.” There is a point of diminishing returns, but I’ve rarely come close to it because the pressure of delivering a good project sooner always superseded delaying the next white hot project until this one was perfect.
My 2 ¢
Karen Cameron
I definitely agree that accurate content is more important than a strict adherence to the style guide, and if we’re pushed for time close to a deadline, I’m going to prioritise creating useful content over getting documentation edited for style. But style guidelines can be very useful and important when it comes to translation. I’ve seen questions from translators about text that doesn’t comply with our guidelines and therefore causes confusion (for example, by using ambiguous words or omitting vital punctuation). So even if the English source is accurate and understandable, the translations might be inaccurate. And of course, we spend time answering those translation queries and making associated changes. So I think that it’s a balancing act. Perhaps it’s sufficient to be aware of translation issues as you’re writing, rather than rigidly following the style rules.
Richard Hamilton
By chance, I was drafting an STC Notebook article about style guides that makes the related argument that the greatest value you get from style guides is productivity, not quality. That is, every time you need to make a decision about style, you lose some time. The more decisions you can avoid, the more productive you can be. That argues for a style guide (and automated support through structured authoring), though I conclude it doesn’t matter what style guide you use (as long as it calls for the serial comma and one space after a period:-).
The article is at http://notebook.stc.org/publishing-perspectives-living-in-style/ and includes a reference to this post.
Vinish Garg
Alan
This post and the comments here about writer’s primary focus reminds me of the soldier who fights first for the countrymen, then regiment, then the battalion, and then for himself if left with any energy and choice. Same way, the writer writes first for the target audience, then for organization, then for the team, and then for himself if left with any choices whether to use single period or not.
And thanks for the reference to that LinkedIn conversation. it had been quite thought-provoking though this post gave it an altogether different direction.
cud
First of all, like all the rest, 100% agreement.
Ok, so why is this an issue at all? I blame it on TWIC — the Tech Writer Inferiority Complex. Tech writers are human language people surrounded by machine language masters — non-revenue producers surrounded by indispensable revenue producers — Humanities grads surrounded by engineers and economists. I think there’s a tendency to retreat to the known and sacred territory of style, usage, grammar, etc.
In the old days, when docs were on paper (yes, there were cars then), we even had an objctive argument — get in our way and costs will balloon. But we’re digital and agile now. In the absence of paper, Tech Com contributors need to fill the resulting void. That means knowing the product, knowing the audience, and knowing how to bring the two together. Obsessive focus on style does not fill that void, it just piles stuff around it, making it look wider and deeper still.
Karen Mulholland
Well said, Alan.
If our readers understand what we meant without having to read it over again, and they don’t get distracted from the message by the way we say it, then we’ve communicated successfully. Mission accomplished. Move on to the next thing.
John Crossland
I think this highly relevant for anyone working within an Agile or Scrum software development team. Engineers generally develop and test ‘good enough’ software, so we need to align our expectations accordingly for what’s good enough for us too.
I’d read a Gordon & Gordon ‘Technical Writing for the Real World’ book ‘Good Enough Documentation’ in 2002 (see http://www.gordonandgordon.com/201.html). This was heresy in 2002 with our striving for PMM (Publications Process Maturity) levels to match CMM (Capability Maturity Model) levels in projects run by PMI (Project Management Institute) PMPs (Project Management Professionals). Then our ‘in-house’ world changed with lots of outsourcing, offshoring, and virtual teams. Lots of MBAs worked out paying 1/3 of wages elsewhere paid bonuses & dividends.
When we work in projects run by CSMs (Certified Scrum Masters), I don’t think that we get to decide the quality of our publications any more. We can influence those who decide the quality, but outside of a publishing company that is in the business of publishing and selling publications, I think we need to meet expectations of the organization we work for first, which are usually accuracy, availability, accessibility.
Pete Wagner
Like everyone else, agree 100% wiht Alan’s arguments. I’m pretty certain that the two spaces after the period is a leftover from the pre-digital age. I had the two spaces drilled into me back in high school in my typing class (OK, now I’m aging myself), but once I started working with computers and read/realized that the extra space didn’t any value to electronically-authored content, I dropped the second space faster a press on the spacebar! 🙂