Beware techies talking gobbledegook
ft.com
ft.com
Feynman explains this really well when trying to answer a question about magnets:
"Of course, it's an excellent question. But the problem, you see, when you ask why something happens, how does a person answer why something happens? For example, Aunt Minnie is in the hospital. Why? Because she went out, slipped on the ice, and broke her hip. That satisfies people. It satisfies, but it wouldn't satisfy someone who came from another planet and who knew nothing about why when you break your hip do you go to the hospital... when you explain a why, you have to be in some framework that you allow something to be true. Otherwise, you're perpetually asking why."
"I can't explain that attraction in terms of anything else that's familiar to you. For example, if we said the magnets attract like if rubber bands, I would be cheating you. Because they're not connected by rubber bands. I'd soon be in trouble. And secondly, if you were curious enough, you'd ask me why rubber bands tend to pull back together again, and I would end up explaining that in terms of electrical forces, which are the very things that I'm trying to use the rubber bands to explain. So I have cheated very badly, you see."
The key quote being:
"I really can't do a good job, any job, of explaining magnetic force in terms of something else you're more familiar with, because I don't understand it in terms of anything else you're more familiar with."
Video: http://www.youtube.com/watch?v=wMFPe-DwULM
Transcript: http://lesswrong.com/lw/99c/transcript_richard_feynman_on_wh...
The fields are presently among of our base concepts. Like the atom was, until the discovery of the electron and nucleus around ~1900.
What he does capture well is that you always have some kind of a base which you accept.
(That might be what you meant, but learning this a couple years ago blew my mind so I had to share.)
"Above all, I hope we don't become missionaries. Don't feel as if you're Bible salesmen. The world has too many of those already. What you know about computing other people will learn. Don't feel as if the key to successful computing is only in your hands."
1. Drop the level of detail, and
2. Explain using analogies derived from the computer terms you are using.
For example, can you explain what a stack overflow is to someone who's basic knowledge of computers amounts to writing school papers in Microsoft Word?
I can:
"A stack is exactly what it sounds like. It is a logical way of setting up data so you can put data on the top of the stack or take it off. Let's look at books here and stack them up. At some point I will run out of space. That's a stack overflow."
If they don't have the concepts, they don't need the low-level detail. I don't need to explain frames, heap allocation, etc. You have to start with the concept. But it isn't that hard.
I am not sure I can explain magnetism to you, but I am not deeply immersed in that field.
A "stack overflow" is a common programming error that can lead to a security compromise. While vendors have made their products more resilient to this problem in recent years, it remains a major risk, especially for systems connected to the Internet.
It's a warning / apology for the logical, competent, altruistic and forthright executives of the world not to be further misled by the self-serving, evasive, babbling "geeks".
Something like a condensed Make Mine Freedom [0] for the "dangers" of technology.
>"But the first step is the simplest and the most important: like Dennis, we need to ask challenging questions, admit that we do not understand “gobbledegook” and demand answers."
What a concept.
Just demand answers to something so far beyond your current comprehension as to be nonsensical.
What's in the best interest of the company / country here?
Is it really attempting to synthesize three decades, a handful of degrees and years of domain-specific knowledge into a 5-minute PowerPoint deck? Or might we all be better served by replacing complacent, technically illiterate board-sitters with people who care enough to come prepared and stay current?
I've seen a FTSE-100 company destroyed because of adherence to buzzwords and industry standards (nothing inherently wrong with that) without - crucially - any attention to the details of applications to their business. Which is what this Dennis did.
I would say techies also get caught up in this behavior sometimes.
For a concrete example, I work on compiler research. To explain my work to a layman, first I have to explain "compiler"; for that, I need to explain "native code" and "programming language". That can take a lot more than 30 seconds.
The CEO you've now explained what he does now has a good idea - translating between human languages usually loses some of the intricacies of the statement and makes it seem unnatural. It's better to just get someone to write directly in french rather than translating it from english, right? So the CEO will fire the compiler researcher and hire someone to code in ASM. Good job.
I'm being silly here, but the point still stands: explaining something complex is fraught with dangers when there is no mutual understanding of the subject matter. You might think you've explained something, and the listener might thing he has understood, but in reality you have now simply created completely invalid assumptions in a person's mind. The greatest example of this I've seen is regarding quantum mechanics and observation collapsing the wave. There is a whole quasi-spiritual movement that now believes that the world is shaped by conscious observation - talk about missing the point!
Summarizing is about maximizing the amount of information conveyed per word. Saying "you have failed to explain what he does in two sentences" is a bit silly, since, if one could fully explain his PhD in two sentences, it wouldn't be a PhD.
Or I could tell you that I find better ways of extracting information from data.
Your pick. The latter just sounds like shit. But just because you have a degree in computer science doesn't necessarily mean you will have the tools to understand that.
It's easy to give an intelligible answer that could be equally applicable to any of about 100 PhD theses. But getting someone to explain their specific contribution in under 5 minutes is often going to be pretty difficult.
Often repeated and attributed (apocryphally?) to Einstein but has never been true. Lots of scientists lack the skills required to explain their work succinctly to a general audience, and it doesn't mean they don't understand their own work.
If it is a simple problem, fine by me and I'm basically delegating my health into his competence. However, critically, if it is anything serious, I go and study it, enough to at least be able to talk about the subject. When I had lasik done, I knew as much domain specific jargon as my surgeon.
The same applies to IT and company boards. For daily operations, hire a good IT exec and let him work. If, however, you are treating an exception, go learn enough IT to talk to the "doctors". Or get an IT guy on the board...
If some "techie" has presented a bag of buzzwords to the board, then someone has failed to recruit a competent technical manager. Someone who's job is to understand both the technical and the strategic domains. Directors would be best to spend their time recruiting, rather than learning Vim.
OTOH, sometimes the board fails to realise that they are actually running a software company. For example, many directors still believe they are running a "bank", when the vast proportion of their business is software development. In such cases, complaints like this amount to little more than pining for the "good old days".
For example, I tell people who want to learn networking "do NOT start with the OSI model. Start by learning how TCP/IP actually works and how it was designed. Then learn how and why the OSI model was designed." But a lot of people insist on going the other way, I think because it is more confusing and obfuscates more than it clarifies.
Some people argue that you can't condense all of that knowledge into phrases non-technical people can understand, that's rubbish. Consider what they already know, then give an overview at that level with a list of benefits. Wherever they inquire then just explain that part at the next level down.
But people talk as if TCP/IP follows the OSI model. It doesn't. Often understanding that it doesn't and why it doesn't is a good first step to understanding why it works the way it does. So that is top of my list.
THere are other issues. For example, when another techie is speaking gobbldiegook, it is way too easy to project meaning onto what is said so that misunderstandings develop. For example, I have written frameworks for building object frameworks. These are not object factory factories (but rather services to offer object frameworks, for example generalized service locator API's for locating stored procedures, allowing a looser coupling than most people have). However, when someone says "its an object factory factory" very often the simplest response is "well, sort of, if you are the factory worker!"
But it doesn't except if you use the cliff notes version of the OSI model. That's my point. Otherwise, H.323 would look like SIP, which it doesn't. Protocols designed for an OSI model look fundamentally different than protocols designed for a TCP/IP model.
Let's look at H.323 since that is the example I am using. The protocol is a beast to work with over TCP/IP because it was not designed for that. It was instead designed for a unified OSI network where virtual circuits could be requested to handle voice and video information. Those don't exist in TCP/IP which has no concept of a virtual circuit and so over TCP/IP, you use a new TCP connection everywhere you'd use a virtual circuit because that is the closest equivalent. It isn't really an equivalent however which makes the protocol very, very difficult to deal with in terms of firewalls, etc. Compare with SIP which just passes everything across a single TCP connection hitting a well known port.
The difference here is that the basic assumptions of what the network can do are different. TCP/IP assumes at its basis that you have a simple, dumb packet switched network that really isn't capable of doing anything else. OSI assumes you have an intelligent network capable of routing packet-switched and circuit-switched information together. They are totally different design criteria and at best you can say TCP/IP is a very narrow subset of what OSI is designed to do.
What this means, effectively, is that you either have to strip down the OSI network in theory to match TCP/IP (which is useless) or you end up with something that doesn't really match. Either way there is no way of understanding H.323 without understanding the OSI model to a level in which the fundamental differences with TCP/IP matter and that requires knowing the basics not only of packet-switched networks but also circuit-switched networks too.
OSI is an ancient, dumb, wrong, 10000000000000 feet architect view of networking. Do not learn anything about it, you'll do yourself a favor. Ethernet is NOT OSI layer2, IP is NOT layer3, and especially do not think TCP is OSI layer 4.
Partly agreed. It's worth noting however that the PKI associated with SSL (X.509) is an OSI thing and so understanding OSI concepts is still rather important. This is also why X.509 certificates IMO feel a bit foreign in terms of structure and they tie in closely to LDAP concepts (a stripped down version of OSI X.500) rather than more internet-y directory concepts like DNS where everything is a text string and human readable.
> Hell they don't even follow TCP/IP's layers, but at least there they make an effort to make it look like they do
My point was that TCP/IP and OSI are just fundamentally different. They are culturally different. They have different goals. You can understand TCP/IP better on its own than through OSI. You can't understand OSI by using TCP/IP as a sole reference.
> "OSI is an ancient, dumb, wrong, 10000000000000 feet architect view of networking."
I think it is more correct to understand OSI in context, namely that it was a network model designed to support the OSI protocol stack. This stack was intended to fully merge circuit and packet-switched networks (effectively merging phone switches and the internet). This means you have, effectively, an intelligent network with possibly intelligent terminals, which are capable of doing both circuit- and packet-switched networking on top. OSI protocols ported to TCP/IP like H.323 make perfect sense if you understand that they are assuming they can open phone calls (but in the process of porting them to TCP/IP, they have to use one TCP/IP connection for each phone circuit they would otherwise open). This is furthermore why the network perimeter controls designed for H.323 involve what amount to phone switchy things instead of things like firewalls (and why a simple packet filter won't work).
In terms of the value of not learning it, I think the best approach honestly is to learn TCP/IP without the OSI model first, and then learn the OSI model and what the OSI stack was designed to do after. This gives you whole layers of insight, not into TCP/IP but into OSI protocols ported to TCP/IP.
Interestingly Roberto Assagioli makes a case that Maslow's hierarchy of human needs is useful beyond that, not so much in terms of the heirarchy itself so much as the idea that peak experiences (including mystical experiences) are things which are easiest to achieve once certain psychological things are dealt with.
Assagioli is interesting reading. It is as if he throws Freud, Jung, and Dante into a pot, seasons with a touch of Hinduism and Arthurian legend and pulls out out a psychological theory which surprisingly makes sense.
The day when an employment contracts is shorter than a CV is when techs do not need to talk gobbledegook. A CV explains your liftime of skills and experience and a employment contract explains how you are paid and what you do to gain that pay. With that in mind, techs deem life too short to expand upon what people do not understand. WIth that you always get the sturborn person who wants to know details they need not know and with that we ask that person for a charge code for our timesheet and play one problem of techs of against another.