
Why You Shouldn't Say It's Easy When Teaching - quasiben
http://karissamck.com/blog/2014/04/26/why-you-shouldnt-say-its-easy-when-teaching/
======
tikhonj
It's funny, because I have completely the opposite view: stop telling people
stuff is difficult! If people think what they're about to learn is supposed to
be "hard", they're going to give up faster and be intellectually lazy. "Oh, I
just can't figure it out because it's _hard_."

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.)

~~~
quadrangle
That's not "opposite" that's the other side of the same coin. Don't say things
are hard or easy, just teach them.

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…

~~~
judk
What's the opposite of "heads"?

------
mikekij
The flip side of this is that it may be helpful to tell students "This can be
easy for you too, with a little work!"

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.

~~~
greghendershott
Exactly. If I ever say this, what I _mean_ to be saying is something more
positive. More like: "Good news! This is something that's actually simple to
fix/do. Even if you find it difficult at first (I sure did), someday you'll
look back on this and think it's really easy."

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.

~~~
sirmarksalot
"Of course it's hard, you haven't done it before!"

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.

------
tokenadult
I like teaching subjects that are intentionally advanced for the age of the
learners presented with problems that require a lot of mental stretching and
effort for the learners. I have a FAQ document about how people feel when they
take on tough learning challenges that explains what to do when the lesson is
anything but easy.[1]

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.

[1]
[http://www.epsiloncamp.org/CourageandStupidity.php](http://www.epsiloncamp.org/CourageandStupidity.php)

~~~
charlieflowers
I'd love to pick your brain on something. My 5th grade daughter has math
anxiety, picked up believe it or not in 2nd grade. As far as I can tell, her
actual ability is average or slightly above. But her self-esteem is on the
line for every problem, so she won't relax long enough to actually think ...
she grasps for the fastest "formula" from rote memory, and if that isn't
right, she is distressed.

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.

~~~
tokenadult
That's a good question. Did you see the other links from the bottom of the
link I posted above? I usually suggest to parents that they read those in
numerical order,

1)
[http://www.epsiloncamp.org/ProblemsversusExercises.php](http://www.epsiloncamp.org/ProblemsversusExercises.php)

2)
[http://www.epsiloncamp.org/RepetitionPractice.php](http://www.epsiloncamp.org/RepetitionPractice.php)

and

3)
[http://www.epsiloncamp.org/LearningMathematics.php](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.

------
robinh
Good god, if only mathematics professors would learn this. If I hear the word
'trivial' one more time I swear I'm going to scream.

~~~
mden
I know where you are coming from... but I have started interpreting the word
"trivial" (and I don't mean the math meaning of it, e.g. "empty set is a
trivial solution") to be a canary of sorts. Once you encounter it and the
statement that is supposed to be "trivial" isn't, that means you should
backtrack and figure out what insight you are missing to make that statement
trivial.

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.

~~~
chmullig
As soon as I realized this, it actually became quite helpful.

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.

------
jw2013
I think the author fails to realize whether saying 'easy' is okay or not
really depends on what background your audiences have. For example, in the
math class I find the professor saying 'it is trivial to get B from A' is
quite okay if the proof of that deduction is something the students have
learnt in the lower-level classes. I don't know another way to skip the easy
proof without saying it is easy.

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?

~~~
npizzolato
One of my most frustrating experiences in school was a math class with a
textbook which would stop explaining examples halfway through because "the
rest of this problem is trivial" or so it could be "an exercise for the
reader".

~~~
nickflees
Agreed. I'm also extremely skeptical when classmates, instructors, or co-
workers use similar tactics. I have found that, when pressed, they will often
reveal that the rest is not nearly as trivial as advertised.

------
sjtrny
This is also a problem in academia too. Very often I read papers that say that
proofs are trivial, that we can easily get from one equation to another
through algebra or that solving an equation is easy. It's something I try to
avoid, instead I use "straight forward", which I think implies to the reader
that this road has been travelled before but that it's still ok to ask
questions because they haven't travelled it themselves.

~~~
TheEzEzz
"Straightforward" is a great term.

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.

------
facepalm
Or maybe students could learn that they can actually figure some things out
for themselves. Google is also there to help.

------
danso
__“Just ssh into the box”… __

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_.

~~~
Jtsummers
Imagine this scenario, you're teaching CS 1 at your college. Your system for
submitting assignments is to have students use a git repo and push it to a
remote repository on your servers. You could tell them, "Just clone this
remote repository when you start working on the assignment." But that's
unhelpful, and the word "just" implies that they should already know how to do
it. If that's your statement on day 1, you're hurting many of your students.
Instead it should be something like, "We use Git for assignment submissions,
it is a version control system. Here's where you can learn more about it.
Assignment 1 is posted on the website and will walk you through using git to
submit the assignment. The full procedure is also available here along with
some cheat sheets. Here's our CS 1 material of the day." The assumption that
students or new employees know the idiosyncratic processes and tools of your
school, class or organization does what assumptions are prone to do, someone
is going to come out looking like an ass. It may be the new person when they
get frustrated, or the experienced person when it turns out "easy" is really
20 different steps on 3 or 4 different systems.

------
Jtsummers
This is a pet peeve of mine. I have a couple colleagues that use this too
often. It's dismissive and rude, it presents to the questioner the impression
that you perceive them as ignorant and stupid.

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."

------
cossatot
In my experience both as a learner and as a teacher in a variety of settings
from teaching upper-undergrad level science courses to whitewater kayaking,
the 'easy' vs 'hard' distinction is quite important on two fronts:

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.

------
andywood
This seems to me like a pretty random communication pattern to jump on, and
not at all likely to be universally 'right'. Maybe it's a personal issue for
the author, and others.

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!"

------
manlio
Strongly disagree. When it is honest, I find calling something "easy" is a
great way to set the bar for the reader.

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.

------
AdrianRossouw
Easy and Hard are relative terms.

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...](http://daemon.co.za/2014/03/simple-and-easy-vocabulary-to-describe-
software-complexity)

------
webo
I think a part of the reason many developers/engineers use words 'easy' or
'just' is because they kind of like to feel more superior than others. This is
not necessarily true within the workspace, but it is very true at school or at
developer meet-ups.

------
lazylizard
um. quite often true for me.. before figuring it out : hard. after figuring it
out : easy. sometimes i describe things as complex or non-trivial..hmmm...

------
vezzy-fnord
On one hand, she's right about how people should be more mindful of others
with whom they have a discrepancy in skill level.

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.

------
a3voices
Where I work, everyone speaks in countless acronyms that only make sense
within the company. It was very difficult for me as a new hire.

------
MCarusi
What's easy for Mark Zuckerberg isn't easy for a complete novice to whom
programming doesn't come naturally.

