31 comments

[ 0.21 ms ] story [ 77.5 ms ] thread
This is my prime concern when teaching and writing. Other terms for this I've seen is Expert Blindness and Expert Blindspot. A related term I've made up is Cognitive Empathy; ones ability to overcome this curse.

I've struggled a lot myself in school, and I think that had something to do with this.

With my current experience, just about any textbook I pick up and start reading, I can often pinpoint a lot of issues in the text that has this problem.

I always liked people who were very smart but without losing touch with simplicity.
I think the reason why Richard Feynman was such a great orator is that he could overcome this gap to a certain extent.

Matt O'Dowd on PBS Space Time also has a great way of breaking down really complex theories (especially if you watch a set of presentations in order).

[PBS Space Time (YouTube)] https://www.youtube.com/channel/UC7_gcs09iThXybpVgjHZ_7g

I love Feynman he was an entertainer, but honestly, even CalTech admitted that nobody really advanced in understanding or created anything out his works, its all like intellectual mind candy.

People who understand things who can roll up their sleeves, and get the job done, are a rare breed, this stuff can't be taught.

Later, after you create you can return to Feynman, have a cold-beer, and listen to his lectures and have a good laugh.

Yea...his intro series seems to be physics concepts for the non math based majors.
Have you read the Feynman lectures? They're not exactly trivial. They have some diversions towards casual descriptions, but they're quite grounded in mathematics. I haven't watched his course lectures, but I have a hard time believing that they're that different.

He does write explicitly non-math based works as well, like the (IMO excellent) QED book. But I also have his lectures on computation book here, and I had to leave a good number of problems in it unsolved.

Yea, you can watch on YouTube. They aren't very math based. Of course the theory is mathematical, but you won't get that without equations. I'm just talking about his intro course and have never read QED or his lectures on computation. A great scientist making more accomplishments in an afternoon than I will make in my lifetime :).
I am no expert, but do people no longer use Feynman diagrams? Were all his theories on QED superceded by new work?
"even CalTech admitted that nobody really advanced in understanding or created anything out his works"

Oh, you mean the work Feynman did for which he got the Nobel Prize in Physics?

Good to know that CalTech considers that worthless.

> he could overcome this gap to a certain extent

I wonder whether this was due to his habit of regularly re-evaluating his understanding of more advanced concepts from first-principles. If so, that could be a technique to counter the curse of knowledge.

And this is why I used to joke with my tutorial partners at Oxford that the more titles someone had, the worse they were at teaching. I did find that the best tutors tended to be ones who were PhD students, with the content somewhat fresh in their minds.

Part of it is that when you become very senior, you start to become an administrator of a little research business, rather than a teacher.

Another part is that once you've internalised something, you cannot fathom not knowing it. Imagine not knowing what the complex plane is, and trying to explain it to someone who only knows what the real numbers are. Your explanations just won't make sense until you can place the real line inside the complex plane, and shepard the learner to the same state.

This is something I've thought a lot about as I've tried to teach basic skills at $corp to smart people with relatively little formal comp sci or programming experience.

It led me to write two books using the Hard Way method:

http://learnbashthehardway.tk/learnbashthehardway.pdf

http://learngitthehardway.tk/learngitthehardway.pdf

It doesn't assume zero knowledge, but it's so hard to know how to pitch. What I like about the hard way method is that typing stuff out forces you to engage the material and encourages self-learning through the topic.

Just a heads up - on the learn bash the hard way section 1.6.2 you tell the user to enter csh but you never tell them to exit, so a beginner following your instructions would be doing the whole tutorial in csh, not bash.

Granted, your comment about $ vs % and the fact that all the following code snippets have $ they could figure it out but still.

Thanks - just the kind of thing I need pointing out :)
Git book, page 36. "look at the diff of the commit that caused it and" ... the sentence just cuts off there.
A table of contents would be helpful!
He that gaineth knowledge, gaineth grief, for in much knowledge, there is much un-happiness.

That is the curse of knowledge, the more you know, the less happy you are.

