This material is in early beta: over 300 suggestions and corrections are waiting to be folded in, some quite significant. Changes should be in place by July 2018, at which times printed copies and downloadable electronic copies will be made available.

Motivation and Demotivation

After reading this chapter, you will be able to

  • Explain the difference between intrinsic and extrinsic motivation.
  • Name and describe three ways in which teachers can demotivate learners.
  • Define impostor syndrome and describe ways to combat it.
  • Explain what stereotype threat and fixed vs. growth mindset are, summarize the strength of evidence supporting each, and describe their implications for teaching.
  • Describe and enact three things teachers can do to make their classes more accessible.
  • Describe and enact three things teacher can do to make their classes more inclusive.

Learners need encouragement to step out into unfamiliar terrain, so this chapter discusses ways teachers can motivate them. More importantly, it talks about ways teachers can accidentally demotivate them, and how to avoid doing that.

Our starting point is the difference between intrinsic motivation, which is what we feel when we find something personally rewarding, from extrinsic motivation, which we feel when we do something to avoid punishment or earn a reward. Both are factors in most situations—for example, people teach because they enjoy it and because they get paid—but we learn best when we are intrinsically motivated [Wlod2017].

The Problem of Grades

I’ve never had an audience in my life. My audience is a rubric.
– quoted by Matt Tierney

Grades and the way they distort learning are often used as an example in discussion of extrinsic motivation, but as [Mill2016a] observes, they aren’t going to go away any time soon, so it’s pointless to try to build a system that ignores them. Instead, [Lang2013] explores how courses that emphasize grades can incentivize students to cheat, and offers some tips on how to diminish this effect, while [Covi2017] looks at the larger problem of balancing intrinsic and extrinsic motivation in institutional education.

As Dylan Wiliam points out in [Hend2017], motivation doesn’t always lead to achievement, but achievement almost always leads to motivation: helping students succeed motivates them far more than telling them how wonderful they are. We can use this idea in teaching by creating a grid whose axes are “mean time to master” and “usefulness once mastered”:

What to Teach
What to Teach

Things that are quick to master and immediately useful should be taught first, even if they aren’t considered fundamental by people who are already competent practitioners, because a few early wins will build learners’ confidence in their own ability and their teacher’s judgment. Conversely, things that are hard to learn and have little near-term application should be skipped entirely, while topics along the diagonal need to be weighed against each other.

Many of the foundational concepts of computer science, such as recursion and computability, inhabit the “useful but hard to learn” corner of this grid. This doesn’t mean that they aren’t worth learning, but if our aim is to convince people that they can learn to program, and that doing so will help them do things that they care about, these big ideas can and should be deferred. Remember, people often don’t want to program for its own sake: they want to make music or explore changes to family incomes over time, and (rightly) regard programming as a tax they have to pay in order to do so.

A well-studied instance of prioritizing what’s useful without sacrificing what’s fundamental is the media computation approach developed at Georgia Tech [Guzd2013]. Instead of printing “hello world” or summing the first ten integers, a student’s first program might open an image, resize it to create a thumbnail, and save the result. This is an authentic task, i.e., something that learners believe they would actually do in real life. It also has a tangible artifact: if the image comes out the wrong size, learners have a concrete starting point for debugging. [Lee2013] describes an adaption of this approach from Python to MATLAB, while others are building courses around data science, image processing, and biology [Dahl2018,Meys2018,Ritz2018].

[Ambr2010] contains a list of evidence-based methods to motivate learners. None of them are surprising—it’s hard to imagine someone saying that we shouldn’t identify and reward what we value—but it’s useful to check lessons against these points to make sure they’re doing at least a few of these things. One strategy I particularly like is to have students who struggled but succeeded come in and tell their stories to the rest of the class. Learners are far more likely to believe stories from people like themselves [Mill2016a], and people who have been through your course will always have advice that you would never have thought of.

Not Just for Students

Discussions of motivation in education often overlook the need to motivate the teacher. Learners respond to a teacher’s enthusiasm, and teachers need to care about a topic in order to keep teaching it, particularly when they are volunteers. This is another powerful reason to co-teach (Section 9.3): just as having a running partner makes it more likely that you’ll keep running, having a teaching partner helps get you up and going on those days when you have a cold and the projector bulb has burned out and nobody knows where to find a replacement and why are they doing construction work today of all days

