practicing clarity — is this a form of sanity?

It’s hard to know where our professional persona ends and the rest of our bodies and minds (and souls, I guess) reside.

This presupposes that there is indeed a difference between who you are professionally and non-professionally.

In my case, this presupposition feels true on almost every level of my being.

For example, in my role as technical writer, I am constantly challenging my investment as a writer. I write and read all of the time — at work, at home, not at home not at work. Mostly fiction. Journaling all of the time.

So where does technical writing fit into this otherwise literary world? Here: somewhere between clarity and ambiguity.

Start with Clarity

I make a living doing only one kind of writing: creating technical content for developers, as well as other professionals who need to understand the technical nature of what my company offers. I make an effort to write in a language that anyone can understand, without dumbing down the material. Otherwise, I’d lose my main audience (developers).

However, I do try to write so that anyone can kick up their feet and enjoy reading my texts as long as they are OK with other signs of life on the page, such as code, diagrams, (some) technical jargon, and bullet points. That’s because the overall framework of the documentation I produce contains a sort of storytelling and uses everyday language to speak clearly and passionately about technology.

I write technical content with joy, first of all because I love writing, but secondly, in all my writing, clarity is key. Clarity reigns even when I am engaged in fiction or journaling or blog-journaling as here, where the material travels in and out of my rather active day-dream state. I consider all writing a process of making complexity clear.

Add some ambiguity

Making complexity clear in all its glorious goo is not only fun but necessary. But clarity does not exclude ambiguity. In my non-professional writing, I like being intentionally vague and filling my writing with loads of potential but unresolved meaning. I consider ambiguity as the best way to represent the false and unfounded but mostly true stuff that I encounter everywhere in the world, all of the time. (That may be just me, though..)

For me, acknowledging, writing down, and indeed creating ambiguity is a sure-fire way to get close to the real — and the clear.

But I would be a fool to believe that developers need ambiguity when reading about how to write great applications.

In my professional day job, therefore, ambiguity serves no purpose, or no apparent purpose. But I am a firm believer in that even in the most functional of writing, one must at least raise the ambiguity before undertaking a new assignment. There is no better way to know whether what you write will indeed be clear or complete or accurate. It will also help you contain an unconstrained, runaway idea liable to multiple interpretations, which can undermine your whole project, as well as create loads of support tickets.

Finish with empathy

Without knowing where ambiguity ends and clarity starts, how otherwise would you assess what your developer-readers’ are understanding or thinking about when they read your texts? How can you empathize with their confusions? We speak of being “concise” concise in technical writing, but concision does not, on its own, undo ambiguity. Otherwise it’s a dental incision — cutting too close, and cutting where it hurts.

Ambiguity and its resolution creates a warm, cosy clarity

Well anyway, like I said in the beginning, it’s hard to draw a line between the professional and the personal, especially when that line defines who you are within the highly-contoured world of your company’s products and bottom line — a line that often separates us from the rest of our tendencies …

But practicing clarity, as a form of sanity, makes it all seem OK to switch between the two.