Thinking Like an Engineer, Working Like a Writer

This blog was inspired by a response to my blog regarding my readers in India. One reader, Amruta, wrote that she appreciated my help on thinking like an engineer. First off, thank you to Amruta (and the rest of you) for reading! I’ll try to make this entry as useful as possible. I’ve covered some of this ground before, but maybe other thoughts will occur to me as I go along.

A while back, I talked about the fact that I prefer writing about engineering rather than science. Part of this preference occurs because I’m fascinated by gadgets, and part of it is because engineering is inherently a human activity. You’re not trying to figure out how the universe works but how a human-designed tool (hardware, software, or process) does or will work. If there’s a human purpose in mind, you can get someone to explain it to you. In science? Not so much.

When I’m approaching a new engineering topic, I have to start with what I know. That might be quite a lot in the case of rocket propulsion or space architecture; it might be depressingly little, as in the case of writing about automobiles or biotechnology. Regardless of my starting point, the most important thing for me to understand is: what is this widget/technology supposed to DO?

I’ve written elsewhere that often I use an airline route structure in my head to help “connect the dots” of my content to places I’ve already been. “Oh!” I think as I read, “This connected to X.” Or I’ll find an analogy in the work: “This part of the system functions like a radiator.” Or I’ll fall back on actual technical knowledge of the physical universe: “This widget is dissipating heat.” The most important tools I have at my disposal are science/technical knowledge, analogies, and logic.

Scientific/Technical Knowledge

Science, technology, engineering, and math are not for everyone. People dislike them or aren’t interested in them for any number of reasons–bad at math, perceived lack of socializing (or social value), bored by numbers, impatient with lab work, etc. As it happened, I grew up with an interest in science and engineering, which was helped along by parents, teachers, and my own reading–science fact and fiction. I had enough interest to be fascinated by what technology could do, but not so much interest that I wanted to do the work myself. As a result, I’ve learned just enough to be able to write about rockets, spacecraft, etc., to be useful but not so much that I’m dangerous (trust me, no engineer with a grain of sense lets me touch the rocket). I write about engineering topics for non-engineers, for the most part (politicians, legislative staffers, and that ever-elusive “general public”). If I have to write for other engineers, I need to delve further into the weeds and learn more vocabulary, acronyms, and actual science.

You can pick up quite a bit about how your hardware or software works just from watching it in action or by talking to the people designing and building it. However, if you’re interested in broadening your skill set and general fund of knowledge about the sci/tech world, you can try the following sources:

National Geographic
How Stuff
Popular Science/Popular Mechanics
Discover Magazine
Science 2.0

A good set of encyclopedias–harder to come by these days, but is not always reliable.

I got started on the science path reading Tell Me Why books as a kid.

A friend got me the Engineering an Empire series from The History Channel. It’s a treatise on architectural technology and how people built things throughout history.

The Great Courses has some interesting content….

In any case, there are some good books and sites out there that you can read or shows you can watch that make science education non-boring.


As I’ve written elsewhere on this blog, science fiction is an excellent form of mental training for the aspiring technical writer. The primary reason is that SF writers take the reader–usually via the viewpoint narrator–through an unusual environment or technology in a literary fashion, often using different analogies, similes, or metaphors for explaining how that environment or technology works. Consider this description of an alien’s view of time from Kurt Vonnegut’s Slaughterhouse-Five:


Or Arthur C. Clarke’s description of “superspace,” from which he postulated a near-light-speed propulsion system in The Songs of Distant Earth:

No one could really imagine a millionth of a centimeter, but at lest the number itself – a thousand thousands – was familiar in such human affairs as budgets and population statistics. To say that it would require a million viruses to span the distance of a centimeter did convey something to the mind.

But a million-millionth of a centimeter? That was comparable to the size of the electron, and already far beyond visualization. It could be grasped intellectually, but not emotionally.

And yet the scale of events in the structure of space was unbelievably smaller than this – so much so that, in comparison, an ant and an elephant were virtually of the same size. If one imagined it as a bubbling, foamlike mass (almost hopelessly misleading, yet a first approximation of the truth) then those bubbles were…


…of a centimeter across.

Again note the effort to tie the unfamiliar to the familiar. You won’t always have that opportunity in technical writing; however, it’s important that you can at least think in familiar terms as a way of helping you navigate the mysteries of whatever job has been put before you. And because you’re dealing with complex topics, it’s important that you try to use the simplest, most straightforward language you can.


I’m using “logic” rather broadly here, but what I’m trying to convey is using your reasoning to visualize how the various pieces of a particular technical puzzle fit together. In the same blog where I talk about using the airline route structure mentioned above, I also discuss how it’s important to do your own analysis of the content you’re given to understand how words and concepts are used in your given topic. For instance, after quite a bit of time reading various technical reports and reviewing schematic diagrams, I learned “rocket science” by understanding it linguistically. Which words are the subjects? Which words are the verbs? Which ones are the objects? What parts are performing specific types of actions upon other parts of the system? What is the outcome when those actions are performed?

If anything, my learning of propulsion systems came about through the logic of linguistics and storytelling: you start with a cold engine at the tail end of a rocket on the launch pad and you end with that engine firing hot gases out the bell-shaped nozzle at the back and and launching the rocket into space. What are all the actions that have to happen in between to make the beginning and the ending fit?

English literature major tricks aside, logic helps you best organize your information into a format that makes sense to you and the reader. Are you talking about a process? If so, you want to arrange your information chronologically. Are you describing a different collections of objects? Perhaps you’d be better off describing them by function, size, or location. Your writing needs to have a flow that makes sense to you but also makes sense to your reader. S/he will have a specific use for the information you are sharing, and that, too, needs to be taken into account. You might want to tell the history of your product and how proud you are of all the hard work that went into making it; however, the user just wants to know how the blamed thing works.

Concluding Thoughts

Amruta, I hope you found this useful. As I have other ideas on the thinking behind technical writing, I’ll continue to share them. I am very structure-focused in my approach. I like to bring order to chaos–which is sometimes that’s exactly what’s handed to me; once I have my structure, the detailed writing follows from there. A document filled with prose to match Hemingway and grammatical precision good enough to make Strunk and White weep with joy won’t matter a whole lot if I don’t know what story I need to tell my reader. That’s true no matter where you’re writing.

About Bart Leahy

This entry was posted in audience, blogging, engineering, philosophy, science fiction, technical writing, Technology and tagged , . Bookmark the permalink.

3 Responses to Thinking Like an Engineer, Working Like a Writer

  1. Amruta says:

    Bart, this is the best New Year’s gift I have ever received! I had reached the limit of self-motivation and trying to figure out the way to do this job on my own, since this is one of the rare gigs..and your post is just what I needed! Excellent tips that I can’t wait to try out! Thank you so much! Have an amazing 2015 :):)

  2. Doc Ezra says:

    For a couple of additional resources for the “self-educating,” I highly recommend browsing the available offerings at OpenCulture ( and checking out some available (and free) courses via Coursera (

    A pleasure to read as always, Bart. 🙂

Leave a Reply
