veyepar: When Jargon Becomes Gibberish

Author(s):	Casey Schaufler
Location	Arena
Date	jan Thu 16	Days Raw Files
Start	10:45	First Raw Start	error-in-template
Duration	0:45:0	Offset	None
End	11:30	Last Raw End
Chapters
Total cuts_time	None min.

https://lca2020.linux.org.au/schedule/presentation/19/
raw-playlist raw-mp4-playlist encoded-files-playlist mp4 svg png

assets release.pdf When_Jargon_Becomes_Gibberish.json
logs
Admin: episode episode list cut list raw files day marks day marks day image_files

State:

Locked:

clear this to unlock

Locked by:

user/process that locked.

Start:

initially scheduled time from master, adjusted to match reality

Duration:

length in hh:mm:ss

Name:

Video Title (shows in video search results)

Emails:

email(s) of the presenter(s)

Released:

has someone authorised pubication

Normalise:

Channelcopy:

m=mono, 01=copy left to right, 10=right to left, 00=ignore.

Thumbnail:

filename.png

Description:

markdown

You've most likely been there: you're a half hour into an important technical meeting and you realize that of the last dozen words you've heard you only recognized two, and neither would seem to have any bearing on the topic at hand. You look around and see that everyone but the presenter appears to be mentally grasping for some key understanding what's being said. Your carefully gathered notes say "SDL PRS review SS2 Smokey Lagoon PKR BKM". Somehow, the jargon you've relied on for precise and detailed technical communication as devolved into incomprehensible gibberish.

Casey Schaufler, who's been working in operating systems development for the past 40 years, explains the reasons technical documents and presentations so often become impossible to decipher.  There's much more to it than the unguarded and unexplained use of acronyms, abbreviations and code words. The impact of language background on the use of technical terms is explored. How cultural differences between individuals and organizations can interfere with technical communications, and how that differs from general communication is discussed. What can go wrong when technical documentation is mistranslated into plain language, resulting in words with completely different meaning also gets much deserved attention. Casey will provide examples, some humorous, some maddening and some otherwise which demonstrate the problems we face. In the end, hopefully useful and pragmatic approaches for avoiding the worst gibberish production are presented.

Comment:

production notes