From 404aa40f43c59bbaff696fab0ca606d7f7c59d18 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Bj=C3=B8rn=20Lindi?= Date: Mon, 5 Aug 2024 10:10:55 +0200 Subject: [PATCH 1/4] Add teaching philosophies for current instructors. --- content/teaching-philosophies.md | 143 ++++++++++++++++++++++++++++++- 1 file changed, 142 insertions(+), 1 deletion(-) diff --git a/content/teaching-philosophies.md b/content/teaching-philosophies.md index c0627f5..c4c7222 100644 --- a/content/teaching-philosophies.md +++ b/content/teaching-philosophies.md @@ -12,7 +12,148 @@ ::: -Here the episode sections and text ... +# CodeRefinery teaching philosophies +During this episode we split into breakoutrooms and discuss own teaching philosophies. +Collect your teaching philosophies in the collaborative document. We will be going through +these and the end of the lesson. + +> ## Ice-breaker in groups (20 minutes) +> +> - Share your approach to teaching and your teaching philosophy with your group. +> - Please share your tricks and solutions in the live document for others. +> +> Additional ice-breaker questions: +> - What is your motivation for taking this training? +> - How structured or informal are your own teaching needs? +> - What difference do you notice between the teaching what we (also +> Carpentries) do and traditional academic teaching? +> - What other skills need to be taught, but academic teaching isn't the right setting? +{: .challenge} + +--- + +Here CodeRefinery instructors share their training philosophy to show that we +all have different teaching styles and how these differences are beneficial to +CodeRefinery workshops. + +It is important to explain how much we value individuals and that there is not +one way to teach but as many ways as individuals. We want to help each other to +find the way that is best for each of us. + +> ## Video recordings +> +> Recently we have recorded some of the below as videos: +> +{: .prereq} + +> ## Bjørn Lindi +> +> My teaching style has changed a bit since I started with CodeRefinery. In the beginning I had this "BLOB" (Binary Large OBject) of knowledge and experience that I wanted to to convey to the participants. With experience and some help from the Carpentries Instructor training, I have realized I need to serialize the "BLOB", to be able to share it with others. +> +>In a similar fashion as you would do with a binary large object which you intend to send over the wire, you will need stop signals, check-sums and re-transmissions, when you give a lecture. I have come to appreciate the natural periods/breaks the lessons offers, the questions raised, the errors that appear during type-along and the re-transmission. Co-instructors are good to use for re-transmission or broadening a specific topic. +> +>When I started with CodeRefinery my inclination was to give a lecture. Today I am trying to be a guide during a learning experience, a learning experience which includes me as well. That may sound a bit self-centric, but is in fact the opposite, as I have to be more sensitive to what is going on in the room. The more conscious I am of being a guide, the better lesson. +> +>Tools that I find useful in preparing a lesson is concept maps and Learner Personas, though I have develop to few them. +>- [Concept Maps](https://teachtogether.tech/#s:memory-concept-maps) +>- [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} + +> ## Sabry Razick +> My approach is to show it is fun to demystify concepts. Once a concept is +> not a mystery anymore, the learners will understand is what it means, where +> it is coming from, why it is in place and what it could it offer for their future. +> I try to relate concepts to real life with a twist of humour whenever possible if +> the outcome is certain not be offensive to any one. I use diagrams whenever possible, +> I have spent weeks creating diagrams that is sometime three or four sentences. That +> effort I consider worthwhile as my intention is not to teach, but to demystify. +> Once that is achieved, learners will learn the nitty gritty on their own easily +> and with confidence, when they have the use-case. +> +> +{: .challenge} + +{: .challenge} + +> ## Richard Darst +> +> Like many people, I've often been teaching, but rarely a teacher. I +> tend to teach like I am doing an informal mentorship. +> I've realized long ago that my most important lessons weren't +> learned in classes, but by a combination of seeing things done by +> friends and independent study after that. I've realized that +> teaching (the things I teach) is trying to correct these differences +> in backgrounds. +> +> My main job is supporting computing infrastructure, so my teaching +> is very grounded in real-world problems. I'm often start at the +> very basics, because this is what I see missing most often. +> +> When teaching, I like lots of audience questions and don't mind +> going off-script a bit (even though I know it should be minimized). +> I find that sufficient audience interest allows any lesson to be a +> success - you don't have to know everything perfectly, just show how +> you'd approach a problem. +> +{: .challenge} + :::{keypoints} From ca9144b77bf12a19f1c9b3e371d72989e89c962c Mon Sep 17 00:00:00 2001 From: Radovan Bast Date: Wed, 7 Aug 2024 11:08:13 +0200 Subject: [PATCH 2/4] 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 From 1ac3445ab1f801baf6795bf8c822ca048ad43e6e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Bj=C3=B8rn=20Lindi?= Date: Thu, 22 Aug 2024 12:45:06 +0200 Subject: [PATCH 3/4] Add timings --- content/teaching-philosophies.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/teaching-philosophies.md b/content/teaching-philosophies.md index f8df8a8..a10c712 100644 --- a/content/teaching-philosophies.md +++ b/content/teaching-philosophies.md @@ -7,8 +7,8 @@ ::: :::{instructor-note} -- Teaching: ? min -- Exercises: ? min +- Teaching: 10 min +- Discussion: 20 min ::: @@ -42,7 +42,7 @@ find the way that is best for each of us. > ## Video recordings > -> Recently we have recorded some of the below as videos: +> We have recorded some of the below as videos: > {: .prereq} From 2c87ebce20fbf66be170e4f0ac202d47f27dc574 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Bj=C3=B8rn=20Lindi?= Date: Thu, 22 Aug 2024 13:48:25 +0200 Subject: [PATCH 4/4] Added keypoint and did something to the formatting. --- content/teaching-philosophies.md | 68 +++++++++++++++----------------- 1 file changed, 32 insertions(+), 36 deletions(-) diff --git a/content/teaching-philosophies.md b/content/teaching-philosophies.md index a10c712..56145af 100644 --- a/content/teaching-philosophies.md +++ b/content/teaching-philosophies.md @@ -110,46 +110,42 @@ 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 -> not a mystery anymore, the learners will understand is what it means, where -> it is coming from, why it is in place and what it could it offer for their future. -> I try to relate concepts to real life with a twist of humour whenever possible if -> the outcome is certain not be offensive to any one. I use diagrams whenever possible, -> I have spent weeks creating diagrams that is sometime three or four sentences. That -> effort I consider worthwhile as my intention is not to teach, but to demystify. -> Once that is achieved, learners will learn the nitty gritty on their own easily -> and with confidence, when they have the use-case. -> -> -{: .challenge} +:::{challenge} Sabry Razick +My approach is to show it is fun to demystify concepts. Once a concept is +not a mystery anymore, the learners will understand is what it means, where +it is coming from, why it is in place and what it could it offer for their future. +I try to relate concepts to real life with a twist of humour whenever possible if +the outcome is certain not be offensive to any one. I use diagrams whenever possible, +I have spent weeks creating diagrams that is sometime three or four sentences. That +effort I consider worthwhile as my intention is not to teach, but to demystify. +Once that is achieved, learners will learn the nitty gritty on their own easily +and with confidence, when they have the use-case. -{: .challenge} -> ## Richard Darst -> -> Like many people, I've often been teaching, but rarely a teacher. I -> tend to teach like I am doing an informal mentorship. -> I've realized long ago that my most important lessons weren't -> learned in classes, but by a combination of seeing things done by -> friends and independent study after that. I've realized that -> teaching (the things I teach) is trying to correct these differences -> in backgrounds. -> -> My main job is supporting computing infrastructure, so my teaching -> is very grounded in real-world problems. I'm often start at the -> very basics, because this is what I see missing most often. -> -> When teaching, I like lots of audience questions and don't mind -> going off-script a bit (even though I know it should be minimized). -> I find that sufficient audience interest allows any lesson to be a -> success - you don't have to know everything perfectly, just show how -> you'd approach a problem. -> -{: .challenge} +::: + +:::{challenge} Richard Darst +Like many people, I've often been teaching, but rarely a teacher. I +tend to teach like I am doing an informal mentorship. +I've realized long ago that my most important lessons weren't +learned in classes, but by a combination of seeing things done by +friends and independent study after that. I've realized that +teaching (the things I teach) is trying to correct these differences +in backgrounds. + +My main job is supporting computing infrastructure, so my teaching +is very grounded in real-world problems. I'm often start at the +very basics, because this is what I see missing most often. + +When teaching, I like lots of audience questions and don't mind +going off-script a bit (even though I know it should be minimized). +I find that sufficient audience interest allows any lesson to be a +success - you don't have to know everything perfectly, just show how +you'd approach a problem. +::: :::{keypoints} -- Here we summarize keypoints. +- People have different viewpoints on teaching. :::