Introduction

Hundreds of grassroots groups have sprung up around the world to teach programming, web design, robotics, and other skills to free-range learners outside traditional classrooms. These groups exist so that people don’t have to learn these things on their own, but ironically, their founders and instructors are often teaching themselves how to teach.

There’s a better way. Just as knowing a few basic facts about germs and nutrition can help you stay healthy, knowing a few things about psychology, instructional design, inclusivity, and community organization can help you be a more effective teacher. This book presents evidence-based practices you can use right now, explains why we believe they are true, and points you at other resources that will help you go further. Its four sections cover:

  • how people learn;
  • how to design lessons that work;
  • how to deliver those lessons; and
  • how to grow a community of practice around teaching.

Throughout, we try to follow our own advice: for example, we start with ideas that are short, engaging, and actionable in order to motivate you to read further (s:motivation), include lots of exercises that can be used to reinforce learning (s:models), and include the original design for this book in s:v3 so that you can see what a lesson design looks like.

This Book Belongs to Everyone

This book is a community resource. Parts of it were originally created for the Software Carpentry instructor training program, which has been run over several hundred times over the past six years, and all of it can be freely distributed and re-used under the Creative Commons - Attribution 4.0 license (s:license). Please see http://teachtogether.tech/ to download a digital version or purchase a printed copy at cost.

Contributions of all kinds are welcome, from errata and minor improvements to entirely new sections and chapters. All proposed contributions will be managed in the same way as edits to Wikipedia or patches to open source software, and all contributors will be credited for their work each time a new version is released. Please see s:joining for details and s:joining-covenant for our code of conduct.

Who You Are

s:process-personas explains how to figure out who your learners are. The four I had in mind when writing this book are all end-user teachers: teaching isn’t their primary occupation, they have little or no background in pedagogy, and they may work outside institutional classrooms.

Emily
trained as a librarian, and now works as a web designer and project manager in a small consulting company. In her spare time, she helps run web design classes for women entering tech as a second career. She is now recruiting colleagues to run more classes in her area using the lessons that she has created, and wants to know how to grow a volunteer teaching organization.
Moshe
is a professional programmer with two teenage children whose school doesn’t offer programming classes. He has volunteered to run a monthly after-school programming club, and while he frequently gives presentations to colleagues, he has no experience designing lessons. He wants to learn how to build effective lessons in collaboration with others, and is interested in turning his lessons into a self-paced online course.
Samira
is an undergraduate in robotics who is thinking about becoming a full-time teacher after she graduates. She wants to help teach weekend workshops for undergraduate women, but has never taught an entire class before, and feels uncomfortable teaching things that she’s not an expert in. She wants to learn more about education in general in order to decide if it’s for her.
Gene
is a professor of computer science whose research area is operating systems. They have been teaching undergraduate classes for six years, and increasingly believe that there has to be a better way. The only training available through their university’s teaching and learning center relates to posting assignments and grades in the learning management system, so they want to find out what else they ought to be asking for.

These people have a variety of technical backgrounds and some previous teaching experience, but no formal training in teaching, lesson design, or community organization. Most work with free-range learners and are focused on teenagers and adults rather than children; all have limited time and resources.

s:joining-using describes different ways people have used this material. (That discussion is delayed to an appendix because it refers to some of the ideas introduced later in this book.) We expect our made-up learners to use this material as follows:

Emily
will take part in a weekly online reading group with her volunteers.
Moshe
will cover part of this book in a two-day weekend workshop and study the rest on his own.
Samira
will use this book in a one-semester undergraduate course with assignments, a project, and a final exam.
Gene
will read the book on their own in their office or while commuting, wishing all the while that universities did more to support high-quality teaching.

What to Read Instead

If you are in a hurry, or want a taste of what this book will cover, [Brow2018] presents ten evidence-based tips for teaching computing. You can download the paper, or read it online, on the PLoS website.

