CHANNELING ANDY ROONEY

As an occasional watcher of the CBS TV news magazine 60 Minutes, I always enjoyed listening to Andy Rooney’s commentaries.  Andy would grumble about something or other that irked him at the end of the show in A Few Minutes With Andy Rooney.    

As a wordsmith specializing in construction documents, I see things that annoy me in the writing I review and edit.  Here are a few of my pet peeves:

Using the word luminaries (plural of luminary) when you mean luminaires (plural of luminaire). People mistake “luminaries” for the plural form of the word “luminaire”. When writing about lighting in the built environment, you need to use “luminaire” and “luminaires”, defined by Merriam-Webster as “a complete lighting unit.”  By contrast, a “luminary”, Merriam-Webster says, is “a person of prominence or brilliant achievement, or a body that gives light; especially : one of the celestial bodies.”

Leaving parentheses in text makes it look as though the text hasn't been edited or is still tentative. As in:

• “This Addendum consists of (2) pages (plus materials itemized herein).”
• “Provide (3) hard copies and (1) PDF copy.”

text in all lower case:  i see this a lot in blog posts and in comments to blog posts or news articles on the internet. i get the impression that the author feels it’s so critically important to get the ideas out of his head and into pixels that he just doesn’t have time to press the shift key to capitalize a word. i suppose this worked for e. e. cummings’ poetry.  i never understood poetry, anyway.  but it doesn’t cut the mustard for me.  see what i mean?

Cross-referenced specification sections that don’t exist in the project. Seek these references out and kill them.  All they do is confuse everybody.

“Do not use explosives”. A provision occasionally left in project earthwork specifications.  I’ve taken this out of our office master specifications. It’s totally unnecessary to say it, because almost no building projects have circumstances where anyone would even consider using explosives.  Leaving this requirement in a project specification is like admitting “I really didn’t read this spec, much less edit it.” Kablooie!

SPEC PROCESS

Preparing class materials for my spring 2012 semester portion of “Codes, Contracts, and Specifications” this weekend, I found myself comparing the old CSI Project Resource Manual to the new Project Delivery Practice Guide.  


In the Project Resource Manual, the product selection process, and by implication the spec writing process, is portrayed in a very neat, orderly, structured, idealized, one-step-follows-the-next, flow-chart-y way.


It would be nice, but a little boring, if the process actually unfolded this way much of the time for me.


Instead, construction document production is usually on such a tight schedule that drawings and specs have to proceed simultaneously, so the spec writing process is anything but a straight line affair. 


In order to edit even some of the simpler spec sections, it’s often necessary to look multiple times at constantly evolving in-progress drawings on the server, ask various members of the project design team lots of detailed questions, wait for answers, and draw inferences when drawings aren’t explicit or when product or design decisions don’t seem to be imminent.  Often it's necessary to go back and delete or add sections when the design takes an unforeseen direction. 


If anything, the trajectory of the process I’ve become accustomed to is less like a flow chart and more like the way a restless canine explores his territory.  


Like my Sheltie, Ollie, in the snow in my back yard this morning.