The nature of NASA technical writing is that if you hang around long enough, you usually end up writing for scientists and engineers. One thing became clear to me, at least regarding NASA people: scientists and engineers are NOT the same kinds of people, nor is their content the same.

Rather than generalize overmuch and get myself into a heap of trouble, I’ll just make some measured observations of my experiences with these two groups. Perhaps this information will be of use to you, perhaps not. Your call.

Writing for Engineers

I have spent most of my five-plus years at Marshall Space Flight Center (Huntsville, Alabama) writing for engineers. These are the folks who are trying to apply physical laws to human problems. They design things in what appears to be a very linear process (design, develop, test, evaluate, repeat until suitable for operations), but which is in fact rather chaotic and creative. Engineers are often a conservative lot. By that I don’t mean they’re all Republicans, though a fair share can be. What that means is that they tend to operate very empirically, are distrustful of wild claims (“marketing”), and have a healthy appreciation for Murphy’s Law.

One example of this conservatism appears in the designs they create to push electrons, make fire, or hold things together as they go hurtling through the sky at a few thousand miles per hour: they add something called “margin” to everything. So for example (this is not relating to any particular product, I hasten to add), the combustion chamber of a rocket—where the fire and smoke happen before shooting out the nozzle—might create an
internal pressure of X pounds per square inch. While X might be the theoretical maximum or “nominal” expected pressure, the engineer(s) designing the combustion chamber will add a margin of strength—what I call a fudge factor—on top of that to make sure the chamber doesn’t go explode—er, “dynamically disassemble.” All well and good, right? Well, that would be fine if it was only the combustion chamber engineers doing that. However, down the hall are the avionics guys, and they’re looking at the temperatures this rocket engine are likely to produce, and they’re thinking, “Our cables are going to melt!” so they add additional insulation to the cables to prevent them melting. Meanwhile, over on the other end of the machine, the guys designing the nozzle—the bell-shaped portion of the engine that points the fire and smoke in a useful direction—are also concerned by the heat of the propellants coming out of the combustion chamber, so they thicken up the walls of their nozzle so it doesn’t crack or melt.

At the end of this process, the Chief Engineer or Project Manager looks at the overall design of the rocket engine, sees the weight, and has a coronary because the bloody thing is now X pounds over specification. So the CE or PM (you get use to acronyms after awhile, it’s a way of life) tells the subsystems engineers to go back, “sharpen their pencils,” and reduce the amount of extra stuff so that the engine still performs its designed function,
but isn’t as heavy. The creative part comes in “trades” (tradeoffs) between margins of safety on this part versus that, and then making sure everything fits within the allotted mass, performance, and cost budget.

So how does the technical writer fit into this sort of culture? When I supported the Ares Projects, my primary outputs were papers for technical conferences, usually gatherings of other engineers. That audience was interested in what progress was being made, what sorts of technologies were being used, and how technical challenges were being addressed. The most important things the writer has to do are:

• Learn quickly
• Get the terminology/acronyms right
• Understand how the overall system works
• Understand what the individual parts of the system are and how they work

In a sense, the Ares technical writers became system engineers or project managers without the work or responsibility, which was actually a pretty sweet gig if you’re a space geek but lack the skills or temperament to be an actual engineer. But perhaps what I like best about writing for engineers is that there’s a certain logic to it: every part is designed by human beings with a human purpose in mind. You know why things are there and what they’re supposed to do.

Writing for Scientists

As with engineers, so it is with scientists: no two are exactly alike. They are there to observe the known universe, anything from bacteria to black holes, and figure out how they work. They require precision of a different sort from engineers and have a different understanding of, and tolerance for, vagueness or unknown-unknowns (“what don’t we know?”). The precision that scientists seek revolves around data and how it was captured:
what equipment was used, how was it calibrated, to what degree of precision, what is the margin of error?

Where things get creative for the scientists is in the formulation of theories to account for data that doesn’t fit an existing theory. To take a space-age example, galactic cosmic rays
(GCRs) are a type of highly-charged particles that had never been detected until we sent satellites into orbit because we are protected from them by the Earth’s atmosphere. GCRs originate from outside our solar system—we know this because they’re not coming from the direction of the Sun or the other planets—but the question remains: where did they come from? What creates them? Where are these GCR-generators, and how can they launch particles through space with such energy that they strike our upper atmosphere at nearly the speed of light? For scientists, the creative part comes in trying to develop theories that would account for all these questions and then in trying to develop a repeatable experiment that backs up the theory.

Scientists are inordinately fond of the question “Why?” If you have kids who ask that a lot, give them a science textbook. If they start wanting to do science experiments, you might have a budding scientist on your hands. If they start asking, “What is it good for?” or saying, “I can make a cool machine with that,” you’ve probably got an engineer. And if they keep trying to write down or explain what they learned to you, you might have a technical writer on your hands. 😉

As a technical writer in the scientific environment, I’ve noticed more emphasis on math than in the engineering world. It’s not that engineers don’t require math, but rather that math isn’t always necessary to explain what a machine or program is doing. By contrast, when writing a technical paper or proposal, scientists seem to require more math to explain or justify their approaches to particular problems. Another challenge when writing for scientists is that sometimes they don’t understand what’s going on, either—note the creative part above. I believe Arthur C. Clarke stated that “Eureka!” isn’t the sound of progress about to happen, but rather, “That’s strange…” In situations where the origins of a puzzle or outcomes of an experiment are not known, scientists are much more forgiving about the uncertainty factor. Often they just don’t know what’s happening, which is why they’re doing an experiment in the first place: to see if they can figure it out. Engineers want to know, with as much certainty as possible, how a test is going to come out, or they won’t proceed.

Lastly, scientists demonstrate their own form of caution when it comes to publishing results. They are more hesitant to propose a theory for the heretofore unexplained because they might be wrong. In this case, scientists and engineers (usually) share a common skepticism for “marketing” or hype. More often than not, they’ll say, “Let me see your data.”

Good, Bad, or Indifferent?

Human beings were performing engineering thousands of years before we had science. Science, as currently understood using the scientific method, has only been around for a couple of centuries. The rapid technological advances our civilization has seen since 1800 have been fed by our vastly broadened understanding of the physical universe and its laws. Both disciplines have need for skilled communicators who can make new discoveries or practices understandable to the taxpaying public or skeptical investor. The writing needs for each field vary, so where you choose to hang your tech writing hat will often depend on
what kinds of questions you like to see answered (“Why does it do that?” vs. “What’s it good for?”). I confess to a certain affinity for engineering. My friend Dauna, who writes for Science@NASA, is more inclined to the science side of things. Regardless of your “favorite,” the two subject matters are complementary, with each providing a unique perspective on the other, and it’s worthwhile to have the experience writing for scientists engineers. For the foreseeable future, these two professions will continue to lead the nation and the world in creating the future. It’s good to have a front-row seat.