Reading Time: 11 minutes

Hi. I’m Chelsea Troy. I’m a computer science educator at the University of Chicago.

You can see all my posts about teaching by visiting the teaching category right here. You’ll find pieces about designing a syllabus, choosing topics to cover in a session, and selecting session activities.

Back in this post, I listed some resources that helped me become a better instructor. Among them:

I…perused a few books that specifically covered how to teach. One of those books fundamentally changed my approach in the classroom: Chris Emdin’s book, For White Folks Who Teach in the Hood. I’ll do a more detailed post later on the value that this book brought to my teaching. For now, I’ll say that I recommend giving this book a read regardless of who you are or who you teach.

Let’s do that more detailed post now, shall we?

In this book, Dr. Emdin speaks specifically to the experiences of black youth whose white teachers don’t understand their lives.

Let’s address the elephant in the room: I teach in a graduate computer science program at an elite university. In order to end up in my class at all, every single student has had to successfully navigate white-centric academic paradigms for close to two decades. I don’t fancy myself a white person who teaches in the hood. Nevertheless, the time to unlearn racist ideologies is always.

But also—and this is a critical point—the changes I made as a result of reading this book shaped me into a better steward of learning for almost any audience. The only folks who prefer my old teaching style to my new teaching style are the folks who would have learned this material on their own in the absence of having a class at all.

I recently found myself in conversation with some other members of the MPCS faculty about the specific changes that Emdin’s work has prompted in my class. So, let’s talk about what those changes were.

Small things that changed after I read this book:

 1. Use of Music: Instead of having students participate in discussions, do independent lab work, or take breaks in awkward silence, I play background music. This one, I should mention, applies chiefly to in-person classes, because I have discovered that Zoom and other video chat services throttle participants’ audio for performance reasons in ways that prevent smooth, continuous background music from my computer.

 2. Breaks: I have separate times and activities for students to take breaks and for me to take breaks. Students receive two breaks during our three-hour session to eat, get coffee, relax, and chat. I stay accessible to students during their down time for questions, and I take my down time while they are engaged with one another in small group discussions, or while they are taking time on a challenging programming problem that we’ll review together afterward. This approach affords me down time to preserve my engagement capacity.

 3. Explicit Leniency Policies: I don’t give extensions or extra points when students e-mail me to ask about them. I know that this leeway often only exists for students who were raised and socialized to see teachers as peers and ask them for things they didn’t initially grant. So granting this leeway puts students who were raised to see teachers as authority figures at a disadvantage (and—you guessed it—there are strong demographic trends here.)

Instead, I tell students in the very first lecture that they have two late days available to take whenever they want to, on any assignment, without having to justify it to me. I also tell them that they will not get a third late day, under any circumstances, no matter the pressure they exert.

Here’s an important caveat: every single quarter, a student tests this—usually at the very end when they didn’t turn in some major assignments and don’t like their final grade. Sometimes they’ll go so far as to get a collection of advisers and administrators involved, or try to play advisers, my assistant, and myself against each other. I had to learn how to thwart this, unfortunately. Here’s how I do it:

1. Any student requests related to course modifications or grades, I forward straight to the program director. I also ask my assistant to forward such requests straight to either me or the program director. This prevents playage.
2. In most cases, I can tell within the first half of the class which students might test the leniency policy. They take late days on early/easier assignments, or receive low grades on homework, and they don’t attend office hours. They also don’t respond when I email them to ask if they have conflicts with the office hours times and offer to work around that for them.
3. Once I’ve identified this student, I immediately notify the program director. I explain that I could be wrong, and that I hope I am wrong, but this student is having an issue and isn’t responding to my offers of support, and I’m worried about them.
4. Then, I keep notes for this student on whether they have attended any office hours, and any email communications we’ve had. I hate this step. But if the student convinces his advisor to convince somebody with a lot of power to call me and ask for leniency for the student, I then have evidence that we tried to help the student several times.

For the record, I have never needed to deploy this plan for a student who was genuinely struggling but wanted to learn the material. I have only needed it to help me enforce my boundaries when a student  felt entitled to opportunities for leniency that his classmates did not get.

