Hacker News Reader

Comment by nickelpro | Hacker News Reader

In my career I've at times been a leading expert on, as is the way of these things, a couple niche technologies. I'm speaking from that perspective.

While certainly there are those who struggle to connect with layman audiences, especially in academia, a complete inability to communicate the challenges and successes of a technology, technique, or theory to laymen is a huge demerit against a claim of expertise.

There's a huge difference between walking through technical and theoretical mechanical specifics, and being able to communicate about a subject at different levels of abstraction. The greatest experts can often walk with a laymen right down to and rub against the jargon-filled specifics in a way that leaves no doubt they're able to step over that line without problem.

This is important because we don't perform ideation, architecture, or structural problem solving in the terms of white papers and technical specifications. If an expert does not have an abstract internal narrative with which to navigate the mechanics of the subject, they are likely not an expert at all.

View on HN

This isn't really true for anything but the basics.

If you're having a conversation with someone who asks more than surface-level questions, but hasnt more than surface-level knowledge, the answers can require many years of study -- or, at least, hours of conversation to get anywhere. This situation is incredibly frustrating if you're an expert, often because these question-askers aren't at all willing to listen to hours of you explaining many things to them.

Consider a person who says, "I heard rust was better than python because its safe" -- where would one even begin? Suppose now you're dealing with a person who knows enough to make the claim, but isnt patient enough to have memory safety, garbage collection, interpreters, etc. explained

This is often the situation experts are in. Indeed, it's a majority of hackernews threads.

It's easy.

"Rust is better for safety than C because it makes it harder or impossible to make certain kinds of mistakes that are easy to make than C."

"What kind of mistakes?"

"There are times when you need to acquire some shared resource. Let's say memory. In Rust, it's easy to ensure you return that memory when you're done with it. In C, it's easy to forget to return that memory when you're done with it. This is called a memory leak, and you might find that eventually there's not enough memory for other programs to run."

"What's memory?"

"Think of a program as a recipe you're performing. Memory then is like working space. Like your counter space in your kitchen. If you run out of counter space, you don't have room to chop up more vegetables or temporarily store your cooked meat or what-have-you. Maybe you ran out of counter space because you left last night's dirty dishes on it. Rust automatically puts the dirty dishes in the dishwasher. In C, you have to remember to do that yourself, and sometimes you forget to."

And so on.

There's an easy explanation as long as you're not expecting them to perform detailed analysis. And I'm not.

edit: eventually you'll get to your limit of simplicity, things like "what is fire?" and maybe you need to say "I don't know, let's find out together!" We all have limits to our expertise, after all.

I said python, not C. Answering the C vs. Rust question would be presumably easier, because the claim is true (ie., it doesnt rest on a misunderstanding) and the person asking is likely familiar enough with the relevant concepts.

The person claiming Rust is safer than python is so whoely confused this 2min tap-dance isnt good enough.

When you're dealing with people with a-bit-more-than-surface understandings, the main problem is their head is full of misunderstandings. It is these that can take hours, or years, to undo.

To suppose otherwise is to suppose that all questions can be answered in a cute couple of setences. This is, indeed, the opposite lesson of expertise.

I shifted it to C because I am intimately familiar with C's drawbacks. I don't have the same understanding of Python's drawbacks.

And it's always about explaining to the target person's level of understanding. A layman isn't going to know the difference between languages and why pick one vs. another. That's a long digression. Explaining why to use Rust to a Python expert is a very different discussion.

An expert can switch between explanations as required for the audience. Non-experts, in my experience, cannot tailor the explanation for the audience. They typically bottom out at a level that leaves them unable to meet the questioner in the middle.

Hell, I've been the non-expert, especially when it comes to something like why a particular material was acting like a diode instead of not passing the signal or passing the signal intact. I can regurgitate that the half-rectified signal from the aggressor is bleeding into the signal of interest, but I can't tell you why. That's when I'll tell you to talk to the EE team for specifics on why, as well as what they plan to do to fix it.

