Is it better to lie to students or to be pedantic when teaching Intro CS?

Question

When teaching Intro CS in Java, I sometimes tell students things that are not entirely true, such as that, unlike abstract classes, interfaces cannot contain any code. (For those of you unfamiliar with Java, that was true until functional interfaces were added with Java 1.8 in 2014.)

I realize I could put an asterisk on the slide, or visibly cross my fingers, and let students know I'm not telling the full story, but, when I witness other instructors allude to irrelevant advanced material, I view them as pedantic and fear that students find the additional information distracting or confusing.

I don't mean to open a debate on the importance of functional interfaces in Java -- they're just an example. What I'd like to know is if it's considered better to gloss over details in an introductory class or to always speak the whole truth.

Answer 1

Lying is good. But advertise it when you lie. Make sure students make a note of it that you are lying.

Pedantic is bad. If you try to explain everything you will wind up explaining nothing. Let me take a simpler example. In java we have a special incantation

public static void main(String [] args)

We put it in every program. It distinguishes a program. But if you start your java course explaining every part of it you will (a) confuse the juices out of them and (b) never get to the point of writing a useful program. For the beginner, it is just an incantation like

Riddikulus; // used in defence against a Boggart.

The Java code is just a "charm" for the beginner. All you need to say is that it is a "hook" for the OS to find its way into your program. Explain it later after you've taken up some of its elements for other purposes.

Beginners need a simple but coherent view of their language and system. When you simplify, work hard to keep it consistent. But it doesn't need to be complete and certainly not exhaustive.

When you are giving an "overly" simplified view, say that explicitly. Have the students mark their notes with an asterisk (or the above charm) so that they know it isn't complete. If you are explicitly asked for "the rest of the story" you have to decide whether it will help to include it (after the commercial break, of course) or to defer it or to enlighten the students out of the class context (email, say), or give a reference for those who "will not be denied."

I used to start some discussions with "I'm about to lie to you, but it will be helpful if you accept my lie for a bit". Of course I had to remember to come back an fill in the blanks later, but it might not be for a while. Complex, inter-dependent topics are like that.

tl;dr: Lie, but honestly and truthfully.

And, perhaps the most important caveat, don't lie in such a way that the student later needs to unlearn something. Lying is giving partial truths, or temporary world views, not sending students into mental blind alleys and backwaters. Withholding some facts may be necessary and valuable as is presenting an incomplete metaphor. UnLearning should never be part of learning.

I'll also note that infants learn to speak a native language without everything being explained to them before they begin. The deeper understanding comes to them only gradually and over time. We are actually conditioned by evolution to work this way.

---

Added in June 2022. Today's Dinosaur Comics gives a good illustration of this. Note that Ryan North, the creator of Dinosaur Comics has a masters in CS.

Answer 2

I would start sentences with "Generally speaking..." and I would appreciate if my professors did the same. It hints that there is more to know but doesn't waste time explaining anything further. If your students are curious enough they can raise their hand to inquire. If it takes too much time to explain during class and someone wants to know, you can offer more of your time during your office hours.

Nobody likes being lied to.

The phrase "generally speaking", does not imply that you are lying, it just points out that it is the most common case of something. You could also begin sentences with "Typically..."

In that particular example, you don't have to say "cannot", you could say they "typically don't".

"Generally speaking, interfaces do not contain any code." It shouldn't be more complicated than that.

Answer 3

As a current CS student, my lecturer use to solve this by simply using For now.

To come back to your interface example:

For now, interfaces cannot contain any code, unlike abstract classes.

This gives a clear message, there is more to the topic, but it isn't relevant at the moment. When students ask you can always elaborate a little bit, but for the most questions I think this will be sufficient.

Answer 4

I am currently a student in a computer science bootcamp learning js, C# and asp.net mvc5.

For what its worth, I appreciate the honesty when my instructor uses crossed fingers.(He will pause to cross his right and middle finger and prominently display them in front of him before/while continuing with a "fuzzy truth") I will treat knowledge given to me in this manner as practical use advice and not grounded principle.

