Last week, after a nine-year journey, NASA’s New Horizons spacecraft reached its destination and started sending back images and other data about Pluto and its moons. In their news conferences, the NASA scientists are practically giddy with excitement — as well they should be. The images have been breathtaking.
These images are just the first taste of what’s to come, however.
Aimed at earth from 5 billion kilometers away, the signal from New Horizons is understandably weak. The bandwidth for the downlink is so limited (1,000 to 4,000 bits per second – much slower than a 1990s dial-up modem) that it’ll take until the end of 2015 just to get the compressed data. It might take until late 2016 to get all of the data in full resolution.
In other words, we’ll have to be patient. Those of us above a certain age can remember taking pictures on vacation and then waiting several days for the drugstore to develop them. It’s going to be like that with New Horizons.
After all the data arrives, it’ll take a while longer for the scientists to interpret it and develop realistic theories about what’s going on with Pluto and the moons: their composition, geological activity, and so forth.
Until then, we wait. In spite of their excitement, the scientists are cautioning everybody not to jump to conclusions, even though they — as much as anyone — surely understand the temptation to do just that.
As a technical writer I know about the temptation to jump to conclusions.
My mind loves to connect the dots and make conjectures. After talking for five minutes with a subject-matter expert, or after reading one page of a design spec, I often say “aha!” and feel like I have the understanding I need to write the documentation. I want to run to my keyboard and start banging it out, while the fireworks of insight are going off in my brain.
But in fact I only know a tiny bit — just like those pictures from Pluto tell us only a tiny bit. Another five minutes with the SME, or another couple pages of the design spec, and I begin to see some of the nuances, some of the layers of complexity in the subject at hand. “Aha!” turns to “hmmm….”
I realize that the software doesn’t always work this way — only when certain settings are in effect. The instrument displays data one way for chemicals and another way for blood sera. What the end user sees depends on a whole host of factors.
Imagine what would’ve happened if I’d yielded to the temptation and begun writing the documentation after those first five minutes. I’d have to make a lot of edits, for sure. More likely I’d have to rewrite it completely, or throw it away and start over. (In my career I’ve done all three, incidentally.)
So, even in our deadline-driven world, technical writing demands that we be patient. Resist the urge to start writing at the first “aha!” moment. On the other hand, don’t succumb to the “paralysis of analysis”: not starting to write until you understand every last nuance. Part of the technical writer’s skillset is knowing the art of when to wait, and when to start writing.
Have you ever written documentation before you had the full picture? What happened?
How have you learned to practice the art of patience while not succumbing to the “paralysis of analysis”?