The purpose of my choosing python is that the comparison is essentially a category error. Python's semantics, and that of all GC'd interpreted languages, make memory safety irrelevant.. there is no manual allocation of memory in the language.

I chose this example as I assumed it would be clear and non-controversial enough to make my point, ie., I assumed most HN readers would appreciate that a person claiming Rust's memory safety model made it safter than an interpreted language would be a person clearly deeply confused about the meaning of any of these terms.

Going on your original example "I heard rust was better than python because its safe", this would be a case where you ask: "What did the person who told you this say was safer in rust than in python?"

If they don't know anything specific, then it's pretty safe to say "Well, there are some differences in the languages, and you might choose one over the other for performance or ecosystem reasons, but they're both pretty safe overall. You probably don't need to worry too much about it, TBH."

There are still unsafe constructs possible in GC’ed languages. I think we’re conflating GC with memory safety.

Well some GC'd languages can take pointers to memory (eg., C#) -- even actually CPython can since it has the cffi/etc. stuff to do so.

In general though, GC means automatic memory management which is effectively a kind of dynamic memory safety.

This is a great example of a common problem, which I've taken to calling "intent-solution conflation". Garbage collection is intended as a way to improve memory safety in a programming language. It doesn't fully accomplish this, and that's an important distinction

This is often more apparent (though a rampant problem nonetheless!) in policy decisions. Like how KOSA is supposed to "protect kids online" but what it mostly does as written is train people to get their identities stolen while making websites even more cumbersome than they already are. If I think it's a dumb bill, someone might say "What, you don't want kids to be safe?", as that's actually a lot of the point of calling it that

You and the commenter above are confusing expertise with ability to determine and speak someone’s language. It’s just a distinct skill.

You may not understand their level, and may be unable to negotiate it due to vocabular barrier (people invent non-standard vocab all the time). Your oversimplifications may bear unintended consequences, etc. You must take that into account and create a plan to make it clear.

And when you have that skill without any expertise, they call you politician. Only a politician may answer “easy” on a hard question and tell something unrelated for few paragraphs cause he doesn’t know anything on the original one.

> You may not understand their level, and may be unable to negotiate it due to vocabular barrier (people invent non-standard vocab all the time). Your oversimplifications may bear unintended consequences, etc. You must take that into account and create a plan to make it clear.

This isn't actually bad in all cases though. It's like learning about science in primary school. You're gonna get some things simplified in a way that might be considered incorrect by those who are experts, but without some base layer of understanding to bootstrap from, you won't be able to become an expert.

An expert dealing with a novice will often get the best outcome by answering the question they should have asked instead. Oftentimes, the novice won't even know the difference.

Meanwhile, the expert who got everything technically correct gets in an argument over irrelevant trivialities.

it's somewhat true, though; python is vulnerable to concurrency errors that rust isn't (rust's concept of safety isn't just memory safety), and while python can detect type errors reliably at run time, that only makes the program fail in a way that is easy to debug and probably won't corrupt your data. for many purposes that is not an adequate substitute for detecting the problem at compile time so that it cannot fail at run time

on the other hand, python is more productive than rust, so if you're time-constrained, sometimes using python will get you a higher-quality product, for example because it's better tested or has a less error-prone or more forgiving user interface. both python and rust fail only at run time when they detect index errors, and users can make dangerous errors with any potentially dangerous program

on the gripping hand, rust runs enormously faster than python, and sometimes optimization trades off against testing time and ui iteration time in the same way that writing more code does, and while writing python is faster, reading it often isn't, so there may be some size of program above which python has no advantages

so i think it's better to say that the question is based on an oversimplification rather than an error. to explain this to a layman i would probably tell some stories of programmers working late nights and delivering unusable guis

There are no concurrency errors in Python.

Every bytecode instruction is implicitly wrapped in a lock.