I feel that telling hidden un-truths for the sake of a smoother delivery sets a bad precedent and has potential to act as a crutch.

And isn't there always the chance a student "catches" the lie and becomes very confused?

Answer 5

unlike abstract classes, interfaces generally do not contain any code

This is not a lie. In a large lecture hall, if they ask for "when do they contain code", say "that will be covered in another class" to avoid going off on a (possibly confusing) tangent.

This is neither lying, but it is glossing over details. There are situations where lying is a good plan, but they are few and far between (for example, when you teach Newtonian physics, always qualifying every statement with "at velocities far below the speed of light" would get tedious quickly).

Telling a lie should be avoided for a few reasons. First, your students may believe your lie and get confused later. Second, they may catch you in a lie, and lose confidence in everything else you are saying or get confused because of the lie.

Finally, not-lies but glossing over (with words like "generally") leave places for students who are extra eager to look into it themselves. If you lied they wouldn't know where to start looking, but by implicitly leaving a sign saying "there are more details here" you can recruit some student self-motivation to do your work (educating them) for you.

Answer 6

I would suggest saying "for the purposes of this class" or something along those lines to make it clear that while it may not be true, they can take it as truth, and that they don't need to learn the obscure case where it isn't as a hope for an surprise question or the like, similarly to how when teaching elementary physics you would typically ignore wind resistance and relativistic effects

Answer 7

I must say, I largely agree with the posters so far. The principle of lying with your fingers crossed is a good one. However, I have two caveats, and I believe that they are important.

First, I have a small bone to pick with something /u/SlyFiye said:

For what its worth, I appreciate the honesty when my instructor uses crossed fingers .... I will treat knowledge given to me in this manner as practical use advice and not grounded principle.

^{(emphasis mine)}

It seems to me that this is exactly backwards. The reason to give an incomplete picture is to allow students to absorb important grounding principled before adding wrinkles and complexities. This is what motivates the entire enterprise.

Second, the principle is one for usually, and not for always.

I've repeatedly observed in my own classroom that, if my students are already somewhat lost in a complex topic, even hinting that there might be more complexity beneath the surface causes them to completely lose the topic. It has been consistent enough that I am utterly convinced that this effect is real, and we need to treat it with care.

I have two brain-based theories for why this might be. I have not found any research to support (or detract) from these theories, but they could both well explain the phenomenon:

1. Simple de-motivation. Upon hearing that this very hard thing that they are faced with is partially false, the student simply despairs and gives up. Why do all of the hard work to understand something that isn't even true?

2. Brain-scrambles. What happens in a student's brain when they hear that there is more to the story may not exactly be the blank "okay, there will be more later" that we might hope for. Instead, what might happen is a series of rapid mental transitions, in which the student mentally loops through the components of what they have learned and tries to guess at which part might not be true, exactly, and what that truth might be. This involves a sort of miniature cognitive scramble at each pass. "Okay, so if this part isn't true, then maybe things don't quite connect the way I've just been shown."

   The reason that this matters is that, if the connections in your student's brain are already quite tenuous, the process of scrambling can muck everything up.

   When faced with the revelation that the topic has even more to it, confused students still go through that same mental process described above, but what comes out of it is essentially spaghetti. That tiny, inchoate thread that they were constructing about your topic will simply come apart.

Regardless of the reason, if my students are already confused, I have found it better to hold off on even mentioning that the material is really more complex. Give the students a chance to try to get a handle on the ideas you have placed before them before inviting them entertain any further complexity.

You can come back around and fix things later. Or not. I actually take a rather dim view of making sure that every statement is always fully accurate. Sometimes insisting on total accuracy can pull your students deep enough into the weeds that they simply get lost, and never fully notice the giant statue that you were trying to point them to.

I stand by what I said at the beginning; crossing your fingers is usually the best way to go. But sometimes it can be more effective to choose your battles and let sleeping monsters lie.

Answer 8