Teachers can do other positive things as well. [Bark2014] found three things that drove retention for all students: meaningful assignments, faculty interaction with students, and student collaboration on assignments. Pace and workload (relative to expectations) were also significant drivers, but primarily for male students. Things that didn’t drive retention were interactions with teaching assistants and interactions with peers in extracurricular activities. These results may seem obvious, but the reverse would seem obvious too: if the study had found that extracurricular activities drove retention, we would also say “of course”. Noticeably, two of the four retention drivers (faculty interaction and student collaboration) take extra effort to replicate online (Chapter 11).


Women aren’t leaving computing because they don’t know what it’s like; they’re leaving because they do know.
— variously attributed

If you are teaching in a free-range setting, your learners are probably volunteers, and probably want to be in your classroom. The challenge therefore isn’t how to motivate them, but how to not demotivate them. Unfortunately, you can do this by accident much more easily than you might think. For example, [Cher2009] reported four studies showing that subtle environmental clues have a measurable difference on the interest that people of different genders have in computing: changing objects in a CS classroom from those considered stereotypical of computer science (e.g., Star Trek posters and video games) to objects not considered stereotypical (e.g., nature poster, phone books) boosted female undergraduates’ interest in CS to the level of their male peers. Similarly, [Gauc2011] reports a trio of studies showing that gendered wording commonly employed in job recruitment materials can maintain gender inequality in traditionally male-dominated occupations.

The three most powerful demotivators for adult learners are unpredictability, indifference, and unfairness. Unpredictability demotivates people because if there’s no reliable connection between what they do and what outcome they achieve, there’s no reason for them to try to do anything. Indifference demotivates because learners who believe that the teacher or educational system doesn’t care about them or the material won’t care about it either. And people are also demotivated if they believe something is unfair, even if it is unfair in their favor, because they will worry (consciously or unconsciously) that they will some day find themselves in the group on the losing end [Wilk2011]. In extreme situations, learners may develop learned helplessness: when repeatedly subjected to negative feedback that they have no way to change a situation, they may learn not to even try to change things when they could.

Here are a few specific things that will demotivate your learners:

A holier-than-thou or contemptuous attitude

from a teacher or a fellow learner.

Telling them that their existing skills are rubbish.

Unix users sneer at Windows, programmers of all kinds make jokes about Excel, and no matter what web application framework you already know, some programmer will tell you that it’s out of date. Learners have often invested a lot of time and effort into acquiring the skills they have; disparaging them is a good way to guarantee that they won’t listen to anything else you have to say.

Diving into complex or detailed technical discussion

with the most advanced learners in the class.

Pretending that you know more than you do.

Learners will trust you more if you are frank about the limitations of your knowledge, and will be more likely to ask questions and seek help.

Using the J word (“just”) or feigning surprise

(i.e., saying things like “I can’t believe you don’t know X” or “you’ve never heard of Y?”). As discussed in Chapter 3, this signals to the learner that the teacher thinks their problem is trivial and by extension that they must be stupid for not being able to figure it out.

Software installation headaches.

People’s first contact with new programming tools, or programming in general, is often demoralizing, and believing that something is hard to learn is a self-fulfilling prophecy. It isn’t just the time it takes to get set up, or the feeling that it’s unfair to have to debug something that depends on precisely the knowledge they don’t yet have; the real problem is that every such failure reinforces their belief that they’d have a better chance of making next Thursday’s deadline if they kept doing things the way they always have.

It is even easier to demotivate people online than in person, but there are now evidence-based strategies for dealing with this. [Ford2016] found that five barriers to contribution on Stack Overflow are seen as significantly more problematic by women than men: lack of awareness of site features, feeling unqualified to answer questions, intimidating community size, discomfort interacting with or relying on strangers, and the perception that they shouldn’t be slacking. Fear of negative feedback didn’t quite make this list, but would have been the next one added if the authors weren’t quite so strict about their statistical cutoffs. All of these factors can and should be addressed in both in-person and online settings using methods like those in Section 10.6, and doing so improves outcomes for everyone [Sved2016].