Of course, you could still get semantic errors by locking the wrong things at the wrong time; but you can do that in Rust as well.

those semantic errors are what i'm talking about, not bugs in the interpreter! rust's borrow checker rejects such 'data race conditions' at compile time (though there are ways to explicitly opt out of it)

You’re either mixing stuff up or need to be more precise in your communications.

A “data race” is simultaneous access of memory from multiple threads, where at least one access is a write. It’s undefined behaviour in modern compilers (including LLVM therefore Rust).

Rust prevents that (except unsafe), as does Python.

All “semantic” concurrency bugs that can be written in Python can also be written in Rust.

that's a correct definition of a data race at one level of abstraction, although the definition of 'simultaneous' required to make it a correct definition is broader than the one you're using; the relevant definition of 'simultaneous' is hairy, but in the case of two threads making a single access each, it is that either thread can be first. it doesn't require the accesses to literally happen in the same clock cycle

another definition of a data race condition is that it's a case where different interleavings of thread accesses to shared data produce different results. see https://en.m.wikipedia.org/wiki/Race_condition for more details and background on the concept

such bugs can be written in rust with unsafe, but not without it

hmm, thinking about it more, i wonder if what i'm saying makes sense

What you're saying makes sense, but I still don't think it's right. Imagine the classic broken bank-balance update algorithm from concurrency 101. It's safe Rust to individually wrap every operation with a lock instead of wrapping the entire transaction [0]. Both Rust and Python prevent data races as narrowly defined by the Rust docs [1], but semantic bugs like that can easily sneak into your code if you aren't careful.

Not to mention, Rust chose not to do anything about the memory fence problem. You're probably mostly fine on x86, but acquire/release semantics and all that nonsense still apply when writing concurrent algorithms in Rust (you'll often get lucky if you have something like a queue/channel and use message passing, since implementations of those often have a few fences internally, probably the fences you need for semantic correctness in your own algorithms). You're a lot more likely to see that sort of problem crop up in embedded work.

[0] That's obviously a bad idea, but more intricate concurrent algorithms are tricky to write in Rust for the same reason they're tricky to write in other languages. You get a bit of help from the compiler which you wouldn't really in Python if you design things to leverage the type system and prove the invariants you need to uphold, but the compiler doesn't know about any of those invariants aside from data races.

[1] https://doc.rust-lang.org/nomicon/races.html

Rust is safer than Python though, at least until the inevitable Rust rewrite of cpython. A hosted language is going to inherit the safety or lack thereof of the host language, barring a level of rigor (think theorem proving) that so far as I know cpython doesn’t have.

Meh. Rust's safety guarantees typically depend on:

- Soundness of their semantics at a conceptual level

- Correct implementation of the semantics in rustc (in Rust)

- Correct translation of those semantics to LLVM IR targeting OS syscalls in rustc (in Rust)

- Correct translation of LLVM IR to native code in LLVM (written in C++)

- Correct implementation of OS syscalls (typically in C)

Python's safety guarantees typically depend on:

- Soundness of their semantics at a conceptual level

- Correct implementation of the semantics in CPython (in C)

- Correct translation of C to LLVM IR targeting OS syscalls in Clang (in C++)

- Correct translation of LLVM IR to native code in LLVM (written in C++)

- Correct implementation of OS syscalls (typically in C)

Both are typically contingent on correct implementation of a huge swath of C/C++ and Rust code. Even if the entire stack were written in Rust, it still wouldn't be sufficient to guarantee memory safety, since bugs anywhere in the stack could introduce memory unsafety into compiled Rust code.

Rust's guarantees come entirely at the first two layers of the stack: If the semantics are sound, and the semantics are implemented correctly in rustc, then the generated LLVM IR (treated abstractly) has memory safety. Python has similar guarantees: if its semantics are sound, and the semantics are implemented correctly in CPython compiler/interpreter, then the resulting execution of the interpreter has memory safety.

