​Below are 5 example pitches we’ve written to give you some idea of how a pitch could look like. Those are not made up 🙂 They will hopefully become real chapters!
Draft pitch: 3 Stars and 1 Wish: Small and Frequent Student Reflections to promote a Sense of Wonder and a Community of Vulnerability
(team: Pawel, Elaine, Clare, Bea, Karim, Rebecca)
“3 Stars and 1 Wish” (3s1w) is an assessment method widely used at the University of Edinburgh, encouraging students to engage in frequent self-reflection. We will describe how it works, who uses it and our current study analysing its benefits. Since 2019 it was used by over 1000 students on 25 Courses across Business School, Edinburgh Futures Institute (EFI), and Medicine at University of Edinburgh.
The technique was originally inspired by reflection practices in primary schools (Mullane, 2013) and has since undergone several iterations. The 3s1w is a short frequent self-reflection written about each piece of learning (e.g. lecture, badge). For each badge, each student lists: 3 things which they found new/interesting/curious (stars) and 1 thing which they wish to understand better (wish). We explored variations in terms of marking, openness and frequency, and alternative prompts (e.g. “Like, Wish, Wonder”, “3 stars, 1 Wish, 1 Step”).
This “assessment for learning” (not “assessment of learning”) (Black, 2003; Dylan, 2011) leverages both self- and community-insights. It draws inspiration from ‘liberating structures’ (Lipmanowicz, 2013), lightly-constraint activities designed to empower students to share their insights equitably. We also take inspiration from the concept of a Gratefulness Journal where individuals are frequently asked to list “things we are grateful for” encouraging a mindset where they notice and appreciate such positives. The same can happen as learners are ‘looking out for’ things that bring them joy in the course. Since students see each other’s posts, we also observed a ‘Community of Vulnerability’ – a space where students feel safe to admit their struggles, and see that they are not alone. The “wish” aims to replace the fear and stigma of being confused or lost, with a sense of pride in the educational struggle (ref? That learning requires struggle?). This approach promotes sustainable growth over maintaining a false facade of constant high achievement. The additional benefit of 3s1w is that the teaching team has a constant feedback loop of what content is being absorbed well and where the students struggle.
We will also present student’s perspective and early results of our academic study of 23 courses using 3s1w at the Usher Institute.
Draft Pitch: Pair programming – structured student group work for practical programming labs
(type: teaching practice, instructions, research study)
(team: pawel, Umberto Noe, Kasia, Brittany)
Pair programming is an Agile technique widely used in the software industry, and over the last decade also in education. It involves two people working together on one programming task. One person is the driver, suggesting solutions and typing the code; the other person is the navigator, helping with problem-solving, spotting mistakes, and acting as the sounding board for the driver. After a short time, they swap roles.
In education, the use of pair programming has been shown to result in better quality code and more discussion between students than solo programming (Hawlitschek et al., 2022). The literature shows that it is particularly beneficial for students with lower prior programming skills (Goel & Kathuria, 2010). At the University of Edinburgh, we use pair programming extensively in programming and data science courses.
With the increase in class sizes, and with the constraints given by space availability in teaching rooms, this chapter aims to provide instructors with clear and practical guidelines on how to extend the well-known pair programming principles to larger groups, while retaining the benefits of the approach.
We’ll review our 7 years of using this practice in various contexts, including large and transient groups. We aim to provide a set of guidelines for instructors wanting to introduce pair-programming in their courses, with a view towards larger classes. We describe how this practice can be modified in response to many axis: course size, group size, modality (online/room/hybrid), topic, skill levels, role-switching frequency, pair-matching techniques, teaching team availability, etc. For example, we trialled students working in various group sizes: 2, 3 and even 5+ (‘peer programming’, ‘mob programming’), or switching roles in various ways (every task, every 20 minutes, every lab).
We would like this chapter to include (1) a video explaining pair-programming to students, which can be used by instructors ahead of the class to explain the setup, (2) a checklist of guidelines on how to successfully implement this, (3) a white-paper with recommendations and issues to keep an eye for and suggested tips on how to resolve them (e.g. Neurodiversity, accessibility), (4) infographics explaining the advantages of pair-programming for experiential learning opportunities.
Draft Pitch: Learning together in the Fusion / Hybrid course – interactions between on-line and in-person students
(type: stories, case studies, course innovation)
(team: Clare, Bea, Pawel)
This chapter will be a set of stories about student interactions in a fusion course (online & in-person at the same time): Negotiating Fusion-Pairs, Ghost Helper, and Micro-Interactions.
Since the post-2020 online-pivot we prototyped and ran Edinburgh Future Institute’s first fusion course: Text Mining for Social Research. Fusion courses involve both in-person and online students. This style of teaching requires at least two instructors – one that provides the content and one that looks after the interaction. Since there were four of us we had the bandwidth to play with interaction. Here are things we found that worked:
Negotiating Fusion-Pairs – We iterated assigning students in same-mode pairs (room-room or online-online) or mixed-mode pairs (room-online). It was important to do this as we wanted the whole class to feel like a single cohort. We changed the setup every hour, student pairs had to negotiate: how they work together, who leads, how they interact with instructors.
Ghost Helper – In an in-person class students can request help from the in-person teacher. In a fusion mode, an in-person pair can do the same. But if one or both of the students are online the helper must be online. For a student in the room, this can come as a surprise, when the person they have just interacted with appears in their ear, like a friendly ghost. This requires a cognitive shift and can divert attention. During mixed-mode pairwork we consciously switched to online helpers only, so students were initially spooked by the ghost but they found it friendly. Boo!
Micro-Interactions – Small moments of joy and frustration are when learning can happen. We used:
1) Relentless feedback: Asking for hourly snap feedback using a whiteboard to take the temperature of student learning.
2) Chat blast: asking all students to type something small, a micro contribution, into the chat at the same time.
3) Amplification learning: all student questions were repeated in front of the class during each debriefing session or students could disseminate their own solutions through the chat.
Draft Pitch: Learning Badges – micro and macro patterns for modular course design
(type: course design, case studies, modularity)
(team Pawel, Clare, Bea)
Collecting Badges – teaching with flexible, modular and structured ‘achievements’.
Since 2019 we honed the concept of teaching with content Badges (inspired by Scouts’ achievements) – small and well defined units of content (each taking 1-2 hours to absorb). Each badge follows the same micro-structure, a pipeline of learning techniques (content, skill, insight, challenge) and modalities (videos, notes, exercises).
In this chapter we describe: how we used Badges within Business School , EFI and School of Medicine courses; the Badge micro-patterns we settled on; and how it handled the trial-by-fire of teaching in 2020 and subsequent challenges. We describe in detail a semester-long 20-credit Python Programming course (20 badges); a 3-day bootcamp in Text Mining for Social Sciences (6-7 badges) and 5-week fusion/hybrid course in School of Medicine (15 badges).
The principles that guided us were: flexibility, compartmentalisation and empowering the learner. Each badge is built around a Threshold concept, a core step or skill (a ‘eureka’ moment) that opens the doors to further learning. Via a clear name and symbol, each badge signposts students’ takeaways and how it fits within the top level learning journey.
The macro-structure in which badges form a course is complemented by a micro-structure of each badge: ‘flipped’ instructional and code-along videos, notebooks with worked examples, exercises of increasing difficulty, introspection diary, relentless feedback, pair work and test-driven assignment. Badges build on top of each other, forming branches and enabling optional, further learning. Additionally, the modular micro-structure, enables easier switching between platforms or teaching modes (e.g. videos vs slides) and multiplies the benefits of improvements.
Badges proved to be a promising format for delivering teaching, especially in times of change, disruption and pivoting.
Draft Pitch: 8 ways Pair-Programming classrooms vary: choose your own pair-programming adventure
(type: teaching methods, case studies)
(team Umberto, Pawel, Brittany, Bea, Clare, Serveh and Ozan?)
- Who works with whom? Different sizes of pair/groups that work together. How is that influenced by course size and type of room or video-call platform. How frequently pairs change? How are pairs established.Â
- What are the roles of students and teachers? What is the exact role of the driver? How does navigator(s) engaging with the exercise? How is the teaching team helping with running the exercise? What are do’s and don’t for staff facilitating? How to establish a Code of Conduct? How to deal with inevitable problems that will arise?Â
- In what modality students meet (online, hybrid, in person)? How to deal with the logistics? What are opportunities/challenges around software platforms?Â
- How are pairs created? Should pairs be prescribed or student-selected? What pair-matching techniques we tried (random, optimising for non-repeated pairs, or optimising for student attributes). If optimising for student attributes, what can we use e.g. skill levels, personal preferences, and what are considerations around that?Â
- When and how students switch roles (driver/navigator): after each task, each session, across different weeks of the course, etc. Â
- Implementation: Programming Language? Or topic/application e.g. Text mining, graphs, data? Tool (IDE) e.g., RStudio, Jupyter, Cloud-based server Â
- Pedagogy of the course: flipped classroom, lecture-based, self-driven (e.g., carpentries)?Â
- ‘Lesson Plans’ of pair programming: (concluding the session (e.g., bringing everyone back for a debrief or sharing reflections, allowing students to continue programming if they want after the class ends, etc). Or when and how to provide example solutions?Â