Impostor Syndrome

Impostor syndrome is the belief that you aren’t really good enough for a job or position—that your achievements are lucky flukes—and an accompanying fear of someone finding out. Impostor syndrome is common among high achievers who undertake publicly visible work, but most people suffer from it occasionally to some extent. It disproportionately affects members of under-represented groups: as discussed in Section 7.1, [Wilc2018] found that female students with prior exposure to computing outperformed their male peers in all areas in introductory programming courses, but were consistently less confident in their abilities.

Traditional classrooms can fuel impostor syndrome. Schoolwork is frequently undertaken alone or in small groups, but the results are shared and criticized publicly; as a result, we rarely see the struggles of others, only their finished work, which can feed the belief that everyone else finds it easy. Members of underrepresented groups who already feel additional pressure to prove themselves may be particularly affected.

The Ada Initiative has created some guidelines for fighting your own impostor syndrome, which include:

  • Talk about the issue with people you trust. When you hear from others that impostor syndrome is a common problem, it becomes harder to believe your feelings of being a fraud are real.
  • Ask your friends what they think of you. Usually, other people have a more realistic (higher) opinion of your work. Your friends can remind of you major accomplishments you have completely forgotten about.
  • Go to an in-person Impostor Syndrome session at a conference, from your workplace training program, or your school. There’s nothing like being in a room full of people you respect and discovering that 90% of them have impostor syndrome.
  • Watch your words, because they influence how you think. Saying things like, “I’m not an expert in this, but” takes away from the knowledge you actually possess.
  • Teach others about your field. you will gain confidence in your own knowledge and skill, and you will help others avoid some impostor syndrome shoals.
  • Ask questions. Asking questions can be intimidating if you think you should know the answer, but getting answers eliminates the extended agony of uncertainty and fear of failure.
  • Build alliances. Reassure and build up your friends, who will reassure and build you up in return. (And if they don’t, find new friends.)
  • Own your accomplishments. Keep actively recording and reviewing what you have done, what you have built, and what successes you’ve had.
  • Re-orient ourselves around your values and worth. When called upon to step up and show your work, think about your core values and how your work reflects them.

Impostor syndrome thrives in communities with arbitrary, unnecessary standards, where harsh criticism is the norm, and where secrecy surrounds the actual process of getting work done, so the Ada Initiative also has guidelines for communities:

  • Simply encourage people.
  • Discourage hostility and bickering. Public, hostile, personal arguments are a natural breeding ground for impostor syndrome.
  • Eliminate hidden barriers to participation. Be explicit about welcoming new students and colleagues, and thoroughly document how someone can participate in projects and events in your research group and at your institution.
  • As a leader, show your own uncertainties and demonstrate your own learning process. When people see leaders whom they respect struggling or admitting they didn’t already know everything when they started, having realistic opinions of their own work becomes easier.
  • Reward and encourage people in your team and department for mentoring newcomers. Officially enshrine mentoring as an important criterion in your career advancement process.
  • Don’t make it personal when someone’s work isn’t up to snuff. When enforcing necessary quality standards, don’t make the issue about the person. They aren’t wrong or stupid or a waste of space; they’ve simply done one piece of work that didn’t meet your expectations.

As a teacher, you can help people with their impostor syndrome by sharing stories of mistakes that you have made or things you struggled to learn. This reassures the class that it’s OK to find topics hard. Being open with the group makes it easier to build trust and make students confident to ask questions. (Live coding is great for this: as noted in Section 8.3, your typos show your class that you’re human.) You can also emphasize that you want questions: you are not succeeding as a teacher if no one can follow your class, so you’re asking students for their help to help you learn and improve.

Stereotype Threat

Reminding people of negative stereotypes, even in subtle ways, can make them anxious about the risk of confirming those stereotypes, which in turn reduces their performance. This is called stereotype threat, and the clearest examples in computing are gender-related. Depending on whose numbers you trust, only 12–18% of programmers are women, and those figures have actually been getting worse over the last 20 years. There are many reasons for this [Marg2003,Marg2010], and [Stee2011] summarizes what we know about stereotype threat in general and presents some strategies for mitigating it in the classroom.