>In Rust, it's easy to ensure you return that memory when you're done with it.

This is a false explanation though - the problem is that memory is returned before you're done with it.

https://doc.rust-lang.org/book/ch15-06-reference-cycles.html

This is extra-wrong as python has a garbage collector to break reference cycles. If giving a simplified explanation to a layman, it's important that if they repeat the explanation to another expert they don't hear "well that's wrong".

In my experience, very few people are able to articulate their lack of understanding with straight forward questions like "What's memory?", and that's before we get into cognitive blind spots. For example, you've completely skipped over what it means to aquire and free memory, so I'm not sure your explanation is as clear as you think.

> What's memory?

Room full of buckets. And each of those has 8 light switches in it.

And on modern computers, the janitor keeps the buckets he's used most recently next to his desk.

They usually make several leaps of imagination from the lack of understanding to the question they actually ask.

> what is fire

Funny you ask, this was the most frustrating question in my childhood because no one could give a satisfactory answer of what exactly is the visible part of fire or whether it even exists as a body.

This is the genesis of the “Flame Challenge” by the Alan Alda Center for Communicating Science (yes, that Alan Alda).

https://www.stonybrook.edu/commcms/alda-center/thelink/posts...

fire is a fundamentally organic phenomenon. you heat dry organic material until there's a gas-like emission of particles, these are then nearly instantaneous oxidised causing more light and heat. The emission of heat and light in this gas-like state ("plasma") then causes more emission and so on.

You can burn certain metals (magnesium, sodium, sulfur, even iron (wool)) neither of which is "organic". So fire isn't a fundamentally organic phenomenon ...

Well I meant several things with that claim, which is why, per the theme of the thread, you cannot summarise these matters in cute sentences.

Fire is only possible in an atmosphere with extraordinarily high accumulations of oxygen on planets with an atmosphere, etc. The only known process to bring this about, as far as I know, is life.

Generically, lighting is the 'original' fire on earth. But I take it the commentor was thinking more in their school days of the sustained sort of burning commonly called 'fire'.

While oxygen is the most common oxidizer, it's entirely possible to have combustion without it. Such as utilizing halogens.

The part about emission of light from a plane is basically correct. It’s really about oxidation producing energy, and that energy pushing electrons well out of their orbitals, and then the thermalization of electrons resulting in transmission of electromagnetic radiation in the visible and infrared spectrum.

That's not an explanation, it's a description-by-analogy.

If you think they're the same, consider why we need explanations at all if a description-by-analogy does the same job.

If someone thinks that they're the same, they probably don't already agree that we need both

Okay, now do explain your paper’s result on this specific JIT compiler optimization that allows vectorization in certain cases?

Like, I never got further than “computers can only execute and understand these few specific commands” before the layman party gave up.

It is absolutely the same with plenty of mathematical topics (like, just the field of abstract algebra is absolutely mind boggling for almost everyone), physics, engineering, etc. Sure, one might bring up Feynman, but physics does have several topics that are easy to grasp - it’s literally about the world around us, and while a layman may not understand anything about the complex calculations about, say, an internal combustion engine, they will find it accessible due to the common ground.

This hinges on a thorough understanding of safety. It also does not even mention trading things off. Both of which are topics that will require further clarifications. And as it were: and so on.

"Why doesn't everyone use Rust then?"

"Because it turns out that people aren't using the language too much yet, and it makes some things that are easy to do in C, hard to do in order to keep the language safe. It's all tradeoffs."

At some point the person asking is satisfied and that tangent ends. This is how conversation works.

You aren't trying to teach a layman how to write production-ready Rust code, and they aren't interested in learning how.

What does it mean for a thing to be hard to do in the context of different programming languages?

Hard and easy here are extremely deep and complex subject matters. Is goto hard or easy, for example?