Tell all the truth but tell it slant —
Success in Circuit lies
Too bright for our infirm Delight
The Truth's superb surprise
As Lightning to the Children eased
With explanation kind
The Truth must dazzle gradually
Or every man be blind —

^{Emily Dickinson, poem number 1129 in Complete Poems}

Dijkstra often mentions the limited size of our skulls, so maybe you could make a remark at the start of your teaching that you cannot possibly convey all of the subtleties of every topic and you are going to have to abbreviate to begin teaching somewhere. This is the opposite of my favorite principle: The Sweater Effect: just start pulling anywhere, and sooner or later the entire thing will come unraveled.

I guess we could call your issue, The Enlightenment Effect. Sometimes it is referred to as "Lies to Children."

Answer 9

unlike abstract classes, interfaces cannot contain any code.

I don't like the word "lie".

Let's change subjects so you can see what I mean:

It isn't lying to teach children that the atom is the smallest unit, that atoms form molecules and molecules form everything else.

Later, in chemistry class, you can tell them that an atom has a nucleus which is surrounded by electron clouds and that the nucleus is made of protons and neutrons.

Later, in physics class, you can tell them about quarks, gluons, spin, color, etc.

Did you lie in the first statement because you said, smallest unit?
Even though you knew full well that the atom is in fact the smallest constituent unit of matter that has the properties of a chemical element?

I'd say No.
You are not leaving out stuff to mislead, you are simplifying to teach the subject clearly.

However, when a politician does that, I call it a lie :–)

Answer 10

I don't see why you restrict your choice to either lie or be pedantic, both of which are negatives.

It is pretty clear that almost all topics in CS are more complex than they seem at first; there always is a small visible surface, and a huge ice berg below. In fact, having a software developer who thinks he knows everything about a topic and has no open mind for further stuff is very hurtful in the real world, it can really wreak havoc in software projects.

Your solution could be as simple as "Today we are looking at the aspect of Java interfaces that makes it so they guarantee that classes implementing them define certain methods." (or whatever better formulation you can come up with). The important point is the "Today we are looking at the aspect of ...", the rest is just part of your irrelevant example.

Any student should pretty easily understand that if we look at one part of a puzzle, there are other parts.

Get them into the habit that you never give them the full picture (because, as the Hitchhiker tells us, that would be too humbling for our sanity...). If you, depending on the age of your audience, have to hammer it in, then preface your lecture by a picture of an iceberg (maybe together with the Titanic for some added humour...).

Also, you could find an exhaustive list of features of your interfaces, and give them a kind of "breadcrumb" somewhere in your presentation (if you are not writing by hand on a board), highlighting the topic of the current session. Even if you lose no word about the other topics, they will be aware that there are other topics. Like "Interfaces: multiple inheritance; abstract method definitions; default code...", if todays session is just about the fact that classes implementing the interfaces have to implement the methods, and that the caller can use the interface as a type if he does not need more information about the concrete classes.

Answer 11

Just tell them you are trying to explain an important aspect of things, and you have to simplify a bit.

I'm preparing a lecture about iterators in Java, so I use that example. I tell student that iterable objects must have an iterator method in order to implement the Iterable generic interface

interface Iterable<T> {
    Iterator<T> iterator();
    ...
}

and iterators have next and hasNext

interface Iterator<T> {
   boolean hasNext();
   T       next();
   ...
}

That's all I want to explain. I don't oversimplify, but I don't want to say a word about forEach and remove and blood-thirsty spliterators from Jurassic Park at this point. If some students read the documentation and ask questions, I point them to the ellipsis.

But I make clear there are other things, not to be discussed now.

About interfaces, what about telling they were mostly intended to list methods to be implemented by concrete classes? It doesn't exclude the presence of other things in the interface.

---

At some point, but much later, it can be interesting to explain why default methods were introduced in Java, whereas it seems a contradiction with their initial intent.

To put it simply, lots of existing code uses the same standard interfaces as, for example, the collections. New features were added to collections interface, like forEach. But it was not reasonable to ask customers provide implementations of forEach for all their existing classes. So language designers went by that tradeoff.