Rewriting History

[Abba2012] describes the careers and accomplishments of the women who shaped the early history of computing, but have all too often been written out of that history; [Ensm2003,Ensm2012] describes how programming was turned from a female into a male profession in the 1960s, while [Hick2018] looks at how Britain lost its early dominance in computing by systematically discriminating against its most qualified workers: women. [Milt2018] reviews all three books; mentioning any of this makes many Silicon Valley brogrammers uncomfortable to the point of belligerence, which is a good reason to do it.

While there’s lots of evidence that unwelcoming climates demotivate members of under-represented groups, it’s less clear that stereotype threat is the primary cause. Part of the problem is that the term has been used in many ways [Shap2007]; another is questions about the replicability of key studies. What is clear is that we need to avoid thinking in terms of a deficit model, i.e., that the members of under-represented groups are the ones who should change because they have some deficit, such as lack of prior experience. Instead, we should use acknowledge that the system that produces these disparities needs to change.

In particular, it’s easy to use language that suggests that some people are natural programmers and others aren’t, but Guzdial has called this the biggest myth about teaching computer science. [Pati2016] backed this up by showing that people see evidence for a “geek gene” where none exists:

Although it has never been rigorously demonstrated, there is a common belief that CS grades are bimodal. We statistically analyzed 778 distributions of final course grades from a large research university, and found only 5.8% of the distributions passed tests of multimodality. We then devised a psychology experiment to understand why CS educators believe their grades to be bimodal. We showed 53 CS professors a series of histograms displaying ambiguous distributions and asked them to categorize the distributions. A random half of participants were primed to think about the fact that CS grades are commonly thought to be bimodal; these participants were more likely to label ambiguous distributions as “bimodal”. Participants were also more likely to label distributions as bimodal if they believed that some students are innately predisposed to do better at CS. These results suggest that bimodal grades are instructional folklore in CS, caused by confirmation bias and instructors’ beliefs about their students.

Belief that some people get it and some don’t is particularly damaging because of feedback effects. Consciously or unconsciously, teachers tend to focus their attention on learners who seem to be doing well. That extra attention increases the odds that they will, while the corresponding neglect of other learners leaves them further and further behind [Brop1983,Juss2005].


Carol Dweck and others have studied the differences of fixed mindset and growth mindset. If people believe that competence in some area is intrinsic (i.e., that you either “have the gene” for it or you don’t), everyone does worse, including the supposedly advantaged. The reason is that if they don’t get it at first, they figure they just don’t have that aptitude, which biases future performance. On the other hand, if people believe that a skill is learned and can be improved, they do better on average.

As with stereotype threat, there are concerns that growth mindset has been oversold, or that research is much more difficult to put into practice than its more enthusiastic advocates have implied. [Sisk2018] reported two meta-analyses, one looking at the strength of the relationship between mindset and academic achievement, the other at the effectiveness of mindset interventions on academic achievement. The overall effects for both were weak, but some results supported specific tenets of the theory, namely, that students with low socioeconomic status or who are academically at risk might benefit from mindset interventions.


Not providing equal access to lessons and exercises is about as demotivating as it gets. This is often inadvertent: for example, my old online programming lessons presented the full script of the narration beside the slides—but none of the Python source code. Someone using a screen reader would therefore be able to hear what was being said about the program, but wouldn’t know what the program actually was.

It isn’t always possible to accommodate everyone’s needs, but it is possible to get a good working structure in place without any specific knowledge of what specific disabilities people might have. Having at least some accommodations prepared in advance also makes it clear that hosts and instructors care enough to have thought about problems in advance, and that any additional concerns are likely to be addressed.

It Helps Everyone

Curb cuts (the small sloped ramps joining a sidewalk to the street) were originally created to make it easier for the physically disabled to move around, but proved to be equally helpful to people with strollers and grocery carts. Similarly, steps taken to make lessons more accessible to people with various disabilities also help everyone else. Proper captioning of images, for example, doesn’t just give screen readers something to say: it also makes the images more findable by exposing their content to search engines.