The person is going to give up (or you are,) because you are not going to be able to just have this conversation for any meaningful length of time. This is a (bad) fantasy, and one that books sometimes attempt (that I hate) and some people fantasise this way.

They are not going to Ask The Next Question because if they could do that, it would come from a position of already understanding in a sort of anachronistic way. (In that they already have your answer, yet still want it.)

They lack intuition for all the new concepts, they have a bunch of false friends (to borrow from linguistics, in that they think they understand some of the concepts - but they are different concepts with the same or simliar names).

If you are a good teacher, then I am sure you will be very successful in explaining, but it's just not happening quickly nor with just anyone.

Notice that you've shifted the parent's question from Rust vs Python to the entirely different discussion of Rust vs C.

> what is fire

It is the light of other days.

Feynman explains it here: https://youtu.be/N1pIYI5JQLE?si=APotFnCuOVKN0wc8

Ironically Rust binaries link to libc.

I think you're both right, but I think you're talking about different kinds of knowledge transfer.

Imagine, as a simple model of expertise, three different levels of knowledge in a subject: beginner, intermediate, and advanced. In my experience, an expert can always explain their knowledge to the next level down: if you've got someone at the advanced level in a room of intermediates, then if the person at the advanced level should be able to explain what's going on to their intermediate peers. If they can't, I would be deeply sceptical that they know their stuff.

But beyond that - someone at the advanced level in a room full of beginners, for example - communication gets harder, and the expert usually needs to be skilled in teaching in addition to their specialist subject in order to effectively explain what they're on about.

So in your example, the expert is dealing with someone who only knows the basics, and so will need to do a lot of explaining to get them up to speed. But if instead the expert was asked something like "How does the use of ADTs in Rust change how you would model data in comparison to Python?", then the person they're dealing with probably knows enough that the expert only needs to explain the relevant specifics to them.

So in summary: yes, teaching someone who knows relatively little compared to you requires a lot of specific teaching skills, even as an expert. But if you really are an expert, you should be able to explain your expertise to peers who just don't have the specific knowledge you have.

This is a very wise point I haven’s seen written out this concretely, thanks! I really do feel this additional detail is necessary to the above claims. No matter how much of an expert someone is, there are topics that have so many dependencies themselves, that are alsk advanced knowledge, that explaining it in one go is just not possible.

There are some topics where analogies can sidestep some of this difficulty in teaching by basically keeping the shape of the dependency graph, and replacing it with one that happens in ordinary life. But I don’t think that every expert topic can have such a homology, fundamentally so. Complexity is unending, while “problems common in ordinary life” has limited complexity. That math paper that 10 people understand on Earth will not be readily accessible to Aunt Mary not even by the smartest person on Earth.

Your point reminds me of ARS LONGA, VITA BREVIS by Scott Alexander [1]

>“You’re talking about an infinite regress”, I said, when I had finished the glass.

>“Not infinite. Architects. Teachers. Teachers of teachers, but the art of teaching teaching is much the same as the art of teaching. Three levels is enough. Though the levels have to mix. The teacher who trains the next architect must be a master both of teaching and of architecture. I will spare you the math, but one needs a series of teachers at different points on the teaching-skill/architecture-skill tradeoff-curve. One will be a master teacher who has devoted decades to learning the textbook-writing skill, and who can write a brilliant Introduction To Architecture textbook that makes the first ten years of architecture ability seem perfectly natural and easy to master. Another will be a mediocre teacher who knows enough advanced architecture to write a passable textbook on the subject. Still another will do nothing but study pure Teaching itself, in the hopes that he can one day pass on this knowledge to others who will use it to write architecture textbooks. In practice we are limited to a few strategic points on the tradeoff curve.”

[1]:https://slatestarcodex.com/2017/11/09/ars-longa-vita-brevis/

> Consider a person who says, "I heard rust was better than python because its safe" -- where would one even begin? Suppose now you're dealing with a person who knows enough to make the claim, but isnt patient enough to have memory safety, garbage collection, interpreters, etc. explained