Answer 12

I had a similar issue in a class about video coding. There is a set of design decisions, that are quite abstract, and then there are actual codecs. The codecs went on relaxing many constraints of initial theoretical design decisions, because then it works better and yields better compression rate. But it does not make it easier to understand for a beginner.

So, what I caught myself constantly saying was more or less this. I am trying to highlight the key phases.

The generic idea is that you have an I frame at the beginning of the GOP. When you think about a P frame now, just for understanding, think that it can reference only a preceding I or P frame. In practice it is possible to reference a frame after the P frame. Actually, there are I-, P-, and B-blocks and frames are built out of them. And, like, with H.264 the criteria of a GOP are also relaxed. This will be discussed in a detail later, when we get there. But for a theoretical overview, that is also relevant for an exam, use the generic, theoretical view above. If a question does not specify a concrete codec, you need to use this generic idea of a video codec without exceptions used in concrete implementations.

And then I also had an exam question of "which frame would reference which" in this "generic ideal video codec".

Answer 13

Are you teaching computer science using Java as an exemplar, or are you teaching Java programming skills?

Because when you use a word like "interface", in the one case you will want to discuss the general CS meaning of the concept independent of programming language (let along programming language versions), while in the latter case, students will need at some stage to be aware of the details.

Discussion of the gory detail of Java versions here could detract from your ability to convey the importance of interface definitions in software engineering by isolating components from each other's implementation detail: which I would think is the important thing to be teaching.

Answer 14

The problem with simplifying-by-lie is in the consequences it can have when your student faces practical, real world code development or maintenance situations as a beginner:

• When trying to find out the cause of a bug, they might discount the possibility of something that you said is impossible, and thus not check for it and thus not find the bug.

• They might make a fool out of themselves by trying to defend what you told them as gospel against seasoned professionals, possibly with extreme accidental arrogance.

So, it is always best to advertise the fact that you are simplifying.

Answer 15

For starters, there is no such thing as an "Intro CS in Java" course, and the word Interface would never come up in such a course anyway.

"Computer Science" means using computers to solve problems. Nevermind the fact that Java would never have made it out of the gate were it not for being named after a drink we are all addicted to. Problem solving has nothing to do with Java, and a weighty language like Java has no place in an Intro class, unless your school is pandering to corporations, or Mao Tse Deng has designed your CS program to go from Freshman to Ph.D in three years.

Intro to CS students should be learning about assignment statements, conditional statements, writing small swap functions, learning about basic loops, memory allocation, and then recursion, fractals, string types, and then toward the end, some more interesting and complex functions and a little bigger programs.

Since Java is garbage collected, and its syntax doesn't represent machine code instructions, there is no place for it in an Intro to CS class, or any CS class really. This is a science class, not a syntax class. Use C. If your students are asking about interfaces, then you are doing something very seriously wrong in your intro class.

Now, regarding lying, I don't know if you are a foreign teacher or not, but it's an extremely strange question in the West. A teacher should NEVER LIE to a student to any degree and for ANY reason. A student in a classroom is essentially in a hypnotic state of a priori belief in your authority as the true instruction. Your students will take your lie, or stretching of the truth, at face value, and will cherish that belief FOREVER. Most humans hold their beliefs not because they make sense, but because that was the first believe introduced to them on a subject. Very few people every reach logical escape velocity.

By lying, you will destroy the credibility of your colleagues and any future teacher (who does NOT lie) who will teach that student correctly, and thus will contribute in a very dangerous way to the breakdown of the pillars of civil society itself, which rest on the first principal of integrity.

Answer 16

In my textbook, I say, "In its most basic form, an interface is an offer to sign a contract." It consists of a collection of method headers; classes sign the contract by implementing the interface. I then proceed from there to discuss interfaces, polymorphism, and the Visibility and Delegation priciples.

This allows me to defer the development of static methods and data and default methods in interfaces.