OverviewTeaching: 30 min
Exercises: 0 minQuestions
What teaching practices are common to Software and Data Carpentry?Objectives
Describe and demonstrate three of the key teaching practices used in Software and Data Carpentry workshops and explain their benefits.
Explain why it is difficult to stream workshop participants by prior knowledge.
Describe and critique two strategies for managing a class in which students have diverse backgrounds and skill levels.
We regard teaching as a performance art, no different from drama, music, or athletics. And as in those fields, we have a collection of small tips and tricks to make teaching work better.
With live coding, it is easy for some learners to fall behind, and for other learners to get bored. Given the diversity of our learners’ backgrounds and skills, we will always have a mix of more and less advanced people in our classes. No matter what we teach, and how fast or how slow we go, 20% or more of the room will be lost, and there’s a good chance that a different 20% will be bored.
The obvious solution is to split people by level, but if we ask them how much they know about particular things, they regularly under- or over-estimate their knowledge. We have therefore developed a short pre-assessment questionnaire that asks them how easily they could do a small number of specific tasks. It gives instructors some idea of who they’re going to be helping, but we have not validated the questions, i.e., we have not done the laborious work of interviewing respondents to ensure that they are interpreting the questions the same way that we are. We also have not yet done the follow-up to see whether the questionnaires’ categorization of learners matches their actual in-class proficiency.
You Can’t Just Ask
Instead of asking people how easily they could complete specific tasks, we could just ask them to rate their knowledge of various subjects on a scale from 1 to 5. However, self-assessments of this kind are usually inaccurate because of the Dunning-Kruger effect: the less people know about a subject, the less accurate their estimate of their knowledge is.
That said, there are things we can do:
The most important thing is to accept that no class can possibly meet everyone’s individual needs. If the instructor slows down to accommodate two people who are struggling, the other 38 are not being well served. Equally, if she spends a few minutes talking about an advanced topic because two learners are bored, the 38 who don’t understand it will feel left out. All we can do is tell our learners what we’re doing and why, and hope that they’ll understand.
Minute cards are anonymous; the alternating up-and-down feedback is not. Each mode has its strengths and weaknesses, and by providing both, we hope to get the best of both worlds.
We have experimented with virtual machines (VMs) on learners’ computers to reduce installation problems, but those introduce problems of their own: older or smaller machines simply aren’t fast enough, and learners often struggle to switch back and forth between two different sets of keyboard shortcuts for things like copying and pasting.
Some instructors use VPS over SSH or web browser pages instead. This solve the installation issues, but makes us dependent on host institutions’ WiFi (which can be of highly variable quality), and has the issues mentioned above with things like keyboard shortcuts.
One of the advantages of collaborative note-taking is that it gives the more advanced learners in the class something useful to do. Another is that the notes the learners take are usually more helpful to them than those the instructor would prepare in advance, since the learners are more likely to write down what they actually found new, rather than what the instructor predicted would be new. Finally, scanning the Etherpad is a good way for an instructor to discover that the class didn’t hear something important, or misunderstood it.
When pair programming is used it’s important to put everyone in pairs, not just the learners who are struggling, so that no one feels singled out. It’s also useful to have people sit in new places (and hence pair with different partners) after each coffee or meal break.
Beyond the teaching practices and philosophies found in Software and Data Carpentry workshops, one of the most important characteristics of our workshops is that they be welcoming and safe spaces. Programming, or data management are scary topics to novices, and workshops are meant to be a judgment free space to learn and experiment. The behavior of the instructor and other partipants may make more of an impression on a novice learner than any “technical” topic you teach.
To support this mission Software Carpentry and Data Carpentry have a shared code of conduct (online here and here) and participants in our workshops are required to abide by it. Hosts must point people at it during registration, and instructors must remind attendees of it at the start of the workshop. The Code of Conduct doesn’t just tell everyone what the rules are: it tells them that there are rules, and that they can therefore expect a safe and welcoming learning experience.
If you are an instructor, and believe that someone in a workshop has violated the Code of Conduct, you may warn them, ask them to apologize, and/or expel them, depending on the severity of the violation and whether or not you believe it was intentional. No matter what you choose to do, you should contact the appropriate Carpentry administrator at firstname.lastname@example.org or email@example.com as soon as you can, and describe what happened in the next online debriefing session that you’re able to attend.
You also have the right as an instructor to walk out of a workshop if you feel that the participants or hosts are not supporting your attempts to enforce the Code of Conduct. Again, please contact us as soon as possible if this happens.
A Code of Conduct is one way to create a safe learning space - making sure that you are properly motivating (and not de-motivating) your students is another. In our next module, we will talk in more detail about what we can do to support motivation in our learners.
Why Not a MOOC?
Many learners find it difficult to get to a workshop, either because there isn’t one locally or because it’s difficult to schedule time around other commitments, so why don’t we create video recordings of the lessons and offer the workshop as a MOOC (Massive Open Online Course)?
The first answer is that we did in 2010-11, but found the maintenance costs unsustainable. Making a small change to this webpage only takes a few minutes. but making any change to a video takes an hour or more. In addition, most people are much less comfortable recording themselves than contributing written material.
The second answer is that doing significantly outperforms watching. Specifically, a recent paper by Koedinger et al estimated “…the learning benefit from extra doing (1 SD increase) to be more than six times that of extra watching or reading.” Doing, in this case, refers to completing an interactive or mimetic task with feedback, while benefit refers to both completion rates and overall performance.
And while we do not (yet) have empirical data, we believe very strongly that many novices would give up in despair if required to debug setup and installation lessons on their own, but are more likely to get past these obstacles if someone is present to help them.
An intermediate approach that we are experimenting with is real-time remote instruction, in which the learners are co-located at one (or a few) sites, with helpers present, while the instructor(s) teaching via online video. This model has worked well for this instructor training course, and for a handful of regular workshops, but more work is needed to figure out its pros and cons.
Live coding is a more effective way to teach programming than slides or whiteboarding.
Making and correcting mistakes in front of learners is good teaching practice.
Try to segment learners by prior knowledge.
Ask more advanced learners to help colleagues during lessons.
Use sticky notes as status indicators.
Collaborative note-taking improves learning outcomes.
Pair programming aids learning, but have everyone pair so no-one feels singled out.