Update teaching philosophies

content/teaching-philosophies.md

@@ -7,14 +7,145 @@
 :::
 
 :::{instructor-note}
-- Teaching: ? min
-- Exercises: ? min
+- Teaching: 10 min
+- Discussion: 20 min
 :::
 
 
-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
+>
+> We have recorded some of the below as videos:
+> <https://www.youtube.com/playlist?list=PLpLblYHCzJAAHF89P-GCjEXWC8CF-7nhX>
+{: .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}
+
+:::{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.
+:::
+
+:::{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.
+
+:::
 
 
 :::{keypoints}
-- Here we summarize keypoints.
+- People have different viewpoints on teaching.
 :::