Hacker News new | past | comments | ask | show | jobs | submit login

I completely agree with you, and i think the problem is way worse than that :

Most IT people i know actually like it when people outside their field don't understand what they're doing when they're using jargon and acronyms and technical slang. It makes them look bright (or so they think).

One thing i like to tell people outside the field is daily software development is 99% convention over very simple concepts wrapped in jargon (aka: that's the way it works because people designed it this way, and gave it this name, not because of some fundamental law of physics), and 1% of "hard" things (the very rare times in your carrier when you had to implement a brand new complex algorithm yourself). The percentage may vary depending on the particular job you have, but unless you're working in R&D that's pretty much the idea.

Once you realize that you actually are brighter when you manage to remove all the cruft around what you're doing and explain it simply to "normal" people, all of the sudden you're much more successful at doing it.




I find it's much more common to see

> Clearly, that was what I should have said in the first place, but I hadn't thought of it.

as in the linked article as opposed to

> Most IT people i know actually like it when people outside their field don't understand what they're doing when they're using jargon and acronyms and technical slang. It makes them look bright (or so they think).

Obviously, we all have different experiences, and I'm not trying to say what you've seen isn't a thing. But I'm happy to report that most of the people I know don't like it when their communication is ineffective and are happy when they find an effective way to remove a layer of jargon (at least as long as it doesn't come with a loss of precision) to make things clearer for everyone.


> Most IT people i know actually like it when people outside their field don't understand what they're doing when they're using jargon and acronyms and technical slang. It makes them look bright (or so they think)

This applies to any specialized job. Some will use laymen's terms and explanations when talking to people outside the field so they can also follow (if it is appropriate to do so). Others will insist on using the most arcane jargon and convoluted forms regardless of actual need, possibly to wow the audience. Or maybe because they can't explain it in simple terms or don't want to bother with "dumbing it down".


Medicine is even worse for this.

I was once diagnosed with "non-specific gingival inflammation" which apparently meant "You have a mild gum infection and we have no idea why."


That's appropriate for a diagnosis, which is the term that they'd pass on to the next doctor who wants to peek into your mouth. "Hey, I looked at TheOtherHobbes, and here's where we're at:

- We haven't yet figured out what's causing it, but - [the official name for the body part involved], - is notably red and puffy, which is probably caused by an infection, - but there could be any number of other root causes, we haven't run sufficient tests to find the exact cause, and we're not worried enough to recommend a million expensive and invasive tests for what's 99% likely to be a common, simple infection."

Jargon is very information dense, and everyone in every field uses it to convey a lot of information quickly. Take a phrase that would be very clear to any reader here: "there's too much RF from my Wi-Fi router, so I switched from a Bluetooth mouse to USB". Suppose this is how I fixed my friend's mouse problems, and he got the gist of what was happening but didn't really understand the details. His girlfriend comes over and asks why he suddenly has a wired mouse. He hands her a piece of paper where I've written exactly the sentence above, she reads it, says "oh, weird. Makes sense though."

Now, my friend may not understand every word of what I wrote. Even "mouse" is jargon, albeit something that's been around forever so it's widely understood. However, his technical girlfriend would immediately understand what the actual problem was and why that was a good solution to it. The diagnosis wasn't for him specifically. The diagnosis was for the next technical person to understand where we're at with the problem.


Oh yes, this is a good one to know. "Non-specific" = "we have no clue wtf is going on".


My kid once had "toddler's diarrhea", aka we don't know why she's going a lot, but she is.


It can be especially challenging to be both precise and comprehensible to people outside the field. Even if you can manage it, you really need to "read the room" to decide whether it's worthwhile.


I've always found it to be a rewarding challenge. Jargon is the lazy way out; anyone can invent complex and smart-sounding labels for a concept[0]. But what's the point? It's much more fun to communicate something accurately, precisely (there is a difference!), and in the way the audience can understand.

