come from the teacher or teaching
assistant. Pair programming also has
some significant positive impacts on
diversity. There were so many links
that I could have put in this tweet,
and I struggled to decide which one
to put in. The ETR link I included
is a great overview. If you want a detailed explanation of how to do pair
programming in the classroom, I
highly recommend the NCWIT Pair
Programming in a Box resources (at
Pair Programming doesn’t always
work. Pairs can go awry. But do the
cost-benefit analysis. What percentage
of pairs are ineffective, vs. how much
time is wasted with students waiting in
queues for office hours and what percentage of office hour 1: 1 time is ineffective? In the long run, pair programming is a bigger win.
3. Backward Design. Look at your
assignments. Did you teach everything
needed to do them? No, it doesn’t
help learning to have students “fig-
ure it out on their own.” That’s what
leads to long lines. If you didn’t teach
it, don’t require it in the assignment.
In CS, there is a pervasive attitude
summarized in four letters: RTFM (read
a great post about those four letters at
http://bit.ly/2KsgkZ6). We tend to be-
lieve students should learn to figure
things out on their own and seek out
resources to guide them. The problem
is that it’s really inefficient and encour-
ages long lines at office hours. Students
would rather wait hours for a specific
answer than spend hours (maybe more,
maybe less) for the chance at an answer.
Here’s the point of the tweet in an
even shorter form: If you didn’t teach
something, don’t require students to
use it in an assignment.
Seriously. Direct instruction beats out
students wandering around through resources trying to find an answer (see my
post from last November making that
same point at http://bit.ly/2ARuUTA).
There is no learning benefit for making
students figure it out on their own.
4.Change classroom climate.
CS classes tend to have a defen-
sive climate: critical, impersonal,
with informal student hierarchies.
That discourages diversity, and
discourages coming to lectures.
This last semester, I taught my
first CS Education Research class at
the University of Michigan (http://bit.
ly/31avw2Y). A significant percentage
of my students did their research work
around the idea of “Defensive Cli-
mate.” Computer science classes tend
to have a defensive climate; that is, the
class is impersonal, unfriendly, often
critical or combative, and there are
informal student hierarchies (for ex-
ample, the students with lots of experi-
ence ask questions that other students
don’t even understand). We need to
teach in a way that discourages defen-
sive climate (see NCWIT article on that
at http://bit.ly/2Xp8X8w). If we taught
in a way that was more inclusive and
welcoming, it might lead to students
coming to lectures, engaging, and
learning more—and they might need
less 1: 1 teaching in office hours.
Please don’t use grade caps to limit
enrollment. I make that argument at
http://bit.ly/2Z4RaUx. You will very
likely reduce your diversity if you do. If
you have to limit enrollment, make it a
lottery so that both privileged and underprivileged students have a fair shot
at getting in.
5. Be explicit in your expecta-
tions that every student can learn
CS. Many CS instructors believe that
some students “got it” and other
students can’t. There’s no evidence
that’s true, but we teach and de-
sign our classes that way. Teach to
the bottom third of the distribution.
I have written a lot about the Geek
Gene ( http://bit.ly/2IhP5xL), the belief
that some students have innate abil-
ity and others do not. It’s a pervasive
belief in CS education. If you believe
that only some students are going to
succeed, you will likely teach for their
success. You will teach to the top few
percent of the class. If you explicitly
expect that everyone can succeed (that
is, saying in class “You can all pass this
class”), and you teach to those students
who have less preparation but can suc-
ceed, then they will succeed, and fewer
students will be waiting in the hallway
for hours to get help.
Mark Guzdial is a professor in the Computer Science &
Engineering Division of the University of Michigan involved
in the Engineering Education and Research program.
© 2019 ACM 0001-0782/19/8 $15.00
For further information
or to submit your
Research and Practice
(DGOV) is an
journal on the
potential and impact
innovations and its
public institutions. It
promotes applied and
and data sciences
Research and Practice