instructor-training
instructor-training copied to clipboard
carpentries
Lesson Contribution -- How to recover from mistakes and screw ups
I'm a member of The Carpentries staff and I'm submitting this issue on behalf of another member of the community. In most cases, I won't be able to follow up or provide more details other than what I'm providing below.
I think it would be beneficial to add a section to Carpentries curriculum on "How to recover from mistakes and screw ups" that happen during teaching and with live presentation. Recommended time slot: on Day 3, after Managing a Diverse Classroom or on Day4, before or after "Putting it Together"
The recommendation:
Slow down, take a deep breath.
Call a break for 5-10 minutes
Reconvene and admit the error if it's unrecoverable or show the fix. Promise the audience to revisit on the next day or email with follow-up if it's the last meeting.
Add any other recommendations for best practices and good examples.
Making mistakes and recovering from them is one of the most important parts of a lesson. Willingness to make mistakes is the largest differentiation between the Carpenties and other teaching.
Some ideas:
- Mistakes show that you are human. This is important to break down the mental barrier that exists between teachers and learners. Learners have been trained to think of teachers as experts since they were children.
- Explain the process. Don't just fire off commands in the terminal. Share your thinking with the audience.
- Mistakes are an opportunity to laugh.
- Mistakes are an opportunity to solicit help and engage the audience
This is something that @sarasrking and I touched on (and got positive feedback for) in our most recent instructor training -- and it was a theme I riffed on using inspiration from @dvanic story of a coughing fit (from teaching with her last year). Sara and I also modeled it a number of times during training.
This needs to go with "never teach alone" in Managing a diverse classroom where "throwing to your co-instructor" is a critical first response and something that must be discussed during workshop prep and sharing that meal. This is also a necessary reason for that shared social experience, to build trust and expectations around communications and interruptions. Asking for help from co-instructors and helpers, talking through the error, and demonstrating patterns of error recovery turn a genuine error into "the errors are the pedagogy."
Apart from “never teach alone”, a major theme that both Denubis and @saraking stressed during that training was that we will make mistakes and it really resonated with me that when (not if) mistakes happen you should own it, explain it and move on. Owning the mistake helps you stay calm and turn it into a teachable moment. Adding into the introduction an explanation of your background at the beginning of the class is also very important as it sets the stage that while you are teaching this to others, your background or expertise/degree may be in something else entirely. This does not mean that you do not know the material but we are human, we cough, we mistype but we are not alone…”never teach alone” but if we do… timClicks is right: mistakes are important. We are not saving lives, we have to remember this and look at it as improving lives and modelling to others how to handle trips, coughs and mistakes (not errors!).
Some more tips for a graceful recovery:
- treat an error message / mistake as an exciting challenge, and express that clearly to the learners
- be willing to spend up to 2 or 3 minutes debugging something. if it takes longer than that, consider moving on and figuring it out later
- model confidence: don't make self-deprecating jokes to try to protect yourself, or apologize profusely. even the most advanced coders make mistakes!
Inviting workshop participants to solve coding errors is a way to maintain the engagement of (and to learn from) the most experienced and knowledgable attendees (apart from the instructors and helpers).
During the Instructor's Training workshop that I recently attended, I was struck by the understandable emphasis on "meeting learners where they are", which catalyzed a worthwhile discussion for how to help learners who are having trouble keeping up with a workshop's curriculum. The instructors and workshop attendees, however, also noted that slowing down too much to accommodate the least well-prepared workshop participant can leave well-prepared attendees bored or annoyed. There's a mix of opinions on how best do address the high variance in the level of preparation of workshop attendees, but my perception during the workshop was that we (the participants) were given the message that "it's much, much better for well-prepared participants to feel irritated and bored by a slow pace than it is for the unprepared learner to be frustrated".
I understand the philosophy and rationale behind this view, and I'm sympathetic to it, but I also don't want to be disrespectful of the time of participants who are well prepared (either because of their previous training or experience, or because they took the time to review the curriculum and lessons before the event, or both) and who may have gone to a lot of effort to fit a DC workshop into their schedules. So, I'm thinking that one way to engage (and to acknowledge the expertise of) those participants who are at the "experienced" end of the spectrum would be to set the stage for soliciting their trouble-shooting skills when errors are made (by instructors or by other participants).
In other words, stating -- as part of any workshop's Introduction -- that this kind of contribution would be valued could help to prevent boredom and irritation by the more experienced participants, while also improving the trouble-shooting process. In addition, by encouraging this kind of participation, it would help instructors to identify those participants who might find it appealing and easy to become certified DC instructors themselves. Of course, some participants will pipe up when they see an error being made (and know how to fix it), but others might benefit from some encouragement.
I got the feeling that there was great concern among the instructors that, if workshop participants were encouraged to step up and fix errors during a workshop, they would somehow be likely to violate the Code of Conduct and leave everyone feeling terrible. Or, perhaps the instructors were worried that this practice would take too much time. In any case, I think it would be worth pointing out at the beginning of the workshop that, while the instructors don't want to get off-track with time-consuming coding diversions, if any participant can offer an efficient repair or work-around to an unexpected coding error, this would be warmly invited.
The concept of instructors working in pairs can be used quite nicely in Carpentries to catch mistakes and owning them while teaching. From my previous teaching experience I have found that attending non-presenting instructors can act as catalysts for breaking the ice and "ask on behalf of the students". Not interrupting by pointing out mistakes, or near mistakes, but rephrasing them as questions. "Sorry for interrupting, but should that letter really be in upper case?", rather than "Hey! Change that to lower case!". It allows for the acting instructor to own the mistake without having it emphasized as a mistake. In my experience, if you point out someone doing something wrong, that is what will be remembered.
-
To add to a constructive discussion, to own ones mistakes we can, as instructors, help each other in gentle ways, e.g. by asking questions and for clarifications. If the learners note the instructors are communicating with each other, it will preserve a good learning atmosphere.
-
If the instructors know that a particular segment could be perceived as confusing and/or difficult, do not hesitate to ask on behalf of the students. It will lower the thresholds and get the discussions going! If there is not enough questions, I will ask them myself!
A lot of great comments and suggestions here. I think more emphasis on ~how to approach issues while live coding~ would be welcome to instructor training! It is absolutely an event that can be nerve-wracking the first time it happens, but I have found is more impactful on the audience then say, making your way through a lesson and everything goes exactly according to script. In my experience with learning R over the past couple years, I feel the moments I gain the most insight are when an error comes about and my instructor/teacher/peer, walk through the thought-process necessary to trace their way to the source of the error. Trouble-shooting is an often overlooked skill in coding!
Would love to see a new lesson in instructor training. Perhaps after the first round of live coding practice, there could be some exercises practicing coming across errors and rolling with it, engaging the audience, talking through the trouble-shooting process you are going through live. Additionally, other instructors-in-training can practice piping up and offering suggestions to help with the trouble-shoot.
This would likely be time-consuming exercise in instructor training, but I believe a welcome addition. Thanks for kicking off this discussion Talisha!
As @Denubis mentioned, we are human, things happen during training, especially during live coding.
- Introducing errors at the beginning of the lesson and troubleshooting with the students is a good way to introduce the concept of errors. An error introduced by the instructor is a good place to demonstrate that mistakes and errors are part of coding. An introduced error is debugged with confidence because the instructor knows what they did to introduce that error.
- It helps to acknowledge a mistake or screw-up, that way students also know that the instructor is aware of the mistake. This can be followed up with correction from the instructor, co-instructors, or an announcement that it will be sorted before the end of the day. That way, the instructor and the students can "move on" from the screw-up.
- Also, pardon yourself. Don't be too hard on yourself when there is a mistake. If you are stressed, you won't be able to fix the mistake. Don't let one mistake ruin a full day's experience.
PR #1412 makes an attempt at this, input from contributors to this discussion is welcome there.