Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Patterns in Confusing Explanations

jvns.ca

Post reply on HN
Print view View original

11–20 of 168 posts

Re: Patterns in Confusing Explanations

#11

Post by n3k5 »

carrolldunham wrote: post #5
null_object wrote: post #4

Earlier quoted context omitted.

>pattern 1: making outdated assumptions about the audience’s knowledge >pattern 2: having inconsistent expectations of the reader’s knowledge >pattern 3: strained analogies >pattern 4: pretty pictures on confusing explanations... edit: I understand you're trying to help, but... Your post simply listing the 'titles' of each of the categories is ironically itself an example of exactly the problem the blog-post is discu…

I dunno... they each seem pretty self-evident.

They could be (and even seem) much more self-evident (and valuable as a tl;dr) if they were one-sentence summaries instead of a copy-paste of a paragraph from the beginning of the linked page.

Re: Patterns in Confusing Explanations

#12

Post by elboru »

Another pattern I usually encounter is explaining the how but not the why.

Trying to understand how a complex mechanism works is hard, but it’s harder if you don’t know why the mechanism exists in the first place.

It would be madness to start studying how an airplane engine works without knowing it is used to impulse a flying machine.

Re: Patterns in Confusing Explanations

#14

Post by darkerside »

Am I the only one that appreciated strained analogies? They are meant to create a visual in the reader's mind so they can remember the pieces that are being shared. Of course, if the analogy is good, it won't feel strained. But it seems like the author is against any extended analogies at all, which I think is a mistake.

Re: Patterns in Confusing Explanations

#15

Post by kbenson »

beprogrammed wrote: post #8
null_object wrote: post #4

Earlier quoted context omitted.

>pattern 1: making outdated assumptions about the audience’s knowledge >pattern 2: having inconsistent expectations of the reader’s knowledge >pattern 3: strained analogies >pattern 4: pretty pictures on confusing explanations... edit: I understand you're trying to help, but... Your post simply listing the 'titles' of each of the categories is ironically itself an example of exactly the problem the blog-post is discu…

I have to disagree. And to each is own. Having read the article I found that list painted a clear picture and summed up the patterns nicely. If one reads that and wants more, read the article. (Not authors)Pattern 13: Using excessive prose where less will do

> Pattern 13: Using excessive prose where less will do

That's just a mix of #1 and #2. "Excessive" prose is usually people trying to provide nuance through language with the assumptions others will be familiar enough with that type of language for it to provide benefit. Different words have slightly different connotations which can help if people understand those differences.

Fundamentally, it's the same problem as using acronyms that people aren't comfortable with to immediately parse so they don't cause extra mental load.

The alternative is to make everything really simple, but the lost nuance can affect communication negatively as well, as Randal Munroe's Thousand Word Challenge showed.

Re: Patterns in Confusing Explanations

#16

Post by ChrisKnott »

elboru wrote: post #12

Another pattern I usually encounter is explaining the how but not the why. Trying to understand how a complex mechanism works is hard, but it’s harder if you don’t know why the mechanism exists in the first place. It would be madness to start studying how an airplane engine works without knowing it is used to impulse a flying machine.

I particularly appreciate when very mature projects still reference the simple old 1.0 way, and why they had to change it to the current mountain of "ContentStore implements AddressableDevice" crap. I'm just trying to get Hello World up and running why can't I just pass a folder as string? Oh... This was brought it to support high availability remote data storage...

The experience of starting with something like Lucene at v8.0 is very different from someone who started when it was simpler and probably has both knowledge of and need for any new complications.

Re: Patterns in Confusing Explanations

#18

Post by bawolff »

n3k5 wrote: post #11
carrolldunham wrote: post #5

Earlier quoted context omitted.

I dunno... they each seem pretty self-evident.

They could be (and even seem) much more self-evident (and valuable as a tl;dr) if they were one-sentence summaries instead of a copy-paste of a paragraph from the beginning of the linked page.

Its a tl;dr. If you write 12 sentences its hardly a tl;dr summary anymore.

I thought it was a pretty self-evident summary. The article is great too and goes in more detail, but i have trouble imagining anyone saw that summary post, and was like "pattern 11: no examples" - i have no idea what that could possibly mean

Re: Patterns in Confusing Explanations

#19

Post by throwaway81523 »

detaro wrote: post #13
throwaway81523 wrote: post #9

Decent post but we just saw this yesterday. https://news.ycombinator.com/item?id=28246519

two points and no comments doesnt count as a duplicate on HN, so please don't point cases like that out. https://news.ycombinator.com/newsfaq.html

Oh that's interesting, thanks.

Re: Patterns in Confusing Explanations

#20

Post by discreteevent »

pattern 9: starting out abstract

That's the most important one for me. I've always thought it was the difference between a good and bad teacher. If you don't start with concrete examples then the listener has no where to map the abstraction. If you start with a couple of examples the listener will start to abstract by themselves.

Experts forget that they themselves started with examples.

Post reply on HN