Why we are much smarter than we think we are | Hacker News Reader

Why we are much smarter than we think we are

leostartsup.com

43 pointsLeonW15 comments

Am I the only person who considers use of the word "smart" as a leading indicator of the absence of intelligence? The term is so vague as to be utterly meaningless, and is usually a signal that we're really talking about someone's insecurities, their feelings of inadequacy, or their passive-aggressive megalomania. /psychobabble

Does the phrase "work smarter, not harder" trigger your alarm bells too?

You're probably past the point where this sentence is useful. Did you often thought about that ? Most people didn't.

My immediate reaction:

- There are circumstances where talking as if you know what you're talking about when you really don't can do more harm than good, both to you and to your audience.

- The idea that we should stop learning before we get so deep into a subject that we can't immediately communicate our insights to a layperson (which is not very deep at all) smacks of anti-intellectualism.

Hey szany, thanks for the feedback, I can totally understand where you are coming from.

That's interesting and I totally agree, talking as if you know all about the subject can certainly do more harm than good. What I tried to focus on with this post, is to see everything you do somewhat like an MVP. The key is to keep getting feedback on everything you do and shipping stuff as soon as you have a slight grasp of the situation. I didn't mean to pretend you are an expert but to be content with the amount you have learnt and sharing it immediately to learn more faster. Does that make sense?

I had a similar reaction as szany. I think part of the problem is that your post has an really shallow example: knowledge of bars and restaurants in Hong Kong. That's not a topic that would ever require very deep study.

There are a range of subjects which really do require deep study before you should be spouting off on them, for instance: compilers. I've got stacks of books on compilers and have spent a decent amount of time studying the details of Lisp implementation, and I'm not sure there's much to be gained from sharing what I know. I would just be regurgitating what I've read in books which present the topic better than I could, so I don't think it would be beneficial, unless I were to specifically seek out feedback from experts, but that's not what you're talking about it seems.

I just think there are shades of gray here and your post might have benefited from some more specific examples rather than presenting the idea that we are in general "smarter" than we think we are. I find it humbling and inspiring to realize how much "smarts" I lack and how much I have to learn, when it comes to deeply technical subjects.

I guess that Leo's post resonated with me because I find that the sharing of what I've learned so far helps me learn it better - and sometimes, there are people who are in the same boat as you before you came to some realization.

That is to say, sometimes I get stuck on something that should probably be easy - and when I find the crux, the thing that got me unstuck, sharing that is beneficial to people who are stuck in the same way. We all think and learn differently, so if there's just one other person out there who thinks the same way as me and might find things easier with the same realization I had...well, I think it's worth it.

The act of sharing also requires you to evaluate what you know . It is through the act of teaching that we can be more certain that we have truly learnt. I myself often think that I know something, but when I try to explain it to someone I often find nuances that I hadn't considered yet.

I don't think Leo is talking about giving the keynote adress at some GCC symposium but rather sharing with the intent of gathering feedback as to gain further insight into the subject.

It's not so much about training someone as it is about growing knowledge together.

TL;DR: Go deep, but make a map.

I would think that complicated topics like compiler construction or LISP implementation actually benefit from deep knowledge and understanding. There are a few topics where I feel like I have achieved some kind of mastery, and it comes with

  a) the knowledge that I actually know nothing about the subject itself

  b) a kind of uncanny "wisdom" about where to look for problems, further reference

  c) the ability to explain the topic in terms of very simple concepts and examples, while still being able to answer most questions.

A concrete example I like to give about this is: I've been programming with all my heart for 18 years, 8 hours a day. Yet I still feel as dumb in front of a for loop for fear of making an off by one as in the first days. What I am able to do now however is know where the dragon lays, double check it, write some tests around it, and being able to pinpoint the problematic for loop in the complete program in a "usually" pretty short time. Or being able to look at the compiler part responsible when it's actually the compiler making the off by one. Or checking how threadsafe the whole thing is. If that doesn't work I could still rewrite the whole thing in a recursive fashion. Or asynchronously with a state machine. And sometimes I'm just a moron and I made a stupid mistake and took 5 hours to find it, and feel as much as a newbie as I did when I was 13.

For example, once you know "everything" about compiler construction: LALR parsing, AST construction, register allocation, SSA trees, static analysis, written a few compilers for your own usage, extended existing ones, wrote a few backends for LLVM, created a language of your own with some following on the internet, you realize you know nothing. You don't know how register allocation works on an IA64, or maybe you have no grasp anymore about how register banks work on modern CPU cores, or maybe you have no idea about how a JIT on ARM would work, and that's just register allocation. You know that you've given it a really serious try, but there is just no way that you actually know anything about compilers.

However, you are able to explain what a compiler does to a layman in simple terms, transforming a formula with multiplications into a formula without multiplications. You are able to explain what a compiler does to a beginning programmer by actually implementing one right in front of her, in 80 lines of python. And you are actually able to answer her questions, which can be extremely difficult questions, while being able to gauge the complexity of the answer and tailor fit it. That's why I think that deep knowledge is very valuable.

What I find very important to write down (and maybe communicate to others, I don't know) is the steps you are taking while learning a topic, the resources you are reading, the conversations you have. I learnt a few artistic fields in the last years, where practice as a physical and mental activity is there to engrain an intuitive understanding of the topic in your soul. In drawing and in music, it's more through practice than through thinking that I acquire new concepts. I play and focus and draw and do some exercises or copy some of the masters, and one day I wake up and I somehow know it's there. And the way and practice and exercises that led to that insight are very easy to forget. It's very easy to forget that it's probably from copying this one painting over and over that I suddenly understood how to render wood. The only way to communicate that kind of knowledge to other people is to have a whip and tell them "copy that painting 5 times over, then you'll understand" because it is so incredibly hard to fit that knowledge into words.

The process is probably slightly the same for more "left brain" activities, but it's easier to be rational about the way to go about it. Still, I now try to write down which book, which exercise and which program I did, in the hope of one day tracing down how some of my "expert" traits came to be.

I think the right attitude is to have enough humility to ask questions, not to assume enough expertise to give answers.

Well see the problem is that we're not all smarter than we think. The Dunning-Kruger effect means that some of us think we're much smarter than we actually are. Unfortunately, 99% of the code out there seems to be written by people in this latter category.

I find it interesting that the author posits that those who sell themselves as being smart therefore are.

Well they were smart enough to realize that that's enough to convince most people.

I can see his point in the context of marketing and pundit-ism.

In the context of anything actually intellectual this is all just silly but the author isn't interested in or speaking to that world.

Great post Leo. There are some great comments here, but I have a feeling you did not intend for people to think they are smarter than they are.

Rather, I think the point you may perhaps be trying to make is that we should all be very pragmatic about sharing our lessons, no matter what stage we are currently at. This is something I believe in very much. I feel far too many people wait until they have achieved something they perceive as substantial before they share their lessons or achievements.

I think we can all benefit by sharing our lessons much earlier and more frequently. If we do it in an open way, where we acknowledge we are on a journey and will need to make adjustments to reach our goal, then this humble approach can really bring some fantastic advice from others who are just a little further along. And, like you've said, there are without a doubt people not as far along who can benefit too.

Cheers Leo!

I think the main problem is that we are in general unaware of what others do not know. I think we all extrapolate that if we know something, others must also. I'm not sure if that is a great self-centered reflective view we all take or simply optimism for our fellow man. Either way, I find that opportunities are missed because of this. I have many colleagues who are experts in their field but believe that what they know is simply common sense.

Reply on news.ycombinator.com