I’m a Technical Writer, I Translate Machines for Humans
Based on Wikipedia:
A technical writer is a professional information communicator whose task is to transfer information between two or more parties, through any medium that best facilitates the transfer and comprehension of the information.
Sounds exciting? No, I know…
Nevertheless it is, and I’ll show you why, because… yeah, I’m a technical writer!
In just two words there are three worlds and more
There are three worlds to discover when it comes to the pair of words technical writing.
First world: technical. That’s not just a world, it’s an era, indeed. We live in the era when even dreams are surrounded by some sort of technology. That means that technology is no longer just a tool to do something, but it’s the way we think and feel life.
Second world: writing. Writing is a technology, perhaps the most impacting technology ever: it’s so ancient and settled in our perception that it’s transparent, powerful and obvious at the same time.
Third world: English. Trivial to say, technical writing is a pair of English words, and that’s not something random. In fact, English is the intermediate language across the planet: no matter the language you and someone else speak, if you both know English you are able to communicate each other. English is indeed the language in between, a sort of meta-language.
And more.
Technical writing engages in a game-changing communication challenge: the dialog between machines and men.
The purpose of any technical documentation, even the most trivial instruction manual, is, in fact, making a man able to successfully use a machine.
A technical document is, in a way, the machine that tells a human being about its behavior.
My experience as a technical writer
I love to think I’m a translator.
As a technical writer, my goal is to translate the language of a machine into the language of the needs of the users that the machine was designed for.
That might sound boring, and actually often it is, and tough.
But building a bridge, too, is somehow boring and tough. Nevertheless, when you realize that this bridge connects two places that otherwise would be unreachable from each other, in that moment a new feeling arises.
That’s what happens when I publish a new technical document: I feel that the service I wrote about and the user of that service are now connected.
That feeling is that of a destiny that has been fulfilled: machines getting closer to men.
Think of someone, let’s say Jack, that needs to solve a problem, and think of a service MyService (or a machine, or a software… no matter) that solves that problem. Well: Jack speaks the language of his problem, MyService speaks the language of a solution to that problem. The technical documentation that comes with MyService is the Rosetta Stone between those two languages.
The destiny of MyService is to solve the Jack’s problem: the technical documentation makes it possible. That’s the fulfilled destiny.
Technical writing is NOT easy
There’s on Medium an extremely useful publication called Technical Writing is easy: its content is valuable, I love it, but I totally disagree with its name.
The main reason that makes technical writing difficult is that it requires the sensitiveness for clarity.
When you describe something complicated to the audience that needs to get value from that complicated something, that’s a balancing exercise, between simplicity and completeness. You can learn how to be simple and how to be complete, but the balance of the two that leads to clarity is beyond any process you can mechanically execute: that’s sensitiveness.
All that makes the technical writers some translators, who cannot limit their endeavor to find correspondences among words of different languages, but must take care of the meaning that those words bring into the page.
In addition, there is a peculiarity that makes technical writers also different compared to the “ordinary” translators.
Translators connect human beings speaking different languages, while technical writers connect machines, or services, or pieces of software (anyway something not human) to some human beings.
Sounds easy? I don’t think so.
The curse of knowledge
Even more difficult, there’s a tough impediment that technical writers need to overcome: the curse of knowledge.
When you know something, you tend to assume, more or less consciously, that everyone else knows the same: that’s the curse of knowledge. It’s a bias that is based on not taking care of everyone else, but you.
Instead,
To write effectively for users, you need to understand who they are and what they want to achieve.
as Docs for Developers: An Engineer’s Field Guide to Technical Writing well highlights.
It’s about getting rid of the ego inside each of us, and opening our minds towards those other minds that don’t yet know what we know.
Conclusion
At the end of this journey around my thoughts as a technical writer, I feel I’ve put on the table the richness that this kind of writing brings.
Among the many facets I’ve mentioned of technical writing, the one I want to conclude with is the translation one.
Go beyond the appearances: machines are, and will more and more be, so present in our lives that we need to seriously start a dialogue with them. And that requires translators, from machine to man: the technical writers, indeed.
