22
$\begingroup$

How do you handle it when you make a mistake while teaching? I used to get confused, stammer, blush, etc. But now I just pause and notice that something is incorrect, then correct it if I can figure it out, or say that I will get back to it.

In one of my questions on this site, I said that I taught something wrongly and a student raised a question about it. I stopped and said I would sort it out, but didn't try then to correct it because I wasn't sure why I had made the mistake. The students have a very limited capacity to handle ambiguous or conflicting info while they are learning new things, so I usually try to say only what is essential at the moment. Dijkstra wrote about "the limited size of our skulls" and I mention that frequently.

My skull is definitely limited, and I forget more than I know at any given moment. So every year I need to refresh my memory of details. That is why if something doesn't work or I can't recall something then I demonstrate how to find it again or figure it out. Every year the software changes, the textbook is different, I am using different teaching notes or web sites, and on and on, so I am never completely on top of what is about to be shown in class. I used to reprimand myself, try to prepare better, make more notes, try out all the examples first and so on, but really, the workplace (to which they are going) is not a rehearsal, so I am "modeling what I am teaching". Maybe I come off as a 'cowboy' sometimes, but I enjoy teaching a lot more than I used to!

"I am a man foolish in heart, dull and confused.
Other men are full of light; I alone seem to be in darkness.
Other men are alert; I alone am listless.
I am unsettled as the ocean, drifting as though I had no stopping-place.
All men have their usefulness; I alone am stupid and clownish."
-- The Tao Te Ching of Lao Tzu

What I really enjoy is figuring out why I made the mistake and saying that, not to pass blame or even blame myself, but because understanding is what matters. How do you, by example, teach your students to "learn from others mistakes, because you haven't got time to make them all yourself"?

Improve this question
$\endgroup$
5
  • 8
    $\begingroup$ The question in the first paragraph and the last one seem entirely different, and the text in between is interesting but doesn't clarify what you're asking. $\endgroup$
    – Wildcard
    Jul 28, 2017 at 3:07
  • 7
    $\begingroup$ "Oops, I see a mistake here, in what I wrote. Raise your hand if you can spot what I did wrong." $\endgroup$
    – hotpaw2
    Jul 28, 2017 at 5:33
  • 9
    $\begingroup$ This reminds me of the time a lecturer spent the best part of an hour trying to explain the concept of parity bits. He'd clearly forgotten but he was obviously trying to wing it. He spent the entire time contradicting himself and getting things wrong. My fellow students would correct him and he still couldn't grasp it. Still one of the funniest things I've ever seen, simply because he was too proud to concede he'd forgotten. There's nothing wrong with admitting you're not sure - that lecture would have been so much more productive for everyone if he had. $\endgroup$
    – Michael
    Jul 28, 2017 at 11:37
  • 5
    $\begingroup$ "If debugging is the process of removing bugs, then programming must be the process of putting them in." - E. W. Dijkstra. IMHO programming (as an applied form of CS) is mostly about making mistakes and dealing with their consequences. Learning/Teaching how to spot mistakes sadly is much harder than making them in the first place. $\endgroup$
    – hoffmale
    Jul 28, 2017 at 15:17
  • $\begingroup$ @Wildcard in a way you are correct, but this is a 'best-practice' question, and it is really about behavior. What is it in the behavior of the teacher that shows good ways to handle inevitable errors? The text between the beginning and the end sentences was meant to say: the more I know, the more impossible it is to be perfect, and I often feel like a dolt, but I don't have to act like one. The ego solution to this problem will not work. "The Tao" means The Way, and this is about the way of teaching, by being an example first of all. Being relaxed also works better for everyone. $\endgroup$
    – user737
    Jul 28, 2017 at 19:42

9 Answers 9

Reset to default
10
$\begingroup$

The teaching philosophy I came to as a young teacher (i.e. in my first year) was that I would ground myself in two qualities: passion and humility. (I've since added gratitude as an important third, but that's another topic.) Humility is essential regardless of the discipline.

