The language of engineering
Translating thoughts and ideas during a construction project can be challenging, and it is imperative for engineers and workers to find a common ground to guarantee a project goes smoothly and safely.
“[Language is] really a pretty amazing invention if you think about it. Here I have a very complicated, messy, confused idea in my head. I'm sitting here making grunting sounds and hopefully constructing a similar messy, confused idea in your head that bears some analogy to it.” – Danny Hillis, "Back to the Future," TED Talk, 1994
Drawings can show size, shape, connections, arrangement, and quantity, but can’t describe operation characteristics, quality of materials and workmanship, and testing procedures. And while engineers can use building information modeling (BIM) programs to draw entire campuses in three dimensions—down to the last electrical outlet—and there are many programs that perform engineering calculations, much of an engineering project isn’t able to be illustrated or automatically calculated. This is where communication comes in.
Communication can be defined as the exchange of thoughts, messages, or information, as by speech, signals, writing, or behavior (American Heritage Dictionary). As Danny Hillis stated above, finding a way to communicate the ideas in an engineer’s head can be difficult since it depends on who is writing the note or specification, which must then be read and interpreted by someone other than the engineer who wrote it. Translating the thoughts and intentions of the engineer into easily understandable language that is comprehended as intended by all parties is extremely difficult.
These communicative barriers are compounded by the fact that in the United States, English is the standard language for construction contract documents but it is one of the most difficult means of communication. It has more exceptions to the rules than there are rules. Likewise, Americans often use terms in the English language that are not intended to be understood in their literal sense or according to their dictionary definitions.
Now consider the many individuals in the US construction industry who do not have English as their primary language and must depend on literal translations, which may or may not match the engineer's intentions. Not to mention that, as Peter Zak noted in his recent column in Consulting-Specifying Engineer, our industry is “becoming very litigious,” which is worrisome since engineers are not often trained as lawyers, yet they must produce legal, contractual documents that can stand up in the courts. Due to these discrepancies and growing pressures, courts must sort out differences of opinion about what is being communicated between the two entities. Also consider that those in courts who are responsible for sorting out these communication issues most often know nothing or very little about engineering or construction and, therefore, must interpret what is written literally. This is the complex nature of the "language of engineering."
Over the next several months, this space will be devoted to discussing the language of engineering. This won’t take the place of a course dedicated to specification or engineering writing, but it will address common issues found when project documentation requires text.
Some of the topics we’ll explore are:
1. Who your audience really is
2. Whether or not specifications really overrule the drawings
3. The 12-month correction period versus warranties
4. The catch-all (or CYA) statement
5. How to direct action versus describe quality
6. The use of performance and prescriptive specifications
7. Personal taste and how to avoid it
8. Structure (writing style and conventions)
Michael Heinsdorf, P.E., LEED AP, CDT is an Engineering Specification Writer at ARCOMMasterSpec. He has more than 10 years' experience in consulting engineering, and is the lead author of MasterSpec Electrical, Communications, and Electronic Safety and Security guide specifications. He holds a BSEE from Drexel University and is currently pursuing a Masters in Engineering Management, also at Drexel University.
Case Study Database
Get more exposure for your case study by uploading it to the Consulting-Specifying Engineer case study database, where end-users can identify relevant solutions and explore what the experts are doing to effectively implement a variety of technology and productivity related projects.
These case studies provide examples of how knowledgeable solution providers have used technology, processes and people to create effective and successful implementations in real-world situations. Case studies can be completed by filling out a simple online form where you can outline the project title, abstract, and full story in 1500 words or less; upload photos, videos and a logo.
Click here to visit the Case Study Database and upload your case study.