Today they say "You Can't Handle the Truth", now many schools are saying the 'truth' is just a tribal crutch.

It used to be simple pure Epistemology was factual truth such as "2+2=4", now somebody will tell you otherwise.

"An educated man is somebody that you can explain your philosophy too, and he will not punch you in the face".

Knowledge, Tolerance, Understanding are all lost, but never mind, we can still toil are lives away for the almighty US-DOLLAR ( faux fiat toilet paper, another unworthy god ).

I tried to teach my girlfriend programming once. She understood stuff that took me years in a few days.

When teaching, I remembered how hard concepts of variables and functions really are. It's really hard to explain it to someone.

God's truth - the honest, God's truth, is that between a standing start with 0 experience and a senior programmer there is very little actual INFORMATION.

Everything else is teachers and documentation and compiler errors being stupid.

For example when starting with C++ who starts out with the importance of semicolons, how you have to not leave them off, find the missing semicolon, and have a teacher watch over you pointing out your missing semicolons? Nobody. You get a stupid abstract sentence : "statements are terminated by semicolons" after some bullshit definition of a statement. You can spend 90 minutes looking at definitions of the latter without acquiring a skill that the former could show in - not an exaggeration - 17 seconds.

17 seconds : 90 minutes is 1:317, so 3 years becomes 3 days of someone actually showing you.

You know it's true. You've seen it!

True. Laravel is probably the best PHP framework I've come across but the error display page seems like the only thing I didn't like. It can be quite daunting at first; errors that are easily decipherable using PHPs inherent error message display can seem quite arcane using Laravel.
Perhaps between 0 experience and a junior programmer, but not a senior programmer; you need a lot of experience with different designs to gauge how to model and approach different problems appropriately. There are many working solutions to problems, but the space narrows drastically when you consider what's appropriate to abstract and what isn't, what can be maintained easily and what can't, what can be tested easily, what can be explained easily, etc.
But that experience, isn't exactly information. You can't really learn it in a book... My comment was about passing on the required information -- and how much of it there is (little) and how well it's hidden (very well, in a pile of things that will waste anyone's time.)

your sibling comment (by andromeda__) gives a good example.

Sure you're not just smitten? Really? Stuff that took you years took her days? Kindly care to expound?
Perhaps he counts his years as a kid? When stuff seems magical, mystical or at least very very fuzzy.
Well, I started programming with 15.

But yes, I'm not a very smart person. I had to learn things a few times till I understood them :/

I don't find this too shocking. First, they never said she learned everything that much faster, just that there were some things she did learn much, much faster. Secondly, a big reason to not "understand" something is that you never considered it one way or the other. It's easy to just barely get by without knowing what's happening because it works so you move on to something else and then suddenly one day you see it again and go "wait, why?" and then you figure it out. You learned it quickly the moment you realized it was something you needed to learn, but it might have taken literal years before you considered it was something to learn. This kind of stuff I think happens a lot if you're self-taught because programming often (particularly in older languages and environments) involved some weird forms of setup that the beginner could skip by just copy-and-pasting the correct "template" without considering what it was doing.

For me, understanding what was involved with "installing" a library to use in Visual C++ took years even though it's not that complicated. I just followed magic instructions and if things didn't work, then I would just have to ask someone for help. Eventually I understood the difference between the dll and the header files, static and dynamic linking, etc. Someone could have explained that to me literally years before I learned it myself, but I spent years just assuming it was essentially unknowable.

I did an small experiment once: giving typical logic puzzles to friends (generally oriented to exact sciences) and family (mother, grandmother, girlfriend now wife, etc). The family group performed faster. I review the methods of each group and the friends group tried to use more formal methods.

Obviously none of these people were hardly into solving puzzles. I think novelty and lack of frustration in this field makes motivated people perform better. Take this with a grain if salt but there are neuroscience studies pointing to novelty as a good way to learn. It is easy to find studies about it like https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3858647/

Keep in mind the converse as well, when negotiating. i.e. you don't want to inadvertently leak information by assuming they know as much as you do.