I've found this to be particularly important with things that are fundamentally simple but very abstract. You can teach people quite a bit of advanced mathematics if you don't tell them it's supposed to be difficult; but if you start out by mentioning that it's graduate-level algebra or something, they just shut down and don't even try.
I think this is a big part of the "monad problem", coincidentally. People don't understand monads because everyone says they're impossible to understand. When I came at them, I expected something complex and obscure. I couldn't see their actual simplicity—they have a tiny definition, after all—because of my expectations. On the other hand, when I went to learn about arrows, which are a similarly abstract concept, I didn't have nearly the same difficulties because I wasn't expecting anything and could take the definition as it is. I had a decent understanding of arrows before a decent understanding of monads, which is a shame because I don't really like arrows!
Now, I suppose that this doesn't mean you should call everything "easy", but you should definitely not perpetuate the idea that things are difficult! (Unless, I suppose, you want to intimidate people rather than teach them.)
agreed. There's also evidence to back that up.
source: Get Anyone to Do Anything (David Lieberman, Ph.D. Psychology)
The second factor in making sure that you are understood has to do with expectation. Numerous studies show the powerful role that expectation plays in understanding and include such finding as (a) girls who were told they would perform poorly on a math test did so; (b) assembly line workers who were told that the job was complex was and difficult performed less efficiently at the same task than those who were told that is was easy and simple; and (c) adults who were given fairly complex mazes solved them faster when told that they were based on a grade-school level
Much more valuable is giving people the tools to (1) understand why something exists, (2) what problems it was designed to solve, (3) why it is designed the way it is vs. other possible ways, and so on. Everything is "easy" once you've viscerally experienced the problem yourself and spent some time tinkering with possible solutions.
Monads are "hard," for example, not because they're technically complicated. Their definition is not so much abstract as austere, as you point out. Rather, they're hard because the beginner doesn't see how they are an attempt to solve certain problems with side effects in a purely functional language which prioritizes referential transparency.
Both "easy" and "difficult" are dangerous words because the student quietly elevates them to statements about their own intellect. If this "easy" but I can't do it, I am stupid. If this is "difficult" but easy for me, I am smart — smarter than those other students who are having a hard time.
IMO, it's really the fixed mindsets we need to combat, not one particular axis of fixed thinking.
I believe the use of both of these terms comes from inexperience, or as you suggested, the desire to intimidate.
Learning how to learn is a lifelong thing, and many people simply don't have the chance to be led through in this way to the point where they can do it themselves.
edit: in regards as to what's "the right thing" to say - I'd start with "Well, let's look for something easy first"..
Case A: The student has a genuine interest in the material. The student wants to be successful, and has worked tirelessly to configure and/or understand a given problem or task. The last thing the student in Case A needs to hear is "It's easy". Obviously the problem, to said student, is not easy. This can hurt overall student moral.
Case B: The student has not a complete devotee to the material. The student is "trying it out". The student thinks the material could be achieved without professional education or training. The student in Case B may need a bit of convincing. Telling that student that something like this is "easy" could be beneficial in this case. The student will believe that understanding of the material is at least achievable.
Saying things are difficult sets up negative expectations, saying things are easy means disappointment when we have unrealistic expectations.
I still think it's fine to say that most people seem to find X harder than Y…
"Somebody somewhere figured this out. If I sweat it, I can too."
Of course, it won't work all the time[1] but the attitude serves me well I think.
[1]: I will never become a great painter because of: physical capacity, interest and willingness to devote my time to this.
Last I heard, the best approach is supposed to be telling kids they got the right answer because they are working hard. Well, I've had that one backfire. "This is too hard!!!!"
As a high school physics teacher, I had students look at me like I was a genius because I could do inclined plane problems in my head. But in reality, do 50,000 incline plane problems, and you'll probably be cranking them out too!
Tell them "This CAN BE easy with some work" and you're doing your students a service.
Because although programming is something I enjoy, it hasn't necessarily always come easily to me. I'm not a natural. I learned to be good(ish) at it by slogging away doggedly.
So to me, it's a long -- and never-ending -- journey of things that are difficult... until they become easy. Being confused about something is a constant fact of life, for me. But so is a growing list of things that, in hindsight, now seem easy.
I wish I knew some pithy, quick way to say that to people, so that it's the positive message I mean.
Edit: Only really applies to a very specific kind of situation. Doesn't help if the person has already encountered that type of problem, and had their confidence shattered by a bad teacher or a hostile environment. My sister in law is a math lecturer who often does remedial classes, and she spends a lot of her time trying to teach students not to be afraid of the subject matter.
AFTER EDIT: I simultaneously posted with two other participants here who both made good points. Let learners know that something that feels not easy at first can become easy after practice, and let learners know that sometimes topics may be reasonably easy for them even if other people have said that the topic is hard. I have to emphasize these points to in my classroom teaching.
I need some insightful advice on how to help her out of this mindset. I've googled and looked at books, but there's a lot of regurgitated crap out there blocking me from finding the good insights.
1) http://www.epsiloncamp.org/ProblemsversusExercises.php
2) http://www.epsiloncamp.org/RepetitionPractice.php
and
3) http://www.epsiloncamp.org/LearningMathematics.php
to lay a foundation for their own thinking in communicating with their children. Please allow me to ponder this question overnight in my time zone and maybe I'll come up with more specifics that can arise in a future HN thread or by personal email. (I'm really tired this evening, after cloudy and stormy weather all day, so I'm not sure I can do your question justice at the moment.) Thanks for asking.
A math professor was giving a lecture and then remarked that something was trivial. Somebody raises an objection and asks why. The professor stops and thinks hard for the rest of the lecture, then finally remarks: "Yes, I'm right, it is obvious."
http://en.wikipedia.org/wiki/Triviality_(mathematics)
(Obvious/easy to prove)
Of course, this kind of depends on the level of the author - some authors don't fully manage to put themselves in the shoes of the reader and take too much knowledge and experience for granted.
Saying something is "easy" or "obvious" is useful! It may demotivate if done poorly. However with a proper teaching approach it also signals what SHOULD be obvious. If it's not obvious to you yet, it's important to learn and understand why not, and eventually it should become obvious.
I'd like a textbook in HTML, where when it says "trivial" I can click and expand it to the proof, with relevant references that I can keep going through until I understand how we got there.
If you know how well the person you are talking to know the material you are talking about, then I don't find calling the thing 'easy' is humiliating at all, instead it is a effective way to say "no worries, just do XXX and you are good". A rule of thumb is when you are not sure if it is appropriate to call something easy, just ask the person you are talking to whether he knows that thing. Why stopping using the word 'easy' when we are sure all parties of the conversation gets what you are talking about and think it is indeed easy?
> A common joke in the mathematical community is to say that "trivial" is synonymous with "proved" — that is, any theorem can be considered "trivial" once it is known to be true. Another joke concerns two mathematicians who are discussing a theorem; the first mathematician says that the theorem is "trivial". In response to the other's request for an explanation, he then proceeds with twenty minutes of exposition. At the end of the explanation, the second mathematician agrees that the theorem is trivial. These jokes point out the subjectivity of judgments about triviality.
from http://en.wikipedia.org/wiki/Triviality_(mathematics)
Trivial doesn't mean easy. Just that it has been shown before or that new information won't be derived in the proof.
Something I'd like to see in whatever replaces Elsevier & Friends is a community markup tool for all papers. Wherever a step has been omitted the community can step in and add a side note explaining and discussing the steps. This would have three huge benefits:
* Easier for neophytes to learn a paper's domain and assumed knowledge.
* Ready-made useful homework assignments for advanced undergrads and grad students: "Fill in the details of this paper."
* Ongoing "reviewing" of papers, leading to more corrected errors.
I get what the OP is saying, but sometimes, the word "just" is justified. It is simply a command, an invocation of a program that is non-trivial itself, but the use of which has been made easy for laypersons...and by laypersons, I mean people who don't study the SSH protocol.
And I think it's important to tell people that things like "just ssh into..." are easy...it's not the action that is hard. However, understanding why you'd ssh into anything, rather than, say, FTP, or whatever...is difficult...I don't mean necessarily studying the SSH protocol, but why ssh is used in modern deployment workflows.
But until students just SSH in, they will never get to the why. So I don't really know what to tell them, except just try it.
The fact is, much of software development is really the application of arcane processes, commands and procedures to solve problems. New people don't know your particular process or tool suite. I worked in an office that used Rational Synergy and Doors. When I was new I had no clue how to use these properly. After some experience they became easy, but going to a colleague and being told "that's easy, just X" was rarely helpful, because it turned out that X was actually A, B, C and D. Admittedly, sometimes A and B were just "click on the options menu", "click on the <entry>", but finding C and D required knowing that.
These sorts of things are, in fact, easy, but they're still arcane enough that when you provide an answer it should be a complete answer. Anything less will result in the questioner being unable to complete the task and feeling like an idiot, possibly being too embarrassed to go back and ask a followup because you told them "it's easy". If, instead, you told them "Oh, that's X, you need to do C and D", you've not poisoned them with "just" and "easy". If they don't know how to do C then they can come back to you and you can say, "Oh, you need to do A and B, then C is the third option down in that tab."
1) How easy/hard things are to learn or do the first time, or the first couple of times, or whatever.
2) How easy/hard things are to do even when you know what you are doing.
Very many tasks are easy or hard w/r/t (2), and are often referred to this way by the teacher. This may be quite different than whether they are easy w/r/t (1). As a student, it's important to use context to determine if an 'easy' task is supposed to be an easy (1), an easy (2) or both. As a teacher, it's critical to be clear about this.
If something is an easy (2), it may be a hard (1), because it's abstract, poorly explained, one has improper expectations or training, or it's just plain tricky. I think this is what the article is referring to.
In this scenario (easy (2), hard (1)), it's important to describe the task as such: If it keeps being hard for the learner to do, it is a good indication that the approach is wrong, and he or she needs to step back and evaluate things, seek more help, etc. Rolling a kayak is like this. It doesn't require a lot of physical effort to do, just proper technique; so if the kayaker is using a lot of strength and it's still failing, s/he needs to work more on being smooth, keeping his/her head down, and so forth.
Contrast this to something that is a hard (2): If a large amount of effort is being expended, this isn't an indication that things are on the wrong track. And it may be that if it seems really easy, then something is actually wrong.
I've been teaching computer science to laypeople for decades, all the while saying it's easy. I feel confident in saying that, because I feel confident that I can make it easy. Explaining complicated topics in simple terms is one of my favorite things.
For myself, anytime I have to go to someone at work and have them explain a system that makes no sense to me, if they start with "oh it's simple, here..." I'm fairly sure my reaction is "Good! Please show me the simplicity!"
Regardless of the subject, If I am blown away by something labelled as "easy", it is most likely one of these two:
1) I thought I got it but I didn't 2) I don't have enough background to understand it
"This is easy" is the nice, red sign that is basically telling me "don't go further until you understood this" - and I'm quite happy to stumble upon it. Yeah, it usually means more research and thinking, but it is the only way for you to know that you actually mastered the topic, when it will eventually look, well, kinda easy indeed.
Simple and Complex are objective terms.
Rich Hickey explains it very well in the presentation "Simple Made Easy", that I have some notes on here.
http://daemon.co.za/2014/03/simple-and-easy-vocabulary-to-de...
On the other, every developer, especially ones who are just starting off, needs to develop a healthy habit of self-reliance, being able to hunt down documentation and just RTFM in general.
Actually, her examples are pretty much all related to system administration (PATH and SSH). This backs up what I've said several times before: one must learn system administration before learning to code. Precisely because you don't want to be studying how to write in $LANG, only to realize you don't know how to export your PATH, or what that even is. You need to know your environment before knowing how to code.
Finally, her statement:
especially under-represented minorities
Right, because underrepresented minorities are all inherently deficient in autodidactic skills. Quite the progressive sentiment, indeed.
