Hacker News Reader

Comment by albertsun | Hacker News Reader

I understand this critique, but I also think there are times where jargon, abstract expressions and acronyms make communication a lot faster and clearer for people who share the same context and domain knowledge.

Trouble is, if you don't have the domain knowledge it's really hard to tell if what you're listening to is really condensed, specific info or meaningless blather.

A lot of times I might say something like "we did data analysis with Python, NLTK and R. The stack is on EC2 running Django with memcached and varnish serving up json and the frontend uses jQuery, underscore and backbone to render it"

To some people, that's a ton of info. To others it probably sounds like gibberish.

The same even applies to the "valley-girl" talking. It sounds like meaningless half-sentences to someone listening in, but to people who know all the social relationships being discussed there might be a lot of information going back and forth.

View on HN

"we did data analysis with Python, NLTK and R. The stack is on EC2 running Django with memcached and varnish serving up json and the frontend uses jQuery, underscore and backbone to render it"

We performed the data analysis using a combination of dynamic programming languages and synergistic components, running on a high availability multi tiered substrate framework while simultaneously utilizing a web space language to deliver content rich user content.

Nice reformulation. It would be right in some contexts ... but, to me (and I am not a programmer by trade nor do I work in the field), the original quote is explicit enough that I would trust the person saying it to know what they are talking about, whereas your reformulation would, in many contexts, sounds like what someone would say when they really have no clue (think "pointed-haired" boss).

I think that's the point of the reformulation: there's jargon and then there's substance-removing abstraction.

Not knowing the meaning of the first formulation, I can still safely say that it was produced by someone who knows precisely what he's talking about. That breeds confidence.

The latter sounds like wall-to-wall bullshit. Not to say that the words don't have meaning, just that they're parked in that infuriating zone favored by people who would generally prefer that you didn't actually understand what they were saying.

If all this represents an especially clever or elegant solution, wonderful - talk about that in a way that makes the elegance clear. Or provide the hard information that the first formulation conveys, so that a trusted advisor can evaluate it. Just don't slip into the bullshit zone. Not if you want to maintain goodwill, trust, and confidence.

And for what it's worth, smart humans are very good at detecting the difference between actual technicalities, and bullshit. It's got little to do with the domain. It's got a lot to do with the demeanor and tone of the person speaking.

The first formulation makes me want to hire the guy. The second makes me want to fire the guy.

I'm not sure how you can "safely say ... [he] knows precisely what he's talking about" while admitting "not knowing the meaning." I think perceiving it as "breeding confidence" is precisely the reason why many business situations where experts' actions must be managed/approved by non-experts result in a flood of impressive-sounding jargon.

The deluge of specificity creates a posture of expertise; however,without knowing what the specifics mean you can't possibly evaluate it for truth. There are many equally impressively structured but semantically ridiculous statements, such as "We host our servers on NLTK, serving up EC2 to a browser frontend running varnish and memcached."

It's almost a shibboleth, these reverse abstractions into understandable English. The more I hear someone jargon it up, the more I think they don't understand what they're talking about. "I like big data!"

It's more subtle than that. Looking past the technical terms, the first formulation is very distilled, and cites a specific action. It's an elegant expression. The second one uses fluffery like "performed" instead of "did". And that's what sets off the BS detector.

I think you missed the point.

Why do you perceive statement #1 to be factual? If you have no domain expertise, you have no way to evaluate it. _DPS's example sounds -identical- to someone without domain knowledge, and yet is comically absurd.

But that example goes well beyond meaningless buzzword boasting into flat-out lying. This is a bit of a different problem and it's a lot easier to fact check factual statements, with or without domain knowledge.

And what is "content-rich content" anyway? The "translation" is still meaningless without domain-knowledge, but is now far less factual. I guess the content is now less content-rich!

the original quote is explicit enough that I would trust the person saying it to know what they are talking about

Which is why (at least) some people do it.

If I read that without having read the original my eyes would glaze over with buzzword overload. So much lost information in the "generic" (or more correctly, vague) form. This is the sort of stuff I'd expect in a sales pitch, where I'm barely any better informed after having heard it, even for someone with domain knowledge in the area.

The original however is packed with specifics, most of which can be looked up if you're unfamiliar with (for instance I had no idea what NLTK was, but a single google search informs me it's a toolkit for natural language processing). They're not buzzwords, they're product names. It's clear and concise to someone with the domain knowledge.

"we did data analysis with Python, NLTK and R. The stack is on EC2 running Django with memcached and varnish serving up json and the frontend uses jQuery, underscore and backbone to render it"