(I've found this often requires constructing a sequence of explanation - almost a kind of a narrative, that starts with an answer to the question "what are we trying to do and why do we care about it?", and is followed by introducing constraints, until it becomes obvious what the concept is, what its moving parts are, and why we actually care about it. But then again, a good analogy can cut through all that. In the article, "just like TV", that was perfect.)

--

[0] - I mean, an average human is an adequate stochastic generator of surjections from words to concepts, under adequacy criterion defined as the capacity of ingroup/outgroup border delineation.


Jargon may serve the purpose of a "gatekeeper" in conversation, signaling who is allowed into certain forms of conversation. Jargon may serve this function by dictating to which direction or depth a conversation about or within the context of a certain field or profession will go.[25] For example, a conversation between two professionals in which one person has little previous interaction or knowledge of the other person could go one of at least two possible ways. One of the professionals (who the other professional does not know) does not use, or does not correctly use the jargon of their respective field, and is little regarded or remembered beyond small talk or fairly insignificant in this conversation. Or, if the person does use particular jargon (showing their knowledge in the field to be legitimate, educated, or of particular significance) the other professional then opens the conversation up in an in-depth or professional manner.

https://en.wikipedia.org/wiki/Jargon


Another problem is when people explicitly try to do a simplified explanation, most seem to be unable to extract the essential concepts from all the implementation details and end up writing massive walls of text in which every technical term is explained further using everyday analogies.

You see this a lot on reddit's /r/explainlikeimfive, but the best example I've seen is the answers here: https://security.stackexchange.com/questions/55343/how-to-ex... - with the top-voted XKCD cartoon as a counterexample.


After digging a bit into machine learning i feel like there is a tendency to be fancy with terminology. For example, do we really need to use the obscure term ’stochastic’ when ’random’ exists?


I do think there's some value in being able to tersely express your exact point to a peer.

For example "a random process" could mean "any process in existence" whereas "a stochastic process" clearly states stochastic as being a property of the process.

I however agree that things can sometimes get a bit wrapped up in sounding cool just to sound cool.


As a rule of thumb you should never use a big word when a diminutive word will suffice.


Among the meanings of random are:

1. Stochastic.

2. Unbiased.

3. Typical and average.

4. Unprompted or unjustifiable.

5. Habitually using non sequiturs.

So, I might use a random sort algorithm like, I don't know, heapsort. Or I might be reading through some code and find a random sort algorithm --- why is there a mergesort in the middle of this calendar routine? Or, if you want a random sort algorithm, you should be sure to use the Fisher–Yates shuffle. Or, to avoid the quadratic worst case of treesort and quicksort with high probability, you can convert them into random sort algorithms by picking partition elements randomly.

Of these four random sort algorithms, only the fourth is stochastic. (I haven't figured out how a sort algorithm could habitually use non sequiturs.)


I think that one doesn't come from being fancy, but from machine learning being the terminologically-uncomfortable collision between statics mathematicians and computer scientists, who previously had essentially no cross-talk with each other. There's a number of similar places where ML uses statistics terms rather than ones you'd expect from a computer science (as a branch of mathematics) heritage.


This makes sense to me. Thanks for the insight!


You're still using stochastic processes? I switched to aleatory ones after reading a DeepMind pre-print that's been going round.


These aren't synonyms.

Random is a property of the world itself; stochastic means "we allow ourselves to think of this process as random because we can't/don't want to deal with it exactly".

Following this is the difference between Random Differential Equations and Stochastic Differential Equations.


I like Robert Anton Wilson's definition. "A stochastic process is a random series, but it is a special kind of random series. In a stochastic process, some agent or agency is making selections—picking out of the randomness a pattern that is not random."


Are the terms that interchangeable? "I used a random algorithm" is a different expression from "I used a stochastic algorithm". For me, the term stochastic is one half of the stochastic vs deterministic categorisation.


I think that's orthogonal to the original question


I used to get a bit frustrated when I'd look up some esoteric programming term and find a convoluted description of what was ultimately a simple concept that I was already using.


Nonsense, monads are actually quite simple. Think of them like a…


... endofunctor ...


(monoid)


I still am. Also, when I discover that esoteric term #1 used in a subfield A is the same thing as esoteric term #2 used by a subfield B, but either they never talked to each other, or someone decided they want to be different.


This was me with patterns. Relatively straightforward techniques dressed up in grandiose terminology, I found them hard to grasp until I got some real world examples.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: