Drawing Parallels

Whenever I present a workshop on effective writing to colleagues from other teams, I try to dispel a stereotype about technical communicators: that we over-index on grammar and punctuation. I stress that the clarity of your message and the arc of your content are far more central to a document's success than perfect compliance with the rules of English, which are, let's be honest, pretty fluid. As collaborators and editors, we want to be carried along by your prose. Nit-picking the placement of your commas is not at the top of our list of priorities.

But--and you knew there would be a but--I usually go on to say that failure to obey nonnegotiable rules is a quick way to lose your credibility with an audience that can recognize your mistakes. A glaring error represents a hurdle before which readers will pause. And if the faults start piling up, some might ask: Just how competent is this person if they're letting howlers like these appear?

Among the rules that I consider "compulsory" are those that apply to placing apostrophes (when to write it's and its, for instance), making correct word choices (knowing the difference between principal/principle and affect/effect, for example), and writing parallel sentences.

Regarding the last rule, parallelism means keeping sentences balanced by applying the same grammatical structure to phrases or clauses that share a theme. For example, the sentence Michelle writes, edits, and reviews newspaper articles is parallel. The same verb form- --third-person present--is used for the three activities that Michelle performs as a journalist. A nonparallel sentence might read Gabriel laughed, cried, and was dancing during the wedding. The sentence contains a mismatch between the past participle (laughed, cried) and the past continuous (was dancing).

Failure to keep your sentences parallel can distract the reader from the message that you're trying to convey. Parallelism crossed my mind recently when I was reading about a programming language just released by [VERY LARGE SOFTWARE COMPANY]. Reading the introductory text for the product, I came across the following:

The goal is improved developer productivity, increased software quality, and enabling a range of new compilers and developer tooling experiences.

I narrowed my eyes. Surely [VERY LARGE SOFTWARE COMPANY] has competent editors to catch such an obvious misstep? Then I doubted myself. Was it really not parallel? But, read aloud, the sentence--with its two adjective-noun pairs interrupted by a gerund--sounded disjointed, clunky: the litmus test for missing parallelism. (And what exactly is a "developer tooling experience"?)

It's quick work to rewrite and rebalance the text to enhance its clarity. For example, you could go with:

The goal is improved developer productivity, increased software quality, and a better coding experience through new compilers and tools.

So what was an awkward sentence that may halt a persnickety reader (like me) in their tracks is now a line that flows smoothly and does a better job of explaining why we should care about this new language.