English: We made a website to process data using natural language parsing and statistical modeling. We can throw a ton of data at and it doesn't slow down. It has a nice UI.

English 2 years from now: Once we wrote this really cool site, then our main developer left and we couldn't find anyone to maintain it. Know anyone who knows Python, NLTK, R, Django, EC2, memcached, varnish, jquery, underscore, and backbone? There really is a lack of good developers out there.

Exactly, you don't start with the details.

>"we did data analysis with Python, NLTK and R. The stack is on EC2 running Django with memcached and varnish serving up json and the frontend uses jQuery, underscore and backbone to render it"

This sentence has actual data in it. The author, I think, is talking about people whose statements have almost no substance, so they fill them in with buzzwords.

My point is that it's really hard to tell if something is a buzzword or is substance.

If you didn't have intimate knowledge of modern web development, everything in that sentence could be a meaningless buzzword and you'd have no idea.

When I hear friends talk about a domain I have little experience in, I usually have little idea what they're saying.

Sure, but if a client asks what you're doing, and you suspect they're not clueful about the work, you'd tailor your reply to as close to plain English as possible. But when you're talking to experts you correctly use jargon to rapidly communicate actual information.

There's a big difference between the example you gave and "executive" speak. About 80% of the uses I see of "leverage" / "leveraged" / "leverages" are bullshit. Not just 'could be replaced by use / used / uses' bullshit, but 'if replaced becomes meaningless' bullshit. It's not that people do not understand business talk, it's that much of it is vacuous nonsense that carries no information once you've decoded it.

The underground grammarian has some stuff about this (http://www.sourcetext.com/grammarian/) (although I can't remember where) when he gives an example of a legal definition for a door. It's a long, technical definition, and it's hard to understand. It's the kind of thing that people often make fun of. But he points out the context (maybe legislation about fire exits?) and says that being exact is important, and in that case it's good that there's no ambiguity.

Here is the definition of an exit discussion for you http://www.sourcetext.com/grammarian/less-than-words-can-say...

I've totally heard people rattling off jargon where it didn't add anything. It didn't remove anything (save perhaps understanding by some within earshot), it's pointless complexity, and I'm a person who thinks pointless complexity should be eliminated.

But that's exactly what the OP was complaining about in his charity example! and that's three acryonyms right there that you passed over without issue, and the other names are equally recondite (like 'Django' or 'varnish' tells you anything whatsoever about the projects?).

I understand all of that and yet I understand none of it. The article is talking about explaining things to people in an understandable manner, and that's a bad example.

I don't care that you did your data analysis with $technology unless I happen to be the maintenance programmer that's having to take over that project.

Why did you do the data analysis, how did you do it, and what were your findings, and what does any of that entail would be what most people are interested in.

Even if I'm interested in the technology you've told me nothing. What are the main bottlenecks in your stack, how does it scale, does it even need to scale at all etc?

It's not only important that your audience understands what you're saying, but that you pick the right and pertinent items to discuss with them.

Agreed. Unfortunately the businesspeople the author is talking about don't seem to be making the insider/outsider distinction that you're pointing out. Combine that with the fact that most businesspeople have the compulsive need to make their ideas sound more complicated and profound than they really are, and you have the recipe for misunderstanding and miscommunication.

That's precisely right. Unfortunately, this is caused by managers so often rewarding "confidence" instead of competence.

Fortunately, the way out of this is through greater use of data and analysis. I always find it amusing when an overconfident manager s left speechless when you show them the numbers indicating what they just said is bs. Of course, the nice thing about using data is that it makes managerial blowhards think twice before making promises or telling people that they've actually done something great.

I agree...for the most part. I think the author's point is however inclined more towards the case where there is an audience as opposed to an intimate social circle.

When it comes to an audience type setting, I think it is responsibility of both, the producer and the consumer, to understand that certain knowledge/terminology/context is required. Then, the speaker must communicate in the "lowest common denominator" of that minimal set of expectations.

I agree but I think it's more a matter of expression of not necessarily tangible concepts with speech, which is not an inherently perfect system of description. In these situations, abstraction is critical as it allows for experiences, knowledge and feeling to fill in the gaps. The use of this technique for this purpose is infrequent and most people use it for pure laziness of not being able to accurately an succinctly form verbal descriptors

No, valley girl talking is just fillers and the abstraction article refers to is fake, unneeded use of more general words that is diluting the actual meaning. The article is wrong on acronyms, they are useful and convey meaning.

Reply on news.ycombinator.com