Teachers are, after all, human. We make mistakes. We forget. We may occasionally forget whether a language uses else if or elsif or elif. The difference for us though is that we also model what it means to be a student. The phrase "life-long learner" is a bit cliche, but it does speak to an important truth: teachers should always model what it means learn. Part of that is showing an innate curiosity and interest with respect to the subject manner. Another aspect is never being okay with resigning oneself to just not knowing something.

If I make a mistake, I acknowledge it, but I do not stop there. If I err when it comes to, say, operator precedence (a recent topic here), I do all the research I can to crystallize that concept in mind and re-teach it so that it is just as clear for my students. I want my students to see that as their teacher, I too am always learning. The classroom should be a safe place to fail, to make mistakes, because of the role said failure can play in the learning process. It's fine to make a mistake; it's not fine to be okay with it.

Also, one thing that can be meaningful in class is to show old code I have written. When I look back at some of the first CS50 solutions I wrote, I absolutely cringe. However, they can be effective teaching tools since students are beginners as well. Explicitly teaching prior "mistakes" emphasizes the benefit of reflecting on past work and the importance of having a "growth mindset."

Note: one caveat would be that some things just aren't okay to mistake. For example, a teacher of Java probably should know the difference between System.out.print() and System.out.println(). There's a level of basic competence that should be mistake-free, but when it comes to more complicated material or language nuances, then there's a little more freedom I think. Where that line is...there might be a bit of grey.

Improve this answer
$\endgroup$
1
  • 1
    $\begingroup$ I chose this as the Accepted Answer because it emphasizes humility, which aligns with what Dijkstra said all those years ago about programming. The "No Problem" attitude described by Gerald M. Weinberg is fatal to openness and success. $\endgroup$
    – user737
    Aug 1, 2017 at 15:15
22
$\begingroup$

If I catch it quickly and can easily explain the error, I use it as an example of failing up. "Ooops, look at me, here's my mistake, here's how I can learn from it."

If students catch it, and I'm not immediately sure who is right, I make a note to do some research and come back to it in the next class.

If I don't realize it until class is over, I make sure to correct it the next day so that I don't reinforce a misconception.

Improve this answer
$\endgroup$
14
$\begingroup$

Mistakes are fine. We are human, we make mistakes.

In fact, one of the worst things you can do in teaching is to never make a mistake and to always say exactly the right thing. This is pretty much guaranteed to reduce the fraction of students who actually learn. A lot of things in CS need to be approached from various, more or less accurate, directions, zeroing in on the truth. Since your students learn differently, and likely differently than you, more of them are likely to pick up the thread somewhere.

In fact, the most valuable thing you can do, at least occasionally is to work live in front of your students, stumbling through the forest to find the spring of knowledge. If you always do the right thing, your students will get the impression that everything is supposed to be easy. But then they ask why am I finding it so hard?. Working live lets them know that they need to go through this search for truth, not just having it served up to them.

If you make mistakes, it will seem more natural and expected when they make mistakes, rather than seeing it as some personal failing.

I think the approach you describe is very good, actually. Ack the problem, put in a placeholder, promise to get back and then do.

If you want to be a famous teacher, find a way to reward stumper questions from your students. You will probably increase attention and participation in your class. Maybe for a real "head-slapper" everyone gets ten bonus points.

That said, it is also bad if you are never correct, but you knew that, of course.