The first and most important step in making lessons accessible is to involve people with disabilities in decision-making: the slogan nihil de nobis, sine nobis (literally, “nothing for us without us”) predates accessibility rights, but is always the right place to start. A few specific recommendations are:

Find out what you need to do.

The W3C Accessibility Initiative’s checklist for presentations is a good starting point focused primarily on assisting the visually impaired, while Liz Henry’s blog post about accessibility at conferences has a good checklist for people with mobility issues, and this interview with Chad Taylor is a good introduction to issues faced by the hearing impaired.

Know how well you’re doing.

For example, sites like WebAIM allow you to check how accessible your online materials are to visually impaired users.

Don’t do everything at once.

We don’t ask learners in our workshops to adopt all our best practices or tools in one go, but instead to work things in gradually at whatever rate they can manage. Similarly, try to build in accessibility habits when preparing for workshops by adding something new each time.

Do the easy things first.

There are plenty of ways to make workshops more accessible that are both easy and don’t create extra cognitive load for anyone: font choices, general text size, checking in advance that your room is accessible via an elevator or ramp, etc.

[Coom2012,Burg2015] are good guides to visual design for accessibility. Their recommendations include:

Format documents with actual headings and other landmarks,

rather than just changing font sizes and styles.

Avoid using color alone to convey meaning in text or graphics:

use color plus cross-hatching or colors that are noticeably different in grayscale.

Remove all unnecessary elements

rather than just making them invisible, because screen readers will still often say them aloud.

Allow self-pacing and repetition

for people with reading or hearing issues.

Include narration of on-screen action

in videos.


In 2003, Christine Miserandino started using spoons as a way to explain what it’s like to live with chronic illness. Healthy people start each day with an unlimited supply of spoons, but people with lupus or other debilitating conditions only have a few, and everything they do costs them one. Getting out of bed? That’s a spoon. Making a meal? That’s another spoon, and pretty soon, you’ve run out.

You cannot simply just throw clothes on when you are sick If my hands hurt that day buttons are out of the question. If I have bruises that day, I need to wear long sleeves, and if I have a fever I need a sweater to stay warm and so on. If my hair is falling out I need to spend more time to look presentable, and then you need to factor in another 5 minutes for feeling badly that it took you 2 hours to do all this.

Spoons are often invisible, but as Elizabeth Patitsas has argued, they are an important form of capital, and the more you have, the more you can accumulate (or exchange for economic, social, or cultural capital). When you are designing classes and exercises, try to take into account the fact that some of your learners may have physical or mental challenges that aren’t obvious, and do what you can to make your workload accessible to them.

Conduct Revisited

We said in Sections [s:intro-code-of-conduct] and [s:classroom-enforce] that classes should enforce a Code of Conduct like the one in Appendix B. In a sense, this is a form of accessibility: while closed captions make video accessible to people with hearing disabilities, a Code of Conduct makes lessons accessible to people who would otherwise be marginalized.

As discussed in Section 9.1, the details of the Code of Conduct are important, but the most important thing about it is that it exists and is enforced. Knowing that there are rules tells people a great deal about your values and about what kind of learning experience they can expect.

Group Signup

One way to support learners from marginalized groups is to have people sign up for workshops in groups rather than individually. That way, everyone in the room will know in advance that they will be with at least a few people they trust, which increases the chances of them actually coming. It also helps after the workshop: if people come with their friends or colleagues, they can work together to use what they’ve learned.


Inclusivity is a policy of including people who might otherwise be excluded or marginalized. In computing, it means making a positive effort to be more welcoming to women, people of color, people with various sexual orientations, the elderly, the physically challenged, the formerly incarcerated, the economically disadvantaged, and everyone else who doesn’t fit Silicon Valley’s white/Asian male demographic. Lee’s paper “What can I do today to create a more inclusive community in CS?” [Lee2017] is a brief, practical guide to doing that with references to the research literature. These help learners who belong to one or more marginalized or excluded groups, but help motivate everyone else as well; while they are phrased in terms of term-long courses, many can be applied in our workshops:

Ask learners to email you before the workshop

to explain how they believe the training could help them achieve their goals.

