From ca9144b77bf12a19f1c9b3e371d72989e89c962c Mon Sep 17 00:00:00 2001 From: Radovan Bast Date: Wed, 7 Aug 2024 11:08:13 +0200 Subject: [PATCH] updated my text on "teaching philosophies" --- content/teaching-philosophies.md | 106 +++++++++++++++---------------- 1 file changed, 50 insertions(+), 56 deletions(-) diff --git a/content/teaching-philosophies.md b/content/teaching-philosophies.md index c4c7222..f8df8a8 100644 --- a/content/teaching-philosophies.md +++ b/content/teaching-philosophies.md @@ -59,62 +59,56 @@ find the way that is best for each of us. >- [Learner Personas](https://teachtogether.tech/#s:process-personas) {: .challenge} -> ## Radovan Bast -> -> My teaching changed by 180 degrees after taking the Carpentries instructor -> training. Before that I used slides, 45 minute lecture blocks, and separate -> exercise sessions. After the Carpentries instructor training I embraced the -> interaction, exercises, demos, and typos. -> -> My goal for a lesson is to spark curiosity to try things after the lesson, -> both for the novices ("This looks like a useful tool, I want to try using it -> after the workshop.") and the more experienced participants ("Aha - I did not -> know you could do this. I wonder whether I can make it work with X."). I like -> to start lessons with a question because this makes participants look up from -> their browsers. -> -> Keeping both the novices and the experts engaged during a lesson can be -> difficult and offering additional exercises seems to be a good compromise. -> -> For me it is a good sign if there are many questions. I like to encourage -> questions by asking questions to the participants. But I also try not to go -> into a rabbit hole when I get a question where only experts will appreciate -> the answer. -> -> I try to avoid jargon and "war stories" from the professional developers' -> perspective or the business world. Most researchers may not relate to them. -> For examples I always try to use the research context. Avoid "customer", -> "production", also a lot of Agile jargon is hard to relate to. -> -> Less and clear is better than more and unclear. Simple examples are better -> than complicated examples. Almost never I have felt or got the feedback that -> something was too simple. I am repeating in my head to not use the words -> "simply", "just", "easy". If participants take home one or two points from -> a lesson, that's for me success. -> -> I prepare for the lesson by reading the instructor guide and all issues and -> open pull requests. I might not be able to solve issues, but I don't want to -> be surprised by known issues. I learn the material to a point where I know -> precisely what comes next and am never surprised by the next episode or -> slide. This allows me to skip and distill the essence and not read bullet -> point by bullet point. -> -> I try to never deviate from the script and if I do, be very explicit about -> it. -> -> A great exercise I can recommend is to watch a tutorial on a new programming -> language/tool you have never used. It can feel very overwhelming and fast to -> get all these new concepts and tools thrown at self. This can prepare me for -> how a participant might feel. -> -> I find it very helpful if there is somebody else in the room who helps me -> detecting when I go too fast or become too confusing. I like when two -> instructors complement each other during a lesson but when doing that to -> others, I am often worried of interrupting their flow and timing too much. -> -> A mistake I often do is to type too fast and in my mind I force myself -> to slow down. -{: .challenge} +:::{challenge} Radovan Bast +My teaching changed by 180 degrees after taking the Carpentries instructor +training. Before that I used slides, 45 minute lecture blocks, and separate +exercise sessions. After the Carpentries instructor training I embraced the +interaction, exercises, demos, and typos. + +My goal for a lesson is to spark curiosity to try things after the lesson, both +for the novices ("This looks like a useful tool, I want to try using it after +the workshop.") and the more experienced participants ("Aha - I did not know +you could do this. I wonder whether I can make it work with X."). I like to +start lessons with a question because this makes participants look up from +their browsers. + +Keeping both the novices and the experts engaged during a lesson can be +difficult and offering additional exercises seems to be a good compromise. + +For me it is a good sign if there are many questions. I like to encourage +questions by asking questions to the participants. But I also try not to go +into a rabbit hole when I get a question where only experts will appreciate the +answer. + +I try to avoid jargon and "war stories" from the professional developers' +perspective or the business world. Most researchers may not relate to them. +For examples I always try to use the research context. Avoid "customer", +"production", also a lot of Agile jargon is hard to relate to. + +Less and clear is better than more and unclear. Simple examples are better than +complicated examples. Almost never I have felt or got the feedback that +something was too simple. I am repeating in my head to not use the words +"simply", "just", "easy". If participants take home one or two points from a +lesson, that's for me success. + +I prepare for the lesson by reading the instructor guide and all issues and +open pull requests. I might not be able to solve issues, but I don't want to be +surprised by known issues. I learn the material to a point where I know +precisely what comes next and am never surprised by the next episode or slide. +This allows me to skip and distill the essence and not read bullet point by +bullet point. + +I try to never deviate from the script and if I do, be very explicit about it. + +A great exercise I can recommend is to watch a tutorial on a new programming +language/tool you have never used. It can feel very overwhelming and fast to +get all these new concepts and tools thrown at self. This can prepare me for +how a participant might feel listening to me. + +I very much like the co-teaching approach where the other person helps +detecting when I go too fast or become too confusing. I like when two +instructors complement each other during a lesson. +::: > ## Sabry Razick > My approach is to show it is fun to demystify concepts. Once a concept is