I doomed mankind with a free text editor
Morten Just

You make a good point about language, but you’ve missed the most important concept: Write for your audience.

Note that Orwell’s advice on word use included caveats “…when a short one will do”, etc. He didn’t say to never use them. Sometimes you need to be more precise. And as you learn new concepts through generalizations, if you want to improve your understanding you need more precise language.

The XKCD book is an excellent example. It’s an attempt to explain difficult concepts to laymen, and it succeeds on several levels. But this type of communication will not work for people already familiar with the concepts and that need to work with them more fully. It’s simply too imprecise. Brian Greene has published several books that are accessible to a mass audience. He is very good at explaining advanced physics to the layman. But he doesn’t use that same language in his academic papers — they are for a different audience and his language has to be more precise.

I see this all the time in the technical world. Some people become so immersed in the technical terminology, and “jargon”, if you will, they have a difficult time communicating with non-technical folks. It is difficult to explain some concepts without using the terms they are familiar with (or only have a basic understanding of), so they don’t even try.

BUT — that terminology becomes important within IT teams and between teams with different specialties. Because words matter, and language needs to be more precise. Just take the word “build”. To most people, they see IT folks “building” a system. But to developers, a “build” is when the compiler takes the code they have written and creates and executable program. What most people see as “building” a system is a number of discrete tasks that include “execution” (the entire process of constructing the system, from the Project Manager’s perspective), the logical design, the physical design, the selection of components, architectures, and frameworks, the coding, the building, the testing, the deployments.

TL;DR: Simple language is not the end-all, be-all. It’s good when writing to a larger audience, but wrong to use in all cases.