Review your notes

to make sure they are free from gendered pronouns, include culturally diverse names, etc.

Emphasize that what matters is the rate at which they are learning,

not the advantages or disadvantages they had when they started.

Encourage pair programming.
Actively mitigate behavior that some learners may find intimidating,

e.g., use of jargon or “questions” that are actually asked to display knowledge.

At a higher level, committing to inclusive teaching may mean fundamentally rethinking content. This is a lot of work, but the rewards can be significant. For example, [DiSa2014a] found that 65% of male African-American participants in a game testing program went on to study computing, in part because the gaming aspect of the program was something their peers respected.

Work like this has to be done carefully. [Lach2018] explored two strategies to bridge computing and African-American cultural capital in computing education. Community representation enrolls cultural capital to highlight students’ social identities, histories, and community networks. This can take the form of after-school mentors or role models who support computer literacies and are from students’ neighborhoods, or of activities that use community narratives and histories as a foundation for a computing project. situates computing in culturally situated practices and local sources of wealth generation; examples include “heritage algorithms” that allow indigenous and vernacular designs to be reverse engineered in a visual programming environment or the use of remix practices from hip-hop culture on websites where users post and share their computational artifacts.

The major risks of these approaches are shallowness (for community representation), e.g., using computers to build slideshows rather than do any real computing, and cultural appropriation (for computational integration), e.g., using practices without acknowledging origins. When in doubt, ask your learners and members of their community what they think you ought to do and give them control over content and direction. We return to this in Chapter 13.

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, but as Benjamin Doxtdator has pointed out, 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.

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.


Authentic Tasks (pairs/15 minutes)

Think about something you did this week that uses one or more of the skills you teach, (e.g., wrote a function, bulk downloaded data, did some stats in R, forked a repo) and explain how you would use it (or a simplified version of it) as an exercise or example in class.

  1. Pair up with your neighbor and decide where this exercise fits on a 2 × 2 grid of “short/long time to master” and “low/high usefulness”.
  2. Write the task and where it fits on the grid.
  3. Discuss how these relate back to the “teach most immediately useful first” approach.

Core Needs (whole class/10 minutes)

Paloma Medina identifies six core needs for people at work: belonging, improvement (i.e., making progress), choice, equality, predictability, and significance. After reading her description of these, order them from most to least significant for you personally, then compare rankings with your class using 6 points for most important, 5 for next, and so on down to 1 for least important. How do you think your rankings compare with those of your learners?

Implement One Strategy for Inclusivity (individual/5 minutes)

Pick one activity or change in practice from [Lee2017] that you would like to work on. Put a reminder in your calendar three months in the future to self-check whether you have done something about it.

Brainstorming Motivational Strategies (think-pair-share/20 minutes)

  1. Think back to a programming course (or any other) that you took in the past, and identify one thing the instructor did that demotivated you, and describe what could have been done afterward to correct the situation.
  2. Pair up with your neighbor and discuss your stories, then add your comments to the shared notes.
  3. Review the comments in the shared notes as a group. Rather than read them all out loud, highlight and discuss a few of the things that could have been done differently. This will give everyone some confidence in how to handle these situations in the future.

Demotivational Experiences (think-pair-share/15 minutes)

Think back to a time when you demotivated a student (or when you were demotivated as a student). Pair up with your neighbor and discuss what you could have done differently in the situation, and then share the story and what could have been done in the group notes.

Walk the Route (whole class/15 minutes)

Find the nearest public transportation drop-off point to your building and walk from there to your office and then to the nearest washroom, making notes about things you think would be difficult for someone with mobility issues. Now borrow a wheelchair and repeat the journey. How complete was your list of challenges? And did you notice that the first sentence in this challenge assumed you could actually walk?

Who Decides? (whole class/15 minutes)

In [Litt2004], Kenneth Wesson wrote, “If poor inner-city children consistently outscored children from wealthy suburban homes on standardized tests, is anyone naive enough to believe that we would still insist on using these tests as indicators of success?” Read this article by Cameron Cottrill, and then describe an example from your own experience of “objective” assessments that reinforced the status quo.

Credibility (individual/15 minutes)