Improve this answer
$\endgroup$
8
  • 1
    $\begingroup$ I came here to say exactly this. One of the most important lessons you can teach a class of novices is that making mistakes is a huge part of the process. It's completely normal to be confused, to get compiler errors, to get runtime errors. It's completely normal to have to do google searches, read the documentation, do some debugging, and even isolate the problem in a little example program. I call this "the Bob Ross approach to learning how to code" - named after Bob Ross's approach of treating mistakes as opportunities. "This accidental brush stroke can become a happy little bird." $\endgroup$
    – Kevin Workman
    Jul 27, 2017 at 18:40
  • 4
    $\begingroup$ Compare that to a student who only ever sees teachers and tutorials getting everything correct the first time, never making a mistake, never having that "wtf..." moment that happens all the time while coding. Then they get home and find themselves making a ton of mistakes. "Is it supposed to be this difficult?" Yes, it is! $\endgroup$
    – Kevin Workman
    Jul 27, 2017 at 18:49
  • 2
    $\begingroup$ @Wildcard I didn't say that, or imply it. Many analogies and metaphors that aid in learning a concept are only "approximately" accurate, but they add to student understanding in different ways as well as to aid students who think in different ways. Saying the "perfect thing, once" is guaranteed to miss all but a fraction of students. $\endgroup$
    – Buffy
    Jul 28, 2017 at 10:02
  • 2
    $\begingroup$ My 2nd-year (undergrad) calculus professor (Dr. K. K. Tan) had an approach to mistakes I still remember fondly: when a student made a mistake, he'd say "ah, you are careless" in a friendly and not-insulting way, and point out the mistake. This sounds rude, but it really didn't come across that way. More like a martial-arts sensei. When he'd make a mistake at the blackboard, he'd say, "oh, I am careless!" after noticing himself or having someone point it out. It was fun, and I think most people got the idea that mistakes happen, and are normal. Laugh it off and move on. $\endgroup$
    – Peter Cordes
    Jul 30, 2017 at 1:54
  • 1
    $\begingroup$ That isn't really the kind of "mistake" the OP is talking about, though. Dr. Tan had been teaching math for a long time, and undergrad math doesn't change the way undergrad programming/CS does. So it was never an issue of high-level confusion, just minor stuff while re-arranging an equation, which of course makes it a lot easier to joke about being "careless". He'd usually notice when he didn't end up with the result he was expecting. $\endgroup$
    – Peter Cordes
    Jul 30, 2017 at 1:59
8
$\begingroup$

I have been adding: “make lots of mistakes” to my student's lesson objectives. I have been asking “What does it mean when we make a mistake?” [That we are learning. That we are trying hard.]

When programming: “What strategies can we adopt, to help us when it does not work?”.

When a pupil asks what angle should the turtle turn to make a triangle. “What angle for a square? Is it bigger or smaller than that? [smaller] Try it? [Oh that went the wrong way]. Try bigger then. [That is still not correct.] Ok so it is bigger than 90 and smaller than 180. Let us write these two numbers here. What could we guess next? (At the end of this, they have done a binary search. Have learnt how mistakes can be used to get where you want to go. And can reuse this strategy, so are more independent.)

We have a merit system, so I always give a +1 to any pupil that spots a mistake I make.

I also model programming the may I do it, with lots of mistakes. But lots of testing so that the mistakes are caught early. I don't always present code that is done. There is a creative myth that people create things in one big bang. Where in reality we do lots of tiny steps, and correct at each step. Model this to your students. And explicitly tell them about it. Get a volunteer (preferable one that thinks them do not make mistakes), put a blind fold on them, and get them to walk down a corridor, with out touching the sides. To touch the sides is a mistake. Then discuss why they can do this when their eyes are open. Is it because they 100% avoid deviating, or do they correct errors?

Improve this answer
$\endgroup$
3
  • $\begingroup$ These are good examples / analogies. Also, since we start knowing nothing, the prognosis is always to get better. "The largest room in the world is the room for improvement." $\endgroup$
    – user737
    Jul 27, 2017 at 19:14
  • 2
    $\begingroup$ Not to brag, but I don't need to add "make lots of mistakes" to my lesson objectives. I do it without even thinking about it. ;-) $\endgroup$
    – Ellen Spertus
    Jul 27, 2017 at 20:32
  • 1
    $\begingroup$ @EllenSpertus It is the student's objectives. I share them with the class at the beginning. For my self, I just make an effort not to cover them up. $\endgroup$
    – ctrl-alt-delor
    Jul 27, 2017 at 21:08
6
$\begingroup$

Many reasons to even intentionally make mistakes in your lessons, but one is especially important in computer science:

Programming is a problem solving skill.

If you don't demonstrate the problem solving skills to your students, they aren't getting part of their education. And the best way you can demonstrate problem solving skills is when you are live, on the spot, trying to solve a problem in front of them.

