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

21–30 of 168 posts

Re: Patterns in Confusing Explanations

#21

Post by heavenlyblue »

null_object wrote: post #4
beprogrammed wrote: post #2

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 pattern 5: unrealistic examples pattern 6: jargon that doesn’t mean anything pattern 7: missing key information pattern 8: introducing too many concepts at a time pattern 9: starting out abstract p…

>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 a team member at work like you while me being the complete opposite. I am not sure I still understand them well enough to say whether they are just stupid or it’s me. But frankly at least once already there was a situation where they said that my explanation was too vague and I didn’t listen and then month later I re-read what I wrote and it was indeed vague now :)

So while I disagree a lot with your statement my experience told me that actually there’s a lot of truth to what you are saying.

Re: Patterns in Confusing Explanations

#23

Post by touisteur »

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.

You'd enjoy Richard de Crespigny book, QF72, about the A380 in-flight engine explosion incident.

One of the clearest reasons he could save the aircraft, is that he spent some time in France, meeting w/ the designers of the different subsystems, and asked (and was answered clearly) tons of 'why' questions.

Yeah yeah 'how' is interesting but in the end, the 'why' is far more important, but also rememberable, and it helps when the thing is broken or half broken and you have to operate it. And I mean the original 'why', not the post-hoc rationalization! 'oh yeah the special "attack-beak" on each wing is there to give more portance during the landing phase, now that it is in "secured mode" (blocked) I will miss % portance during my approach I need to adjust'. And it is secured in case of hydraulic failure or WTF to avoid triggering spuriously during high altitude flight, etc.

I was lucky some time ago to have him comment on a twitter thread about automation and human-aircraft interactions, when I talked about 'why's: https://twitter.com/RichardDeCrep/status/1358560210927771649

Record the whys, that's what jira, code comments, design and justification documents are for! Forget the myriad uml, merise, whatever young people use these days, give me 'why's !

I highly recommend that book and anything from de Crespigny.

Re: Patterns in Confusing Explanations

#24

Post by null_object »

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

> 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.

> (Not authors)Pattern 13: Using excessive prose where less will do

Ok I guess we simply have to assume that people know the underlying explanations for why assumed knowledge is a bad pattern.

Re: Patterns in Confusing Explanations

#25

Post by lmilcin »

I think confusing explanations are kinda same as your first implementations.

If you don't refactor it to clean up your model, it will stay confused.

Once I have some explanation, I try to "refactor" that explanation by understanding the exact meaning of specific words (domain model) of that explanation.

Once I understand exact meanings and relations between all parts of the explanation it starts making much more sense because it moves from specific (made for me) to general (made for every case).

Re: Patterns in Confusing Explanations

#26

Post by danybittel »

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 love, "Learning by invention".

Basically, you start with a problem, than the teacher "helps" to come up with a solution, (by hints / guides), which casually ends up at the solution implemented. I think it's one of the reasons people love to reinvent the wheel. When they invent something themselves they truly know it inside out. You can somewhat do it yourself, if say, you want to learn a new library, by first trying to implement the problem yourself, then take hints from the library and finally use the library.

Re: Patterns in Confusing Explanations

#27

Post by detaro »

bawolff wrote: post #18
n3k5 wrote: post #11

Earlier quoted context omitted.

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

The article also has that list at the start, so duplicating it here in the comments is just noise.

Re: Patterns in Confusing Explanations

#28

Post by mrspeaker »

amirGi wrote: post #22

My default mindset used to be “I’m not getting this -> I’m stupid”, and I’ve been slowly shifting my mindset to “I’m not getting this -> this is probably not being explained well”

Yes! Teaching is really hard, and is an independent skill from having knowledge about a subject. Many blog posts and articles are written by people who know the domain, but are not good teachers.

The same goes for teachers in general - you can have professors who are very smart, but are poor teachers. It's a completely different skill set... that's why it's so exciting when you find someone who has both!

Re: Patterns in Confusing Explanations

#29

Post by beardyw »

kbenson wrote: post #15
beprogrammed wrote: post #8

Earlier quoted context omitted.

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 u…

Sometimes a lengthy explanation is just a lazy stream of consciousness.

“I have only made this letter longer because I have not had the time to make it shorter.” — Blaise Pascal.

Post reply on HN