I also recommend:

  • The Carpentries instructor training, for which most of the first half of this book was originally developed.

  • [Lang2016] and [Hust2012], which are short, approachable, and connect things you can do right now to the research that backs them.

  • [Majo2015], [Broo2016], [Berg2012], and [Rice2018]. The first catalogs a hundred different kinds of exercises you can do with students; the second describes fifty different ways that groups can discuss things productively, while the third is a collection of patterns for teaching, and the fourth explains why to give learners breaks in class and ways to use them productively. These books can be used on their own, but I think they make more sense once Huston or Lang have given you a framework for understanding them.

  • [DeBr2015], which conveys a lot of what is true about educational by explaining what isn’t, and [Dida2016], which grounds learning theory in cognitive psychology.

  • [Pape1993], which remains an inspiring vision of how computers could change education.

  • [Gree2014], [McMi2017] and [Watt2014]. These three short books explain why so many attempts at educational reform have failed over the past forty years, how for-profit colleges are exploiting and exacerbating the growing inequality in our society, and how technology has repeatedly failed to revolutionize education.

  • [Guzd2015a], [Hazz2014], and [Sent2018], which are academically-oriented books I’ve found useful about teaching computing.

  • [Brow2007] and [Mann2015], because you can’t teach computing well without changing the system in which we teach, and you can’t do that on your own.

Of these, [Pape1993] is the one that shaped my ideas about teaching the most. Papert’s central argument is that people don’t absorb knowledge; instead, they (re-)construct it for themselves, and computers are a new and powerful tool for helping them do that. Andy Ko’s excellent description does a better job of summarizing Papert’s ideas than I possibly could, and [Craw2010] is a thought-provoking companion to both.

History

A lot of my stories aren’t true, but this is a true story…

When I started teaching people how to program in the late 1980s, I went too fast, used too much jargon, and had no idea how much my learners actually understood. I got better over time, but still felt like I was stumbling around in a darkened room.

In 2010, I rebooted a project called Software Carpentry that teaches basic computing skills to researchers. (The name “carpentry” was chosen to distinguish what we taught from software engineering: we were trying to show people the digital equivalent of painting a bathroom, not building the Channel Tunnel.) In the years that followed, I discovered resources like Mark Guzdial’s blog and the book How Learning Works [Ambr2010]. These in turn led me to books like [Hust2012,Lemo2014,Lang2016] that showed me how to build and deliver better lessons in less time and with less effort.

I started using these ideas in Software Carpentry in 2012. The results were everything I’d hoped for, so I began running training sessions to pass on what I’d learned. Those sessions became a training program that dozens of trainers have now taught to over a thousand people on six continents. Since then, I have run the course for people who teach programming to children, librarians, and women re-entering the workforce or changing careers, and all of those experiences have gone into this book.

Why Learn to Program?

Politicians, business leaders, and educators often say that people should learn to program because the jobs of the future will require it; for example, [Scaf2017] found that people who aren’t software developers but who still program make higher wages than comparable workers who do not.

However, as Benjamin Doxtdator has pointed out, many of those claims are built on shaky ground. Even if they were true, education shouldn’t prepare people for the jobs of the future: it should give them the power to decide what kinds of jobs there are, and to ensure that those jobs are worth doing. And as Mark Guzdial points out, there are actually many reasons to learn how to program:

  1. To understand our world.

  2. To study and understand processes.

  3. To be able to ask questions about the influences on their lives.

  4. To use an important new form of literacy.

  5. To have a new way to learn art, music, science, and mathematics.

  6. As a job skill.

  7. To use computers better.

  8. As a medium in which to learn problem-solving.

Part of what motivates me to teach is the hope that if enough people understand how to make technology work for them, we will be able to build a society in which all of the reasons above are valued and rewarded (s:finale).

Have a Code of Conduct

The most important thing I’ve learned about teaching in the last thirty years is how important it is for everyone to treat everyone else with respect, both in and out of class. If you use this material in any way, please adopt a Code of Conduct like the one in s:conduct and require everyone who takes part in your classes to abide by it.

A Code of Conduct can’t stop people from being offensive, any more than laws against theft stop people from stealing. What it can do is make expectations and consequences clear. More importantly, having one tells people that there are rules, and that they can expect a friendly learning experience.

