Listen to this post: You can download the MP3 file, subscribe in iTunes, or listen with Stitcher. Simple versus complex language My wife is in a master of liberal arts program at Stanford. When she writes an essay, she asks me to read it and provide feedback. Every time I review an academic essay, it reminds me of the stark differences in language. In tech comm, most of the more interesting, flavorful words she uses in her essay are off-limits for technical documentation. For example, here’s a smattering of words and phrases she used in her last essay: imposed didacticism pearlescent hues erstwhile acolyte progeny wanton placatory efforts intangible ephemeral uncannily evocative existentialist ideal of transcendence immanence blessed cessation of incessant demand litany emotional expenditures begrudge solicitous weather forecasts ebbed in bolstering travesty of symbiosis unfathomable pit of neediness modulating deputizing chivvy yonic staunching counter-narrative foisting catechism talisman culminatory inaugurated commodity promotional conventionality None of those words would be welcome in technical documentation. Instead, best practices for language in technical documentation are to use simple, unambiguous words that have one easy-to-understand meaning. You also use short sentences, small paragraphs, and frequent subheadings. Despite the technical writer’s attempt at simplicity, technical documentation struggles with its own jargon. In a topic I was working on last week, the following words might be just as challenging as the previous academic ones: Android Nougat Fire TV Generation 2 Android 7.1.2, level 25 Fire TV Edition backported Marshmallow Lollipop, or Android 5.1, level 21 uplevel permissions at runtime linking to private libraries normal and dangerous permissions declared in your app’s manifest revoke individual permissions single binary targeting multiple devices gyroscope permissions public NDK APIs Private API Picture in Picture (PiP) Content Recording Time-shifting APIs Apps & Games Services SDKs in-app purchasing parity with Nougat API level memory on load target devices Build.Model Build.VERSION.SDK_INT dependencies SDK add-on Imagine if you were to use academic language and technical jargon? That would be a one-two punch for incomprehensibility (though it would score a ten for comedic effect). The difference in style between academic essays and technical documentation isn’t anything new. But I’m a bit troubled by it. After working many years in tech comm, much of my wife’s vocabulary is no longer part of my lexicon. I’m constantly going to the dictionary to look up words when reviewing her essays. It makes me feel out of step with my English BA and MFA background. More importantly, in giving up these words, I have a sense of having lost something — my delight in language, in learning new words, and in reading and enjoying the eloquence of an author. Now when I read an author who uses more sophisticated language, I find myself asking, couldn’t the writer have expressed this in a simpler way? Why use that word instead of a more familiar one? My distraction with the language often poisons my attitude toward the content and author. This is especially the case when reading academic essays. I have to constantly remind myself that my wife is writing in a specific discourse community that expects complex, hard-to-read language. Comprise As an example of plain language versus complex language, let’s look at a specific word: comprise. From a plain language advocate’s point of view, is there ever a time you should use comprise? Probably not. In Wikipedia’s article on New England, the entry begins: New England is a geographical region comprising six states of the northeastern United States: Maine, Vermont, New Hampshire, Massachusetts, Rhode Island, and Connecticut. In technical documentation, a guide might use similar language: The system comprises submodules A, B, and C. But the question is