My experience suggests that engineers do a lot more writing than the rest of the world realizes. We had a saying where I worked that the engineering effort was not complete until the documentation outweighed the final product. At one time, I was writing (more like typing) so much material for system specifications, proposals, and trade-off studies, that I actually developed an unpleasant case of acute tendinitis. To be fair, the tendinitis was not so much a function of the amount of writing I did, but more a function of the layout of my workspace. Eighteen months of physical therapy and reading everything I could find about ergonomics taught me how to continue writing without hurting myself.
As a boy, I recall hearing how my father was in the top of his class for math and science, but that he was also in the bottom of his class for writing and language. His teachers passed him through the language courses because they figured he would get by fine on his technical skills and would not need to know how to write well. How wrong they were. I remember sensing his frustration that the skill he was most weakest in, writing, was the one thing he had to spend significant portions of his time doing to produce specifications, interface documents, and data analysis reports.
Jon Titus has been writing about how engineers can write better, and I suspect he will be posting about this topic a few more times. Jon offers a nice list of types of writing that engineers might need to engage in, such as status reports, technical articles, application notes, marketing material, manuals, instructions, proposals and justifications, as well as blogs or columns. I would like to expand on that list and include logs or lab journals, specifications, as well as design justification and review documents.
Ambiguity is unacceptable in most of these documents, and as a result, engineering writing can exhibit structures that language majors find humorous or frustrating. I know that when I transitioned to article writing, it took me some time to adopt an active voice rather than a passive voice. Even then, there are times when the passive voice just makes more sense. I found an article that discusses the passive engineer in a useful fashion. What I appreciate about the essay is that it avoids being dogmatic about never using the passive voice, such as when you want to emphasize results or the actor is unimportant to the concept you are communicating.
I would like to uncover whether my experience with writing as an engineer is niche to the aerospace market or if engineers in many or all other fields also engage in a significant amount of writing. What kind of writing do you do as an engineer, and what percentage of your time do you spend doing it? Do you consider yourself a fast writer or a slow writer?
Processor Tracker
All Entries RSS Feed
I was hanging around as my sons attended a Communications merit badge workshop and realized that communication, usually written communication, is an engineer’s primary function. We spend a little time determining what is the right approach to a questions and the rest of our time is spent explaining it to others: What is this best approach; details of how to apply this best approach; why this is the best approach; and answering challenges to our determination of the best approach. The engineer doesn’t build the bridge or assemble the black box, he has to tell others how to do so. He doesn’t pay for the building or SW application, he has to convince others to do so.
It’s hard to quantify how an engineer’s time is allocated between problem solving, writing about it, and talking about it, since the three legs of the stool support each other. When you catch your reference guy in the hall and ask for clarification on how a certain part works, are you problem solving or verbally communicating? When you are performing a peer review and ask if a certain paragraph is clear, are you talking or writing?
I’ve been developing firmware for 25 years and I find that I spend at least as much time writing verbiage as I do writing code. My writing includes proposals, specifications, status reports, technical correspondence (email), and the often overlooked code documentation (comments in the code).
I take my writing very seriously and I am meticulous about it. However, in the engineering world, I find I am the exception. My point is not that I’m a great writer. It’s that I take the time and effort to communicate clearly. Most engineers simply do not expend that effort in their writing.
Much of what I read from other engineers falls into two categories: 1) prose that is overly wordy in order to ‘sound’ sophisticated, and 2) text that says nothing and simply fulfills an obligation to write a document. Both of these scenarios produce worthless documents that waste the employee’s time and the employer’s money.
I’ve also found that engineering prowess does not translate to comparable writing skills. I have worked with brilliant engineers who are practically illiterate. However, the contrary does not seem to be true. Very few of the incompetent engineers I have encountered turned out to be great writers.
Engineering expertise may be an innate talent, but competent writing skills certainly are not. It just takes a bit more time and effort than most engineers are willing to offer.
A lot of what we do is writing and it is getting worse all the time: every new layer of ISO/CMM/SPICE means more documentation, both to define the process and to show that we followed the process.
S., you say you’ve worked with brilliant engineers who were practically illiterate. I never have; some were better writers than others but most were pretty fair. If they were poor writers, they tended to be poor engineers, too. And the best doc writer I ever met absolutely hated it! As you say, he took the time and effort to do it right (so he wouldn’t have to do it over).
My degree is in Mathematics (emphasis in Computer Science), with a minor in English (emphasis in Creative Writing, not Technical Writing) and I often mention this about my college days: as students often did (at least in those days), we’d sit around during breaks and discuss majors and minors. If it was in one of my hard-science classes, when I mentioned my minor was English, it was like, “Cool, have you had this class yet? What did you think of that professor?” In other words, the guys following the hard science curriculum more or less expected that we had varied interests and that often included the fuzzy subjects. I’ve since run into many engineers with background in writing, photography, music (lots of musicians), etc.
But in the English classes, when I mentioned that I was majoring in Math, you could practically hear their chins hit the floor. For those students, it was as if people in the hard sciences couldn’t understand the arts and people in the arts couldn’t do hard science (sadly, there’s some evidence to that effect).
Even coding is writing. It is in the category of communication. A segment of engineering where writing is not the principal aspect of the job is perhaps mechanical engineering, however, so much of that effort is done in CAD and those drawings require explanation that writing is important; just not principal. There is no doubt, though, that mechanical engineering is more ‘hands-on’; as is systems integration testing (verification / validation). However, the tests themselves involves writing (procedural steps) and the results and affects of performing the tests requires writing skills to effectively communicate; there just would be more time with hands on in the lab environment.
A. – I like your story. The best engineering minds in history were capable of blending art and science. Given the human condition, that requires a medium for exchange of information. Effective writing faciliatates that.
A significant portion of my business enterprise is music and entertainment production (www.wahallamusic.com). Systems engineering principals apply to the development, construction, and configuration of the accepted recording of a well-crafted song.
What I wrote most is design documents, and often it is written after coding complete
, the reason is always a tough project schedule.
One engineer I talked with recently explained his most difficult writing job: creating documents for production people based on his work with prototypes. Although engineers might see assembly of a connector as intuitive, most production-line workers don’t. And engineers know they need a certain size bolt, nut, washer, and lockwasher at Point A, but manufacturing people need a clear diagram and step-by-step instructions. Those instructions require not only good writing skills but the ability to explain details in fundamental ways that ensure the proper assembly of components. Writing instruction manuals presents its own types of writing challenges. –Jon Titus