During the COVID times, I’ve been in an IRC reading group for Richard Hamming’s The Art of Doing Science And Engineering: Learning To Learn. Long out of print, it’s been recently republished, and I snagged a hardback copy (though the original text is still available as a PDF for free). While I knew nothing about Hamming prior to the book club, the book has been a delight for learning all kinds of things I’ve never read about (though digital filters was a hard slog). We have just gotten to the chapters on Simulation, something I am very familiar with, and nestled among the anecdotes about early missle simulation was a paragraph about jargon. Apparently Hamming and I were of the same mind about it:
Beware of jargon — learn to recognize it for what it is, a special language to facilitate communication over a restricted area of things and events. But it also blocks thinking outside the original area it was designed to cover. Jargon is both a necessity and a curse. You should realize you need to be active intellectually to gain the advantages of the jargon and to avoid the pitfalls, even in your own area of expertise!
I understand that there is a need for jargon; there has to be some baseline for understanding concepts (so context is often key to whether it’s appropriate). It’s also necessary to create building blocks for other pieces to build upon: no Carl Sagan apple pie here. But too often I see jargon for jargon’s sake, used in all the professions I touch where it’s a stand-in for understanding. I frequently get emails that are sentence after sentence of jargon. No discipline is immune; architects and engineers love to bat equally inane abbreviations and technical terms at each other. It serves no purpose other than to confuse communication and make people look smart. What’s worse, it’s used to gatekeep and feign surprise with less experienced employees, making them less likely to ask questions in the future when now is the time for them to be asking questions.
I’ve also found that jargon crops up a lot in “design computation"" (though I think even that term is an incomplete catch-all), that is, anything software or technology related being applied to changing the design practices within the AEC industry. I don’t know if it’s a defense mechanism to emphasize complexity and value for tech/software groups within a company, but it magnifies the divide between those who know computation and those who don’t (and discourages those who want to!)
Jargon is particularly insidious in academic papers and appears to be getting worse with time. Consider the folowing paragraphs both describing the same numerical method:
Dynamic Relaxation, is a step by step method for tracing the motion of a structure from the time of loading to when it reaches a position of equilbrium due to the effects of damping. Since the method of Dynamic Relaxation is for static analysis the analyst is not concerned with the motion since this is fictitious…(Topping 1994)
[Dynamic relaxation] is an explicit iterative procedure in which static system is transferred to an artificial dynamic space by adding artificial inertia and damping forces…Dynamic Relaxation calculates steady state response of a dynamic system…using numerical techniques.(Pajand 2010)
Yes, the first definition has a baseline of knowledge required. If you know nothing about structural analysis, the concepts of equilibrium, static analysis, and damping would be foreign, but an undergraduate with a degree in structural engineering would have knowledge of all three concepts. The second one is one of many similar definitions that I read as much more jargonish with “artificial dynamic space” et cetera.
These papers were written over two decades apart, and while I understand the need to reword concepts to avoid plagiarization, it feels like a definition was crammed into thesaurus.com and then the longest word was picked. It leads to loss of knowledge, as concepts get rehashed and obfuscated time and time again, producing more noise than signal. I don’t know what the ultimate solution is, but I know where my preferences lie in plain damn English and will try to keep finding that balance in what I write.
As an aside and endnote, I am very much enjoying the following website called Write Like An Architect by @brianthehuman as some unabashed mocking of superfluous language…