Post History
The only way to really expand your vocabulary is to, when you find that you need a word which does not immediately "come" to you, look for an appropriate word in reference works. Go grab a thesauru...
Answer
#4: Attribution notice removed
Source: https://writers.stackexchange.com/a/6711 License name: CC BY-SA 3.0 License URL: https://creativecommons.org/licenses/by-sa/3.0/
#3: Attribution notice added
Source: https://writers.stackexchange.com/a/6711 License name: CC BY-SA 3.0 License URL: https://creativecommons.org/licenses/by-sa/3.0/
#2: Initial revision
The only way to really expand your vocabulary is to, when you find that you need a word which does not immediately "come" to you, look for an appropriate word in reference works. Go grab a thesaurus, an encyclopedia, a dictionary, or some other reference work (or refer to ones online), and look it up. Then, get a feel for the meaning of the synonym (or antonym...) that you have found, work it into your text, and perhaps mull it over for a bit. Flag it somehow (different color, a column note, whatever) and go back to it later. Read it again. _Use_ the word in question. No one is born with a complete understanding of a language. I think it's safe to say that everyone uses various reference works now and then. Most people learn a language by being exposed to it. Why does it make you sad when, when you use an uncommon word, the person you used it towards _asks_ what it means? Would it make you feel better if they _assumed_ some, quite likely incorrect, meaning of the word in question? Referring to a reference work while writing does not mean you cannot use words that your audience is unlikely to know by heart. If, as you say, your audience is open to putting your book aside and referring to a dictionary or thesaurus just to understand the message you are trying to convey (which, if nothing else, is going to be quite inefficient), then what problem does your doing the same to find those words pose? If you do so repeatedly, those less common words should start coming to you more readily as you are writing. _But I am betting that there are ways you can work the details into your writing in a reasonably efficient manner which will not require the reader to have a reference work right next to your book in order to understand your message._ I work in the IT field, specifically programming. There is probably a million ways to write code in just about any programming language that makes it difficult for a fellow human to understand, while still being perfectly comprehensible to the computer. There are even _contests_ for that! Programming languages and software development frameworks these days are such huge behemoths that nobody can be expected to know all of it. _Lots_ of C-style-language (C, C++, Java, C#, ...) programmers don't understand the ternary operator (`?:`). I've had coworkers balk at the C# null-coalescing operator (`??`). It took me a while to get a good grasp of generics. Start talking about the precise difference between prefix and postfix increment/decrement inside statement execution and far too many are going to look at you like you are delusional. None of this means you shouldn't use them when appropriate; they are all extremely useful language constructs. But if you write a five-levels-deep ternary operator expression involving null coalescing, implied operator precedence, implicit conversions between types, uncommon operators and Heaven knows what else, _when something simpler would do just as well_, then you _are_ going to annoy people who try to read and understand the intent of that code because they are going to have to refer to reference works all the time, or use a major portion of their mental or physical whiteboard, just to figure out how the blasted thing works. _The same goes for natural language writing._ Programming languages are just a very formal set of languages, with precisely defined semantics, grammar and syntax. In natural languages, ambiguity is commonplace. In a programming language, any ambiguity tends to be either a compiler/interpreter (lexer, mostly) bug, or specification oversight.