Why You Shouldn't Say It's Easy When Teaching

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

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.

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.

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.

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.

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