Follow us on Twitter at http://twitter.com/blogCACM
The Communications Web site, http://cacm.acm.org,
features more than a dozen bloggers in the BLOG@CACM
community. In each issue of Communications, we’ll publish
selected posts or excerpts.
DOI: 10.1145/2716345 http://cacm.acm.org/blogs/blog-cacm
1. The most important thing is tone
and attitude when answering questions. Many of us in CS (I include myself in this) have to fight against lapsing
into a very patronizing tone. It is easy to
slip into the “I cannot believe you don’t
understand that” tone of voice, or say
things like “it is so obvious.” Every time
we use that tone of voice, or those sorts
of phrases, we send the “if you don’t
get it already, you shouldn’t be here”
message. While this is likely more of a
problem in lower-level courses, it can
happen in upper-level courses as well.
An interesting exercise for TAs and lab
assistants would be to sit down and
collect a list of the sorts of things they
have heard over the years (or even said)
and then actually say those things in a
patronizing tone of voice. That should
serve as a good reminder of what it
sounds like, hopefully making it easier
to avoid talking to students in that tone.
2. If students are working in teams,
keep an eye out/ear out for problematic
dynamics amongst the team members.
Suggest to teams ways of rotating re-
sponsibilities so that everyone has the
opportunity to play a leadership role.
3. The electronic submission deadline for homework should be set so
that it does not encourage macho behavior. Have homework due no later
than 11:00 P.M. or midnight. The problem with a 6:00 A.M. or 9:00 A.M. deadline is that it encourages very macho “I
stayed up all night, I’m hardcore, I’m a
*real* programmer” behavior. People
who do not handle their work that way
are seen as not being a true hacker, as
not having real “programming chops,”
even if the person who did not stay up
was incredibly organized, completely
solved the homework problems, and
turned in the assignment hours early!
4. It is fine to suggest the use of
Github or others, but understand that
not everyone wants to put their work out
in the world in that way. If it is required
of all students, fine, but do not encourage the use of public repositories as a
way of measuring people’s abilities. I
am always distressed when I hear that
employers are grouping résumés based
on what they find in code repositories—
this automatically knocks out of the
running anyone who does not choose
to display their work in that way, and
we know that women tend not to use repositories as much because of the level
of attack they experience in that world.
5. Periodically look over the grades
as a group and see if any implicit bias
is in evidence. Are grade distributions
roughly the same across all groups of
students? Check in about who is com-
Valerie Barr
“Some Thoughts For
Computer Science
Teaching Assistants
(and Faculty)”
http://bit.ly/1yBDMbb
January 4, 2015
I was recently contacted by a student
who will be working as a teaching as-
sistant for an upper-level CS course. He
remembered that, during a visit to his
campus, I had said that the way cours-
es are taught is just as, if not more,
important than the race, gender, eth-
nic background of the instructor. His
question was whether I had any advice
for him and his fellow TAs about how
they could “conduct ourselves or talk
about the course material in order to
help foster as inclusive and welcoming
an environment as possible.”
Here is the advice I gave, which I
think can be helpful for faculty as well
as for TAs, lab assistants, student help
desk workers, and others.
Advice on Teaching CS,
and the Learnability
of Programming
Languages
Valerie Barr considers how attitude can impact teacher effectiveness,
while Mark Guzdial suggests the ultimate focus in teaching
programming languages should be on usability.