Of course, unplanned mistakes work better, but I find my planned errors often branch out in unplanned directions.

When you think about it, this applies in all branches of engineering.

In fact, since education is not just the memorization of facts, but the obtaining skills to use facts, it applies in every branch of education. Nothing kills a course more completely than perfect planning and perfect execution. (And, considering the problems of context, lessons really can't ever be perfect.)

So making mistakes in front of the class and showing the students different ways of dealing with them is an essential part of presenting any coursework.

But with computer science it is explicitly so.

Keep up the good work.

Improve this answer
$\endgroup$
1
  • $\begingroup$ Ah, the ramifications of unplanned branches of planned errors! Perfect execution kills most everything. No worries of that for me. $\endgroup$
    – user737
    Jul 28, 2017 at 12:21
4
$\begingroup$

In addition to what has already been said, I would point out that my mistakes are an essential part of creating a community of learners. If students point out an issue that I legitimately didn't know about (i.e. not a simple flub), I will get pretty visibly excited. I always thank the student who points the problem out, and address it immediately if I can. If I can't, then I have a few go-to options:

  1. Promise to research the issue, and get back to the students at the next class.
  2. Ask the student who discovered the issue to research it, and report back with their findings.
  3. (If the issue is simultaneously complex and pretty far from the goals of the unit, i.e. a time-sink) acknowledge the mistake, and thank the student, but proceed with something like, "I don't want to go too far afield here. I really want to make sure that you folks come out of this lesson understanding __________, because that's what your test will be on."
Improve this answer
$\endgroup$
1
  • $\begingroup$ Time-sinks are bad, but I am especially careful not to over-explain in such a way that people become confused again. My mistake in the Precedence question came from over-explaining or re-explaining something they already knew. $\endgroup$
    – user737
    Jul 27, 2017 at 19:22
4
$\begingroup$

I'm a big fan of live-coding for many of the reasons people stated above. For me, the biggest reasons are for students to see my process, to see me make typos and not get frustrated, to see me make mistakes (notice - I differentiate between typos and mistakes), how I troubleshoot those mistakes, and to see my elation when something I wrote works as intended.

Here is a paper and a talk about the topic of live-coding you may find interesting.

  1. The effectiveness of live-coding to teach introductory programming - Marc Rubin
  2. CS Education Zoo Episode #6 - Mark Guzdial
Improve this answer
$\endgroup$
1
  • 1
    $\begingroup$ Could you give some details about these links? We love great resources, but link-only answers aren't considered to be good SE form. It doesn't take a lot of writing, but what are the big takeaways? $\endgroup$
    – Ben I. ♦
    Jul 27, 2017 at 22:27
2
$\begingroup$

Give some level of bonus points for any mistake they point out - in your teaching, in your problem statements (even grammar mistakes), in your code, anything. They don't need to be significant, just enough to encourage it.

After a little bit, not only will your written/handed out material be better for it, but you'll have a group of students ready and willing to work with you. Another option is to give bonus points to a student who can explain a topic more succinctly or clearly than you (first they'd have to write it out and hand it in, as to not waste class time). This will also help you see what explanations stick.

Plus, you can just wave off mistakes as a way to 'keep your students on their toes' ;)

If no student points out a mistake, prompt them ("I've made a mistake here. Can anyone see what it is?") and then explain it after a second or two. If you realize the day after, address it ASAP in class.

Improve this answer
$\endgroup$
1
$\begingroup$

One of the dangers of "playing without a net" and of responding to student input in real time is that of having something not work. This is a teaching opportunity. We ask: What went wrong? Can we use our suite of tools (browser dev tools, documentation, debugging technique) to deal with the brokenness?

You want your students to see how you confront and overcome problems. This is a behavior that professional programmers engage in every day.

Improve this answer
$\endgroup$
1
  • 1
    $\begingroup$ Right. Like Bret Victor said in the video The Future of Programming: "The most dangerous thought that you can have as a creative person, is to think that you know what you're doing." (Because it shuts off learning, growth, openness, discovery, inquiry...) $\endgroup$
    – user737
    Aug 1, 2017 at 15:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.