[Fink2013] describes three things that make teachers credible in their learners’ eyes:


, or knowledge of the subject, as shown by the ability to explain complex ideas or reference the work of others.


, or having the student’s best interests in mind. This can be shown by giving individualized feedback, offering a rational explanation for grading decisions, and treating all students the same.


, or excitement about the subject (Chapter 8).

Describe one thing you do when teaching that fits into each category, and then describe one thing you don’t do but should for each category as well.

Common Stereotypes (pairs/10 minutes)

You will (still) sometimes hear people say, “It’s so simple that even your grandmother could use it.” In pairs, list two or three other phrases that reinforce stereotypes about computing.

Gender-Neutral Writing (pairs/10 minutes)

This short article by Jean Hollis Weber presents half a dozen tips for making technical writing gender neutral. Take a lesson you have recently taught or been taught, go through it with a partner, and see how many small changes you would make to conform to these rules.

Saving Face (individual/10 minutes)

Are there any aspects of what you want to teach that members of your hoped-for audience might be embarrassed to admit to not knowing already? Are there any that they would rather their peers didn’t know they were learning? If so, what can you do to help them save face?

Why Learn to Program? (individual/20 minutes)

[Scaf2017] found that people who aren’t software developers but who still program make higher wages than comparable workers who do not. With this in mind, re-read Guzdial’s list of reasons to learn to program in Section 10.7, then draw a 3 × 3 grid whose X and Y 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 your learners (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?

After the Fact (whole class/15 minutes)

[Cutt2017] surveyed adult computer users about their childhood activities and found that the strongest correlation between confidence and computer use were based on reading on one’s own and playing with construction toys with no moving parts (like Lego). Spend a few minutes searching online for ideas programmers have about how to tell if someone is going to be a good coder, or what non-coding activities correlate with programming ability, and see if these two ever come up.

Counting Failures (pairs/15 minutes)

Any useful estimate of how long something takes to master must take into account how frequent failures are and how much time is lost to them. For example, editing text files seems like a simple task, but what about finding those files? Most GUI editors save things to the user’s desktop or home directory; if the files used in a course are stored somewhere else, a substantial fraction won’t be able to navigate to the right directory without help. (If this seems like a small problem to you, please revisit the discussion of expert blind spot in Chapter 3.)

Working with a partner, make a list of “simple” things you have seen gone wrong in classes you have taught or taken. How often do they come up? How long do they take learners to fix on their own, or with help? How much time do you currently budget in class to deal with them?

Tracing the Cycle (small groups/15 minutes)

[Coco2018] traces a depressingly common pattern in which good intentions are undermined by an organization’s leadership being unwilling to actually change. Working in groups of 4–6, write brief emails that you imagine each of the parties involved would send to the other at each stage in this cycle.

Inclusivity Strategies (small groups/15 minutes)

[Tann2013] enumerates twenty-one teaching strategies to promote student engagement and cultivate inclusivity in classes:

  • Give learners opportunities to think and talk about the subject.
    1. Wait a few seconds after asking a question before selecting someone to answer it.
    2. Allow learners time to write.
    3. Use think-pair-share (Section 9.10).
    4. Do not try to do too much.
  • Encourage, demand, and actively manage the participation of all learners.
    1. Hand raising.
    2. Multiple hands, multiple voices.
    3. Call on learners randomly.
    4. Assign reporters for small groups.
    5. Whip around.
    6. Monitor learner participation.
  • Build an inclusive and fair community.
    1. Learn or have access to learners’ names.
    2. Integrate culturally diverse and relevant examples.
    3. Work in stations or small groups.
    4. Use varied active-learning strategies.
    5. Be explicit about promoting access and equity for all learners.
  • Cultivate divergent thinking.
    1. Ask open-ended questions.
    2. Do not judge responses.
    3. Use praise with caution.
    4. Establish classroom community norms.
  • Teach all of the learners in your classroom.
    1. Teach them from the moment they arrive.
    2. Collect assessment evidence from every learner, every class.

Working in small groups, collect examples of specific cases in which you have seen these recommendations violated. Are there cases where the members of your group disagree on whether a rule was broken or not?