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.)
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
Having taught ~200 adults to program, a teacher should avoid the "difficult/easy" dichotomy entirely, which is closely related to the "stupid/smart" dichotomy. SQL is "easy" if you come from a job where you've used Excel all the time, but hard if you've never had to think that way.
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 think you might in fact be in agreence on the deeper point, 'easy' and 'hard' are relative terms, what is 'easy' for you may be hard for me and vis-versa. I would agree that in teaching it's best to avoid or greatly use both words in lazy everyday speech.
It's my experience that you should tell the students that the topic is challenging. Not difficult. And if it's easy, there's no point in bringing that up either.
I believe the use of both of these terms comes from inexperience, or as you suggested, the desire to intimidate.
People don't understand monads because they don't write code with monads. Instead, they read abstract tutorials about how a monad is like a burrito full of kittens, get scared, and then don't actually reach the stage of learning by doing.
Usually that's a sign that the person learning doesn't have the right "toolbox" yet.. It requires stepping into their shoes and trying to build up smaller pieces which they can grasp, then allowing them to step through them first semi-guided, and then again on their own. After a while, the student can grasp that this is the way to attack a seemingly "impossible" problem - well, all these pieces I've been learning must fit in here somewhere.. what's the simplest bit I know which puts me at least a step in the right direction?
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"..
I think context matters here. Let's take two different use cases as examples:
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.
What I've learned with my kids: it depends on the person.
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!!!!"
everything is easy in context. what you are supposed to be teaching is not "what is easy", but how to put something in context to make it so. this typically means eliminating degrees of freedom--most of what you learn in school makes you smarted by limiting your cognitive overhead. the actual calculations are 1/10th of the cognitive load; that is why experience and not aptitude are valued later on. "hard" for someone with no experience is almost always not "intellectually difficult", its simply befuddlement.
When I read the post, I had the exact same thought you just wrote (experiencing too much of this first hand with my eldest boy atm). Took the words right out of my mouth.
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.
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.
"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.
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.
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.
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,
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.
There's an old joke that goes something like this.
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."
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.
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.
If there's any subject which would benefit from interactive textbooks, it's mathematics.
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.
It would be impossible to spell everything out, though. Then you would have to start every proof by inventing the concept of natural numbers and so on.
While I agree that you can't reasonably implement a complex subject from first principles every time you want to talk about something, I think the core of the complaint was more in frequently calling something trivial when addressing a room full of students with varying ability.
Trivial is, I suspect, best expressed in terms of inferential distance that the student has to cover. Education naturally works on the borders of what people know: too far and showing people something is incomprehensible to them, too close and they're learning nothing they couldn't have found themselves simply by looking at your powerpoint stack.
I suppose, to develop that line of reasoning, it might go something like this:
Given that you're operating on the edge of people's concept space to be teaching them something worthwhile, if you're saying that something's trivial (i.e. that they should find it trivial) a lot, you're either:
A) Wasting people's time, (it's too close to their known concepts)
or
B) Confusing people, (it's too far from their known concepts)
If you're in the goldilocks zone for learning, it shouldn't be trivial. Might it rely on things that are trivial to them? Sure. But I don't see any value in mentioning that they're such, and if you're dealing with varying ability it's worth keeping in mind that some of the things you think are trivial aren't going to be to everyone.
Basically, my question to you, would be: What value is added by calling something trivial to justify the harm to those who don't find it such?
You could after all just not mention that the thing is trivial, perhaps more students would have the courage to ask you about it if they don't understand it that way.
I think you interpret too much into this question. If you do a proof, at some point you have to say something. Either "it's trivial" or "it's obvious" or "it is known" or whatever. Otherwise, how would you stop expanding the steps of the proof?
I also don't think a university course has to hold every students hand. For example if you offer Advanced Calculus or whatever, it is fair to expect students to know that 2+2=4. If some step is too far from a students known concepts, they can either invest extra time trying to catch up (Google is your friend), or they can switch courses.
You could also debate which approach is better for learning maths. In my time, there were comparatively thin books about calculus and comparatively thick books about calculus. The latter spelled everything out. I hated them - too many words really made it hard to focus. I personally much preferred the dense books that left more thinking to the reader.
Maybe for some students the thick books are better, but I don't think a teacher has to please everybody. Students should have the opportunity to switch to another teacher or subject if they can't cope with the current teacher.
> I think you interpret too much into this question. If you do a proof, at some point you have to say something. Either "it's trivial" or "it's obvious" or "it is known" or whatever. Otherwise, how would you stop expanding the steps of the proof?
Just stop when you've got as deep as you care to go. I don't see the necessity to say anything there. If it is trivial, then it's not going to be challenged because everyone will know that they'd lose, and if it's not trivial and it is challenged, then you've identified that at least one of you's going to learn something in the exchange.
> I also don't think a university course has to hold every students hand. For example if you offer Advanced Calculus or whatever, it is fair to expect students to know that 2+2=4. If some step is too far from a students known concepts, they can either invest extra time trying to catch up (Google is your friend), or they can switch courses.
There's failure on both sides if students are being entered for a course that's significantly beyond their ability in that sense.
On the one hand, the student needs to try if they expect to get anything out of it, and persistent focused effort should have equipped them for most of what they can reasonably expect to run up against. On the other hand, the college shouldn't be taking people on who are manifestly unsuited to the subject they're being admitted to.
Perhaps in first year, that's understandable. Testing what people know for admittance, especially given the pitiful standard of secondary education and testing, is a non-trivial task. However, by the time you're getting into second year, if the university has passed them, and they're under-equipped for the second year... well, why the ever loving spaghetti monster did you pass them from first year?
I think we'd probably both agree that both parties in education need to make reasonable effort. If the student isn't willing to try, then there's nothing that can be done. If the college isn't putting its best foot forwards, then the student may as well just be paying for the right to sit the exam for all the value the college is providing.
"Just stop when you've got as deep as you care to go."
Really, I don't think saying "it's trivial" is such a big ordeal for students. In maths at least, they'll quickly learn to get over it. I think in the beginning I was surprised a couple of times. Then I thought about it, and then after a while I realized it is trivial. It is also a pointer for the students so they can see "I should know this".
As for passing students from first term to second term - I am not sure if I care. Why not let students enter any course they wish?
If we're talking about college math courses, then presumably there are prerequisites for any moderately advanced course. So "trivial" would be in the context of students with the appropriate mathematical background to be taking this course.
Its a meta problem. Both math and physics have their own little language which is only vaguely inspired by standard English, and its a popular meme to complain they're just similar enough to cause emotional anguish.
For example a pathological problem doesn't mean you'll get a nasty MRSA infection from working on that problem. At least not directly...
Of course it's subjective. Why is that relevant? Math teachers are teaching a course with certain prerequisites, so in that context "trivial" means something like "it should be easy/obvious for people with the appropriate mathematical background for this class."
Many of the students in the class got through those prerequisites with, say, 70% on the final exam. That means they have a very tenuous grasp on much of the content, and so teaching with at least some overlap with the prerequisite is useful.
The prerequisites may have been taken 6-12 months earlier. Without constant use, a lot of the concepts that were learned in the prerequisites will be lost over that time period. Many classes will indeed start with the first lesson or two as a revision of the prerequisites for this reason. It possibly annoys those who have a firm grasp, but not everybody learns mathematics (or language, or anything else) the same way.
I've never taken a math course that didn't contain some overlap. But you simply can't realistically teach everything from every prerequisite in every class. There may always be some students who snuck through a prerequisite without learning or retaining the info. That's what office hours are for.
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?
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".
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.
That definition of trivial is not the one in regular usage.
> 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.
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.
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.
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.
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."
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.
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!"
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.
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.
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...
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.
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.)