This means that the asker is impatient, not the expert. An expert can explain everything from 0, and might even enjoy it.

Let the expert be a native Indonesian person who speaks no English, and I don’t speak a word of his native tongue.

Can he explain anything to me, given such a language boundary? Even though he knows stuff from 0, that doesn’t translate over to ability to explain.

It’s all about analogies. You can explain anything to anyone.

Rust is safer than Python in the way same way as having a backup sensor in your car versus not. Sure, you won’t need most of the time but it may catch you that one time that you almost backed into a wall because you were still groggy after a night out.

You got their attention and they understand your expert PoV. If they’re still curious and want to know more, you go deeper.

If I were presented such questions I would provide some basic context in a sentence or two and then ask why they care about the difference. Perhaps something like this:

Sqeaky: rust and python are both good programming languages rust is good for high performance, safety oriented, systems development. While python is good for hooking two systems together or processing a little data right in front of me. Why do you ask what are your goals, maybe some context would help me understand?

Q: I'm a new developer and I want to build a web page I wasn't sure what to use?

Sqeaky: well let's get into what programming you know and let's discuss some Libraries Python and rust both have options!

Q: ...

And the conversation would carry on from there based on the context the asker provided, because contextualizing conversations, questions, and data around a topic is part of having expertise.

"Python is like your kid's room - clean and dirty clothes mixed up in the wardrobe and in random piles and boxes on the floor. Every now and then you come, take the dirty laundry away, and put the rest in some order - in programmer terms, you're acting as 'garbage collector'."

"Rust is like the room of Steve, you know, the one with OCD. Separate drawers for underwear, separate for socks, all subdivided by days of the week. And nothing, nothing is. ever. out. of. order. Sounds like a lot of work up front, but you know what Steve never is? Late. Or in dirty or mixed up outfit. Or unsure whether something is lost or who was it lent to."

"Now, some programming is more like writing experimental music; other is more like double-entry bookkeeping for a company. The flexibility Python gives you is great for the former, but you'd likely prefer something more strict for the latter."

"If you can't explain something in simple terms, you don't understand it." - Richard Feynman

Experts deeply understand their subject, and tailor answers to meet the audience where they're at. If you express genuine interest in someone's passion, they'll be ecstatic. That's what the OP is talking about. It's not about how experts (or anyone) interacts with belligerent and dismissive interlocutors. And observing teaching moments is just one aspect of a larger smell test for detecting imposters. I think it's a good heuristic within that scope!

That's oft cited but usually by people who know Feynman from the shuttle explosion. I've never heard a physicist cite it, and as a former physicist (high energy theorist) myself I have a few qualms with it.

I would say even the Feynman Lectures for undergrads aren't simple, but that's arguable, so let's talk about Feynman diagrams, a supposedly intuitive invention of Feynman. Pretty little line drawings of particle interactions are indeed useful for surface level explanation, but physics is quantitative (that's how we verify anything) and staring at line drawings gets you nowhere in that regard. So the layperson might ask, "how do physicists calculate anything with Feynman diagrams?" at which point Feynman himself would probably be speechless. The path integral calculations for the simplest case in QED is like a page long, which is complete gobbledygook for the mathematically unprepared (>99.5% of the general population), and even for the mathematically prepared, the calculations mean nothing without tons of theory buildup. I have on the shelf right next to me the classic tomes on quantum field theory: >800pp Peskin & Schroeder, >800pp Schwartz, three volumes of Weinberg, all filled with dense mathematics. You need to study at least about a quarter of those to properly understand the aforementioned topic, no to mention all the prereqs: various formulations of classical mechanics, some classical electrodynamics, quantum mechanics, special relativity. There's no shortcut, anyone claiming to have an intuitive understanding of Feynman diagrams (the real deal, not just the line drawings) by reading some "simple" explanations is lying, regardless of whether they have genuine interests. (Btw, the ones with genuine interests are sometimes the worst: the "my theories are correct, I'm just bad at math!" alt scientists who love to email their papers to our entire department.)