Big things that I changed after I read this book:

 1. I take time to consider what the students can bring to the classroom, that I cannot. In any classroom, that includes their unique interests and lived experiences. Rather than think of the class as a monolithic product that all students should experience the same way, I allowed students to fill unique roles in class for themselves, for classmates, and for me. For example, I had two auditing students. If folks asked me questions about professional stuff, I’d give them a chance to answer it too. I had one student who came from a product management background. I asked for her help writing requirements for a homework assignment. I had one student who liked to do work early. So I posted all notes early and made everything very discoverable so she could access all course materials before session began. Because of this, she ended up being my “sentry” and pointing out things about the homework instructions that might cause confusion for students such that I was able to change them before any other students laid eyes on them.

 2. I try to provide context for the material that I am teaching. Why is this API the way it is? What conflicts, decisions, and personalities shaped it to be like this? Do we see that in other parts of the API as well? Where are the inconsistencies, and why might they be that way? We can further investigate these questions together as a group—even (especially!) when I don’t know the answer.

 3. I collect regular feedback from students: not vague feedback on me as a teacher or the class as a whole, but specific feedback on the activities that we have tried in the classroom. This gives students an opportunity to participate in deciding how we structure our sessions.

4. Rather than deliver material/proctor activities either this way or that way, I try to offer students choices that allow them to get the material in the way most conducive to their learning style. For example, this quarter, we did some exercises in class, and I gave students the option to do them alone or in pairs, and if the students wanted a pair, I’d assign them to someone else who also wanted a pair. (edited)

 5. Perhaps most importantly: instead of focusing on how the fastest students are going to experience my class, I focus my efforts on how the slowest students will experience my class—not slow as a stand-in for “not that smart,” but slow as in literally most materials are not well-designed for them in the first place.

This one is tricky to operationalize, because there are so many ways for material to be disconnected from its intended beneficiaries. A good set of considerations here for me focuses on common disabilities, learning differences, and predictors of executive function rather than cultural factors. Those considerations me to design assignments and materials that maximize skill transfer while minimizing friction related to the medium.

Some examples (not exhaustive, I am not a doctor, these are just examples, refer to item 3 and ask your students what is going to work for them and what they need):

• What if they’re low vision?
  • This means that I should be stating button descriptions as I use the IDE, because that is how an engineer who uses a screen reader would access the button. I also read the line numbers and code aloud that I am modifying.
• What if they’re hard of hearing?
  • All of my videos have captions, and I get a live captioner for classes and office hours sessions when I have students with disability accommodations.
• What if they have dyslexia?
  • I always offer more time in class to complete video tutorials than the time of the actual video tutorial. I also back-calculate from how long I want things to take to the appropriate average so a dyslexic student would fall under the cap. For example, if I want an assignment to take no more than 10 hours, I plan it so it will take most people around 6 hours.
• What if they have symptoms of anxiety?
  • Folks who catastrophize benefit from having as much info as possible, as early as possible, and they benefit from being able to review the same information multiple times. I distribute lecture notes before class, pre-record programming demonstrations, and record lectures as much as I can.
• What if they have symptoms of depression?
  • Depression can affect a person’s executive function—moreso when tasks are not well-defined. So I try to be specific in my homework descriptions and remove ambiguity about what I’m expecting.
• What if they have symptoms of OCD?
  • Students who are prone to feeling all the time like they missed something, or messed something up, also benefit from specific instructions and having notes and lectures available for review.
• What if they have symptoms of ADHD?
  • Students with ADHD may take longer to complete assignments, or they may struggle without focus music to occupy their mental background thread. In addition, adult ADHD is often characterized by rejection-sensitive dysphoria (RSD), which can affect their willingness to ask questions that they think will be perceived as “stupid.” Having an asynchronous means by which to ask questions can really help these students, since asynchronous communication allows them to manage when they are ready to read the response (yes, this can affect them even after I have established myself as a “safe” person to ask questions).

A note on this: there’s always a student or so who feels my class was too easy as a result. So far, this student has never been someone who “needed” my help to learn this material in the first place. This is an acceptable loss to me for students who need these accommodations.

The Big Surprise

I thought that these changes would chiefly improve the experience for BIPOC students and it would be the same, or slightly worse, for white students. Instead, these changes improved the experience for almost every student regardless of race.

Why did this happen? Well, the issue wasn’t solely, as I figured at the time, that academia favored white peoples’ customs and experiences (though this is the case).

It’s also the case that those customs and experiences produce drag in the learning environment for…well, almost everyone, with an exception here or there. Most people benefit from a learning environment that rethinks a lot of our defaults.

This happens to also be the case in professional environments, by the way. If you’re interested in learning more about this, you might appreciate the ongoing series about how white supremacy culture shows up in tech and professional culture, and how that impacts our experience at work.

If you liked this piece, you might also like:

The aforementioned white supremacy culture series

The debugging posts (a toolkit to help you respond to problems in software)

The Listening Series (Prepare to question much of what you know about how to be good at your job.)