Speaking of writing, I have neglected this blog lately, as I have been caught up in too many other things, but I would like to get back on track. Today’s post isn’t related specifically to metadata or information management, but it’s a topic that is very close to my heart, namely, the art of writing. I have been fortunate in my life to have been formally schooled for many years in the grammar and syntax of a number of languages. The quality of writing in so many environments does appear to be declining, and I certainly see this in many of the assignments that I receive. While problems with grammar and syntax are common and, unfortunately, on the rise, the bigger matter is the ability to communicate clearly and concisely.
In this post, Glenn Leibowitz’s discusses his frequent encounters with writing that is loaded with jargon, clichés, technical terms, and abbreviations. Leibowtiz asks: what is the writer trying to say, exactly? And second, how can the writer convey her ideas more clearly, without having to lean on language that confuses the reader? Leibowitz discusses psychologist Steven Pinker’s belief that the root cause of poor writing is the Curse of Knowledge, which he defines as “a difficulty in imagining what it is like for someone else not to know something that you know.” I encounter this phenomenon frequently in academic writing; as a reviewer of manuscripts, I have often found it necessary to ask authors to provide further clarification of pivotal concepts or ideas they discuss. When marking papers, I often remind students to be wary of assuming prior knowledge on the part of the reader. This situation can be remedied relatively easily by the provision of simple explanations.
Jargon, on the other hand, is more insidious and difficult to deal with. Jargon is particularly rampant in the business environment, and I encounter it frequently from some colleagues in my faculty. There have been a number of articles about the pervasiveness of jargon and “management speak.” This post suggests that jargon may be a means of validating the importance of the work; further, when we replace a specific task with a vague expression, we grant the task more magnitude than it deserves. If we don’t describe an activity plainly, it seems less like an easily achievable goal and more like a cloudy state of existence that fills unknowable amounts of time. This post suggests that jargon is used for two reasons:
- Technical. In this case, you have a specific highly technical area where jargon helps communicate more clearly, efficiently and effectively (within the technical community).
- Posturing. Here people choose to use language that prevents others understanding what they are saying. The word ‘evasive’ is used a lot in connection with this type of jargon.
This post provides useful tips for how to avoid jargon:
- Try to think of a different word. If you can’t come up with one, try harder. If you still can’t think of one – Google it.
- Think about your audience and what you’re really trying to communicate. Where are these people coming from? What are they interested in? Keeping these things in mind, how can you communicate your message clearly, simply, and effectively?
- Ask yourself if a fifth grader would understand it. That doesn’t mean you should weed out complexity, but think about simplifying language. Simple doesn’t mean stupid.
- Have someone who is not familiar with devspeak (development speak) read over your work and give you feedback. Eventually, you’ll start to learn which words make no sense, and which ones are OK.
I am crossing my fingers that this post does not contain jargon.