In conclusion, there are fields where there's really no way to explain things beyond the extreme surface level in simple terms, and ironically Feynman's own is one of those.

Experts deeply understand their subject.

- Experts that tailor their answers to meet the audience are experts, but not only experts, they also have the luck of finding good analogues for parts of a system or topic, and a skill, or luck, of story telling and structuring teaching.

- Individuals who use analogues and simplifications to describe a system or topic are not necessarily experts, they can also be lucky or skilled imitators, or just teachers.

- Experts who are experts by the definition of having a deep understanding of the subject, but who are incapable or unwilling to simplify and/or structure the story well (in your subjective opinion), are still experts, but unless you also become an expert on the topic, it will be hard for you, or anyone else, to trust their expertise.

Reminds me of Feynman on magnets. He said something awhile back...basically said "ya'all are too dumb to understand magnets". That was my take-away anyway.

My takeaway was more that it was along the lines of "you can't explain this in terms of other things because it is fundamental to the nature of reality."

Agreed. My experience with experts--both being one in my domain and working with others in their domain--is that if they can't explain how it works to a layman, chances are they don't know how it works.

True experts can understand from the layman's perspective and tailor the response to that level of understanding.

Then there is the corollary: a topic is shallow, if an expert can explain it to a layman before the layman loses interest.

I've been working with experts on highly technical topics most of my career. They can explain the big picture to a layman just fine, but if the layman asks something within the actual scope of their expertise, it takes a long time to get there.

> True experts can understand from the layman's perspective and tailor the response to that level of understanding.

The Feynman paradox:

> if you can't explain it to a six-year-old you don't understand it yourself

but also

> If I could explain it to the average person, I wouldn't have been worth the Nobel Prize

The former probably apocryphal.

Interestingly I have recently watched a video of Feynmann essentially saying "I cannot explain it to you because you don't have relevant background knowledge" to a question of "What makes magnets repel or pull each other?". Which agrees with the latter.

https://www.youtube.com/watch?v=MO0r930Sn_8

Of both quotes the latter is definitely closer to the truth.

The problem isn’t always whether an “expert” can, it’s whether they want to.

I’ve worked with plenty of experts who are also impatient, short and condescending with anyone who doesn’t grasp things straight away. That doesn’t mean they’re an imitator, it just means they’re an arsehole.

People aren’t binary. An expert isn’t automatically a good teacher. And, in fact, some imitators are actually better teachers. It’s almost as if teaching and “doing” are different skills ;)

Not so sure. It implies that a bad communicator can't be an expert at anything.

This is my take. As an autistic individual, I struggle a lot with communication in general, especially speaking in-person as opposed to typing slowly and carefully like I am doing now.

No matter how well I understand something, my ability to relay that information effectively to another individual will always be another matter entirely. It's true that I can't explain something I don't understand, but it doesn't logically follow that I only truly understand something if I can explain it.

I think a little piece of that idiom is left out for the sake of making it a good sound bite. An expert can explain something to an eager listener. Would you be able to explain something you're an expert in to a patient lay person who actually listened and tried to ask the best questions they could?

It is an entirely different skill to educate someone with your expertise when you don't get their feedback (tv, radio, youtube) or when they don't want to learn (classroom teacher, office politics around bean counters). Those are two kinds of education and they are important skills all on their own but are in no way tied to other kinds of technical expertise.

If we were both working on a project that needed your and my expertise. If I understood that you had different sensibilities about social norms. If I respected those while asking questions about parts of your explanation I didn't understand. Would you be able to explain a detailed topic to me?

Yes. I can answer questions far more easily than I can coherently give an impromptu explanation of a complex topic on which I am something of an expert.

Even if the listener knows little to nothing about the subject, being eager to understand and asking questions while respecting my sensibilities, however realistic that expectation may be, makes all the difference for me.

One interesting thing about most communication is the implied context. It is no slight against you, but based on what you said here you think differently than others and you will imply different contexts.

I know of no easy answer but I have met people like this and seen them succeed. I hope you're able to successfuly wrangle this extra complexity that the neurotypical will foist upon you and not even understand that they've done it.

Thank you for listening and understanding. :)

Agree. Another thing I notice in this thread is that the implied context is a professional environment where you are expected to showcase your expertise to other teammates, colleagues, etc. As if solitary people, masters of their craft, could not exist in isolation.

This. Many arguments ignore this implication or commit other logical fallacies.

I sense some self-selection that experts tend to be decent communicators, at least in some mediums.

How would anyone know they are an expert if they can’t make themselves understood?

> a complete inability to communicate the challenges and successes of a technology, technique, or theory to laymen is a huge demerit against a claim of expertise.

Hard disagree. A person can be an internationally recognized expert working on e.g. a novel mathematical theory useful for cryptography, without being able to explain any of it to anyone without a university-level math education.

I posit you're combining two orthogonal properties, expert knowledge and being a good communicator, into one axis because that's a useful combo, or the make-up of an expert that you'd like to know and/or hire.

> The greatest experts can often walk with a laymen right down to and rub against the jargon-filled specifics in a way that leaves no doubt they're able to step over that line without problem.

Unfortunately I think it’s naive. I saw people ready to say BS things with a touch of acronyms getting more traction and at higher levels compared to some experts. It’s true experts can walk a layman into deeper subjects but so people used to half BS and know how to convince people…

I remember getting a technical interview with the CTO of a startup. He knew all the vocabulary of DDD, Event Sourcing and the like and was talking length about it but he couldn’t explain even what he was saying like what is an aggregate, etc… I’m sure he was convincing to other officers and the tech team but not to me.

Because of that I feel like almost only experts can detect non experts.

The world is full of people like that. Consultants are sometimes literally all they do.

There is also a similar thing many experienced people complain about: Eventually, you'll have to be able to explain the cost and merit of a technical decision in business terms.

Like, yeah I'm able to explain our postgres HA setup + DC-redundancy at fairly detailed technical level. But then a member of the board asks "Yeah but what does it cost and what benefit does it bring the customers and why?"

Finding a satisfying and comprehensive answer to that question takes a whole new perspective and made me understand a few things more. And question a few more.

Being able to contextualize such data and such facts into actionable knowledge or wisdom is definitely a facet of expertise. It takes a different sort of expertise, some kind of communication expertise, to interject the need for actual study or research in the space.

In my career I have many times been asked to understand a system and to evaluate it and come back with an explanation to the non-technical. The first few times I made no accommodations for cost or support planning. And when asked how much such a thing would cost I inevitably gave wrong answers based on sticker prices or cost of hardware or something similarly trivial. Today I'm always evaluating systems I work in in terms of technician and expert hours in addition to the cost of the things we purchased for them to work on.

If somehow I were surprised today and asked to give a price of standing up such a system, I would know enough to say I need to do some review and formal planning. I would staunchly, but politely, refuse to give up any numbers and say that I can come back with a detailed plan with itemized costs after I actually write down all my notes because even after having worked and software for 20 or more years there are just too many little details that can add a million dollars to a project. After having bought such time I would write down all my thoughts and gather all my notes and look around for things I missed. Then provide such costs and benefits to the bean counters in the only language they all speak dollars, and I would be sure not to put a single number for any field they would all be ranges possible minimums and maximums. And I've been asked why they are ranges in the past, and those help to articulate uncertainty. That is another whole discussion but people who don't work with the technology often don't understand the uncertainty that come from these very certain, digital, and predictable machines.

Reply on news.ycombinator.com