[anyfoo]

Maybe everyone sees this differently? Or maybe is more than one viewpoint to it.

For example, if someone tells me that something is "actually really simple", and I did not get it yet, I tend to think that I likely (not certainly, but likely) have not found the right approach to that something yet, and once I found that way to look at it, things will resolve itself.

But if people assure me that something is "hard to learn" or "hard to get", I'm rather suspecting that that thing is full of unwieldy complexity and/or unintuitive aspects, and unless I'm either up for the challenge (definitely the case sometimes), or learning it is crucial for achieving a certain goal (in which case it may turn out to be fun after all, even if still hard), I might think twice if I want to put the time and energy into it.

In the case of DNS, which I've learned in the nineties, I found the principle simple and elegant, the tools and software unwieldy and sometimes arcane, and a large multitude of little details that are not strictly necessary for understanding and using DNS in basic ways, but that can get important when either debugging or working at scale.

So, in the case of DNS, I'd say the answer is "depends on how deep you want to go", but don't shy away from the simple and elegant principle, even if the arcane software (it has gotten better, though) stands in the way.

I think that matches the content of your article overall?

[saghm]

> Maybe everyone sees this differently? Or maybe is more than one viewpoint to it.

> For example, if someone tells me that something is "actually really simple", and I did not get it yet, I tend to think that I likely (not certainly, but likely) have not found the right approach to that something yet, and once I found that way to look at it, things will resolve itself.

At least in my experience, people asserting that something lots of people have trouble understanding is "not hard" are doing so as a flex at least as often as they are trying to be helpful, so I'm surprised that a lot of people don't make the same hypothesis you do. When someone does so while also touting their status among their peers due to their knowledge and talking about how anyone could do it by just putting in the work, it's not surprising that people might interpret that as implying that people who don't have the same knowledge are either too lazy to put in the effort or not capable of it, regardless of whether that was the intended message. If the goal is to try to help people, it's more effective to communicate in a way that conveys understanding and not judgment; if someone doesn't care to improve their methodology of helping people, that's fine, but it does raise more doubts about whether they're being honest about their intentions.

[vasco]

> anyone could do it by just putting in the work, it's not surprising that people might interpret that as implying that people who don't have the same knowledge are either too lazy to put in the effort or not capable of it

Not spending time on something doesn't mean you're lazy or stupid, that seems like your own leap. If you choose to interpret in a charitable way it just says: "if you haven't looked here don't worry, it's not that hard, you'll just need to spend some time".

I haven't looked under many rocks I've walked by, talked to everyone, read every book I encountered, doesn't mean I'm stupid or lazy, I just haven't done it.

[saghm]

My point is that if your goal is to teach people, you should care about framing things in a way that's conducive to the people who you want to teach. Dismissing fairly common insecurities because you don't happen to have them will significantly reduce your effectiveness at teaching, and if you don't find it worth the time to take into account feedback about how to craft your messaging more effectively, I'd argue that your priority never really was teaching in the first place.

[zhte415]

Your post reminds me of three things -

The nature of what's being learnt. Some things require a continuity - to understand B, prior A is needed (or helps, to understand faster).

The method of learning. Book/theory-based, or practical? For either, what's the nature of scaffolding (self, or via resources) to help leap the chasm? If testing one's self, what's the complexity and can that complexity be broken down into simpler (or more discrete) parts, (perhaps testing working better in smaller parts)? Perhaps A isn't fully (or at all) required to 'know' B, depending on how it's learnt. Which goes on to -

The nature of the learner (at that point for that task). Someone that's looking to solve a task, somewhat surface, or someone that's interested and will go deeper into edge cases or approach with greater curiosity?

[I'm skipping the nature of the learning/knowledge, since 'resolving DNS' is a pretty externally verifiable result. However it might be fruitful to consider the nature of the learning is not only 'resolving DNS', and even if 'resolving DNS' fails, learning always happens (intended/unintended, positive/negative, a can of worms there).]

You point out that 'easy' and 'hard' are motivators that might have unexpected, or the reverse, effects vs. intended, depending on the reader. When putting it into those 3 parts, perhaps this shows the usefulness of framing.