Hacker News Reader

Comment by wccrawford | Hacker News Reader

I find that egos can be really fragile when people are just starting to learn things. Pointing out the mistakes so quickly can seem like a great help (and it is!) but some people react like they're staring at the sun.

Instead, I find it better (except for how long it takes) to walk them through finding the problem as if it's really hard and just nudging them to the steps they'd need to take to find it themselves. They learn even more, and it doesn't immediately show the difference in skill between you and them.

At the very beginning, even a small difference in skill can seem like a lot to the lower-skilled person.

View on HN

Some people are lucky enough that the things they focused on early in life are things they were good at. Unfortunately, I think some subset of those people also develop an aversion to things that they don't appear to reach competence in as quickly as prior endeavors.

That's a shame, because often I think people that have competence in a subject come naturally to them end up at a disadvantage later, because their foundational knowledge is lacking (at least in cases where that's possible and learning was self driven).

One example of this is learning a programming language through doing compared to actual study and research. By "doing" I'm not referring to a project to cement details, but for example how most people know bash.

Another example would be spoken languages and some of my college professors. I'm not sure I ever heard anyone speak with as good of a vocabularity and diction as one of my CS professors that English wasn't his first language.

I find the opposite. If you know how it feels like to learn something you have a natural talent for, and you know what it feels like to be struggling, then you can choose to focus on the things that are most "efficient use of your time". Especially considering that life is short.

Of course, you can always choose to learn something you aren't best at, but at least you know the trade offs (i.e. needing to spend relatively more time to reach the same level of competence as more talented person).

I'm not convinced there is such a thing as natural talent. (there is such a thing as lack of talent) All the greats are just average people who focused until they became great.

You just have forgotten what it is like to be a child who knows nothing. I've been speaking English since I was a toddler, I'm learning Spanish now and I make tons of mistakes and often can't understand even a basic sentence - but in fact I'm a lot better at Spanish than I was at English when I had equivalent amounts of study into English.

Once you are a minimal level of competency it is a lot easier to study as well. So if you have only a tiny head start you will be top of your class, and that is always more enjoyable.

In my layman’s view it’s obviously a balance, like all things. Look at the top athletes - Michael Phelps has more upper body than he does lower. The best UFC fighters often have insane wingspan for their height (and therefore reach for punches). Usain Bolt is not a short man. Certain people are tuned for certain things. Then whether they combine that baseline with total obsession and hard work is up to them.

The mental sphere is where it becomes super vague for me. Did John Von Neumann just study really hard? The anecdotes told about Feigenbaum of Chaos Theory make him sound like a savant among savants. They just kept that childlike curiosity? Doesn’t make any sense to me. It seems they are tuned differently.

> I'm not convinced there is such a thing as natural talent. (there is such a thing as lack of talent)

....That doesn't track.

If there is such a thing as lack of talent, then "talent" is just "not lack of talent".

The concept of a thing called G factor shows there is such a thing as a natural innate talent.

I find slow-walking someone through a problem can sometimes come off as condescending.

I take a different approach where I immediately point out the issue, and if they get discouraged about how fast I solved the problem, I remind them that I’ve spent hours banging my head against the same issue. They will probably run into this same issue again, and get stuck again, but next time they’ll figure it out faster, and the time after that a little faster, until it’s basically instantaneous. And then when they’re instantly able to solve a problem for a newb, they’ll have to give the same explanation as I’m giving now.

The circle of life!

Even very senior engineers can make simple mistakes that can bruise their egos. Several years ago I was called into the office of the chief architect. I was also a senior engineer with a lot of experience, but he was quite famous (at the time) in the industry for his technical skill. He was convinced he had found a compiler bug. He had some c code that he had traced through the debugger at the assembly level. It was something like this:

if(/some really long boolean value with AND and OR clauses/); { /* some code to execute if TRUE */ }

He was sure that the if statement was FALSE some of the time, but the code inside the brackets would always execute. He spent more than an hour pouring over the code.

It took me a few minutes before I noticed the semicolon at the end of the if statement. I'm sure he felt stupid when I pointed it out.

> I'm sure he felt stupid when I pointed it out.

He certainly did. There is no amount of experience that makes people not feel stupid about those. What changes is that you learn to not be affected by it, because you know that it's not a personal flaw (at least not one specific to you), and while you can improve on it, you can't completely fix it.

But the alternating between feeling like the dumbest person on Earth and the smartest person on Earth never goes away.

You develop tunnel vision and, whether someone points it out to you or you look at it with fresh eyes in the morning, it's a head slap "Duh."

Yep. I've learned over time to just walk away from problems like this that make me go "that's not possible!" or "there must be a compiler bug!"

After at least a few hours away (ideally not coding) your fresh eyes will often spot it.

Similarly, demoing the bug to someone else is a good way, and often through the mere act of demoing it you'll find it yourself (also known as "rubber ducking" [1]).

[1] https://en.wikipedia.org/wiki/Rubber_duck_debugging

Or just better software development practices that can eliminate whole classes of bugs. If the developer was instead in the habit of not putting huge expressions inside if() statements, he might have caught it himself. Consider:

    bool condition = /some really long boolean value with AND and OR clauses/;
    if(condition); { /* some code to execute if TRUE */ }

Two advantages of doing it this way:

1. It's much easier to notice that incorrect semicolon

2. Even if you don't, you can stick a breakpoint (or log) between when condition is set and when it is evaluated, to convince yourself it works.

3. All modern compilers will produce the exact same code as they produce with it mashed into the if()

I agree. It also really helps when you want to negate something.

if(!condition) is a much better read and less prone to errors than trying to negate a long statement inside the if().

This pattern also eliminates duplication. I have fixed bugs in code where the same long if condition was duplicated several times within the same function (probably with cut and paste). This wastes cycles recalculating it each time and runs the risk of changing one of them without changing them all.

    bool subCondition1 = /* something kinda long */;
    bool subCondition2 = /* something also kinda long */;
    bool subCondition3 = /* something absurdly long */;
    bool condition = (subCondition1 && subCondition2) || subCondition3;

    if (condition) {
      /* do something */
    }

where, ideally, the sub conditions all have meaningful, relevant names that succinctly express what they were testing for.

Good point, code readability is often the best thing to optimize for.

Your change also got me thinking of unit tests: at some point it becomes worthwhile to have dedicated tests on that condition, and that's often easiest by putting it in a static method, and that also improves readability.

In those situations i do feel stupid but also feel relieved. Fixing a semi-colon is easier than fixing some major logic flaw that could have way deeper and worse ramifications.

I think it happened enough that some newer compilers actually post a warning message when it is encountered. Just like switch statements when you don't have a break; statement for every case: clause. In some cases you want the logic to fall through, but it can cause havoc when you didn't want that and you just forgot the break.

Perhaps this is really stupid and juvenile, but the show Adventure Time had an episode where one of the characters said “sucking at something is the first step to being kind of god at something.” I think that’s an important lesson a lot of people should learn. Going out and sucking it up is awesome if it means you’re getting better at something.

On the other hand, toxic positivity sounds exactly the same. So which is one and which is the other? What to do when you suck at something? Persevere or pivot? Both are praised in TED talks, but you just can't pursue them at the same time.

Sucking at something is the first step to being kind of good at something. It's impossible to not suck at something new, unless you are a prodigy. Whether or not you want to persevere in the face of prolonged sucking is a personal decision.

> Persevere or pivot? Both are praised in TED talks

For good reason. Wisdom is recognizing which is correct for the current situation. There is no rule that applies to every situation. You have to make a choice and stick with it. Sometimes that means you try something decide it isn't for you. Sometimes you try something and even though you hate it, someone needs to do it so you keep at it - of those sometimes you will turn out to love it in the long run sometimes it was just a job. (it seems to me the only people who actually hate it are justifying a mid-life crisis that turned them to something new - if the mid-life crisis hadn't worked out they would have returned and been happy)

There is a old prayer that goes something like:

May God grant me the courage to change things that I can, the patience to endure the things that I can't, and the wisdom to know the difference.

I think one of the quickest ways to make life easier and less stressful is to try to ignore the ego as much as possible.

Easier said than done, no? I think one of the defining qualities of an ego is deceiving the individual into behavior - ymmv. But that’s why failure, psychedelic experiences, and more are important (imo) - for keeping the ego in check

Sure, in the same way that "surviving to old age" is easier said than done. It's true, but what choice do you have?

Indeed. Parent post did mention “try… as much as possible” and that seems appropriate.

Show a person the bug, you’re on the hook forever. Teach them how to debug, you’re needed less and less.

Easier said than done, I've found. "Check the logs." is a statement I have to utter far too often.

Admittedly, when I started at the present company, I also remarked "this logging tool [Sumologic] is pretty difficult to use". The response from my senior engineer at the time was "it really isn't that hard." and then she didn't answer the question I had and made me figure it out on my own. It felt a bit brusque at the time, but it was very useful in the long run. I did end up figuring out how to query Sumo (I still maintain that its UI is gawd awful), and that's enabled so much debugging.

I think I also ended up authoring our internal documentation's page on how to effectively query in Sumo, which I feel has been read never.

Kill the ego. The less allowance we make for hurt feelings the more we can live in a world devoid of toxic ego-driven politics. We should all carry the expectation that professional criticism be received professionally.

Hm, that's an interesting way to look at it, though I don't like framing it as ego fragility as that seems unfairly negative.

I've reflected on this point quite a bit because I really struggled with it when I was teaching myself how to code. It's extremely demoralizing in the beginning, because of a couple of root causes (IMO).

1. We place a lot of cultural value around "genius", and we often ascribe that quality to programmers, mathematicians, etc. While some of them undoubtedly are, it's not clear what that genius actually is, and a great deal of people mistakenly believe that they don't have the "right brain" for it, or are not "smart enough", because they don't feel like geniuses. When you make several mistakes when learning a new activity, every mistake reinforces that perception.

2. There are two relationships you can have with technology - that of a consumer , and that of the provider. As a consumer of technology, your perspective is that "technology works", and if it doesn't work, then something went terribly wrong. But once you become a provider of technology, that perspective is flipped. Technology is broken, and if it works, then something went wonderfully right. It takes time to develop that perspective, and so young engineers will have their programs break constantly, not realizing that "broken" is the default state of the world, and in fact now their job is to make things work. Of course it's broken.

Reply on news.ycombinator.com