If someone challenges you about having a Code of Conduct, remind them that it isn’t an infringement of free speech. People have a right to say what they think, but that doesn’t mean they have a right to say it wherever and whenever they want. If they want to make someone feel unwelcome, they can go and find their own space in which to do it.

Acknowledgments

This book would not exist without the hard work and feedback of Erin Becker, Azalee Bostroem, Hugo Bowne-Anderson, Neil Brown, Gerard Capes, Francis Castro, Dav Clark, Warren Code, Ben Cotton, Richie Cotton, Karen Cranston, Katie Cunningham, Natasha Danas, Matt Davis, Neal Davis, Mark Degani, Tim Dennis, Michael Deutsch, Brian Dillingham, Kathi Fisler, Auriel Fournier, Bob Freeman, Nathan Garrett, Mark Guzdial, Rayna Harris, Ahmed Hasan, Ian Hawke, Felienne Hermans, Kate Hertweck, Toby Hodges, Dan Katz, Christina Koch, Shriram Krishnamurthi, Katrin Leinweber, Colleen Lewis, Lenny Markus, Sue McClatchy, Jessica McKellar, Ian Milligan, Lex Nederbragt, Aleksandra Nenadic, Jeramia Ory, Joel Ostblom, Elizabeth Patitsas, Aleksandra Pawlik, Sorawee Porncharoenwase, Emily Porta, Alex Pounds, Thomas Price, Danielle Quinn, Ian Ragsdale, Erin Robinson, Rosario Robinson, Ariel Rokem, Pat Schloss, Malvika Sharan, Florian Shkurti, Juha Sorva, Tracy Teal, Tiffany Timbers, Richard Tomsett, Preston Tunnell Wilson, Matt Turk, Fiona Tweedie, Anelda van der Walt, Stéfan van der Walt, Allegra Via, Petr Viktorin, Belinda Weaver, Hadley Wickham, Jason Williams, Simon Willison, John Wrenn, and Andromeda Yelton. I am grateful to them, to Lukas Blakk for the cover image, and to everyone who has used this material over the years; any mistakes that remain are mine.

Breaking the Law

Much of the research reported in this book was publicly funded, but despite that, a lot of it is locked away behind paywalls. At a guess, I broke the law roughly 250 times to download papers from sites like Sci-Hub. I hope the day is coming when no one will need to do that; if you are a researcher, please hasten that day by publishing your research in open access venues, or by posting copies on open preprint servers.

Exercises

Each chapter ends with a variety of exercises that include a suggested format and an indication of how long they usually take in an in-person setting. Most can be used in other formats—in particular, if you are going through this book on your own, you can still do many of the exercises that are described as being for groups—and you can always spend more time on them than what’s suggested.

The exercises in this chapter can be used as preassessment questions (s:classroom-prior) rather than as in-class exercises. If you have learners answer them a few days before a class or workshop starts, they will give you a much clearer idea of who they are and how best you can help them.

Highs and Lows (whole class/5)

Write brief answers to the following questions and share with your peers. (If you are taking notes together online as described in s:classroom-notetaking, put your answers there.)

  1. What is the best class or workshop you ever took? What made it so good?

  2. What was the worst one? What made it so bad?

Know Thyself (whole class/5)

Write brief answers to the following questions and share them as described above. Keep your answers somewhere so that you can refer to them as you go through the rest of this book.

  1. What do you most want to teach?

  2. Who do you most want to teach?

  3. Why do you want to teach?

  4. How will you know if you’re teaching well?

Starting Points (individual/5)

Write brief answers to the following questions and share them as described above. Keep your answers somewhere so that you can refer to them as you go through the rest of this book.

  1. What do you most want to learn about teaching and learning?

  2. What is one specific thing you believe is true about teaching and learning?

Why Learn to Program? (individual/20)

Re-read Guzdial’s list of reasons to learn to program in s:intro-why, then draw a 3x3 grid whose axes are labelled “low”, “medium”, and “high” and place each point in one sector according to how important it is to you (the X axis) and to the people you plan to teach (the Y axis).

  1. Which points are closely aligned in importance (i.e., on the diagonal in your grid)?

  2. Which points are misaligned (i.e., in the off-diagonal corners)?

  3. How does this change what you teach?