We have a pandemic, a reckoning about police brutality, late-stage capitalism, and more.
And consecutively, I'm supposed to be teaching a class about mobile software development.
I wanna talk for a second about why and how I address tough topics like these in the classroom.
1/
So first, why talk about tough stuff in the classroom?
1. These things affect my students lives and, therefore, ability to learn. Acknowledging the events makes it easier for students to come to me with questions and concerns related to their studies.
2/
2. I look like a tool if I teach 20 min after the Derek Chauvin trial concludes and I act like nothing just happened.
Computer scientists already have a reputation for living in their own little nerd world. I don't wanna feed that beast.
3/
3. When I acknowledge events students have heard of, it raises my credibility for talking about important events they haven't heard of.
Programmers pass around a lot of inaccurate rumors about how tech got the way it is. I need credibility to debunk that stuff.
4/
4. Finally, apropos of 2 and 3, programmers living in their pet headspace divorced from broader social concerns has to change.
We have too much leverage for that. We impact modern society too much to be responsible craftspeople without also being students of that society.
5/
So how do I address tough stuff in the classroom? I won't claim expertise here, but I'll tell you.
There are a couple of different scenarios here.
6/
1. For acute events that impact my students' ability to pay attention (individual police brutality videos/trials, for example),
I acknowledge this at the start of class and ask people to hold space for themselves and their classmates.
This happens at least once a quarter.
7/
"Chelsea, holding space like that AT LEAST once a quarter sounds like way too often"
Look, I dunno what to tell you. Gimme a world where rage and grief isn't pulling my students out of their studies this much and I'll acknowledge it less often.
Other scenarios:
8/
2. For systemic events that impact my students' ability to pay attention (ongoing pandemic or the upward rush of capital from the working class to billionaires, for example),
We'll talk in class about tech's role in either causing the issue or responding to the issue.
9/
For those two specific topics, we might address, for example:
Contact Tracing: who is building it, whether it should make money, how it gets funded if it shouldn't, how to protect people's privacy while doing it
And the other example...
Rush of Capital: what does it mean to "disrupt" something? What activities get "disrupted" by tech, and which ones don't? Why doesn't, say, community care and mutual aid get "disrupted" the way, say, paid car services do? Who does "disruption" benefit?
11/
The idea that systemic factors impact whether and how these solutions get built is often new to my students.
I see the application of systems thinking to social issues as one of the primary ways I get to seed a better future for tech.
12/
3. I address current events in the context of discussing ongoing questions for engineers like:
"How do we make sure that our code doesn't break?"
"How do we make sure that our code doesn't contribute to harm?"
13/
Conveniently (yikes), there's always enough happening that I gotta change out the examples every quarter for something recent that happened.
But the underlying skills to address these questions stay the same. We do activities in class for building those skills.
14/
Through these means, students get (I hope) an explicit invitation to participate in history, rather than just observe it.
They get a chance to see that what they do matters.
15/
And in fact, believe it or not, I think a lot of these things I've learned from teaching have applications in industry as well.
For example, take this piece. It's about management and the workplace, and it echoes some of what we've discussed here.
Or this thread from a week or two ago, about evaluating students' work.
A lot of it also applies to job interviews. That's not even just my conclusion: it was the conclusion of several other engineers and managers who read the thread.
In the same way that it's important to bring the broader world, and the broader tech industry in my case, into the classroom, I think we can bring lessons from the classroom back to the field and to the broader world.
18/18
• • •
Missing some Tweet in this thread? You can try to
force a refresh
I have been watching several online lectures and lecture playlists from different instructors lately.
I'm starting to have some aggregate thoughts about what makes a lecture work—or, more specifically, NOT work.
1/
Before I begin, two things
1. I'm a graduate school instructor. I have given lectures. I'm not the peanut gallery.
2. My sample is "Lectures that got to YouTube," so their quality probably outstrips the average.
In particular...
2/
I have seen very few cases where the instructor didn't prepare or didn't care.
So this thread is really "What can STILL make a lecture not work, even if the instructor cared about the quality of instruction and prepared for class."
3/
This evening in Chicago, I watch one moneyed/powerful institution after another sound alarms about Possible Protests.
That's what upsets them; not graphic evidence that Chicago Police murder innocent people with impunity.
What is the purpose of protest, here, now?
1/
Under the right circumstances, protests drive change. In 2020, multiple city administrations moved to divert funds from policing to community support, and Colorado became the first state to end qualified immunity since its introduction.
But Chicago's circumstances...
2/
I mean, let's start here: the mayor is a cop.
She has presided over, at this point, MULTIPLE high-profile cases of police misconduct attempted coverups.
To be clear, engineers have a lot of power and share blame for a lot of stuff.
But also, engineering suffers a bit from the goalie problem, and it ends up negatively impacting orgs' opportunities to fix things. 1/
The Goalie Problem:
Any time the opponent scores, what's immediately obvious is whatever the goalie did wrong.
But the most fruitful answers to "how can we not let this happen again" often have to do with how that ball got into the goalie territory in the first place.
2/
Here's a common one: some kind of joke about "Engineers write bad error messages."
'kay, well, sure, hardy harr, but that's what happens when you don't give eng the time or access to ask questions and then and hire a designer who doesn't design failure cases.
3/
@freakboy3742 So, I feel like an ass explaining this to a Django maintainer. This guy's gotta know 3x as much as I do—including why it's controversial.
The REPLIES, however, are getting kinda sarcastic and mean and poorly informed. So I'm'a explain, in good faith, why it's controversial. 1/
@freakboy3742 Before I begin, who the hell am I: I write Python that powers article recs on Firefox and NASA LandSat satellite data-to-image processing. I teach Python to CS grad students by having them replicate features of pytest, pandas, and memcached.
The reasons it's controversial:
2/
@freakboy3742 1. The first thing to understand about any language/framework is that computers are entirely manmade, and so therefore CS doesn't have "natural laws" like physics does.
CS's "laws of physics" are the perspectives of the humans who wrote whatever the thing is we're writing in. 3/
Tonight I gave the last lecture of the third run of my class, Mobile Software Development.
The final recording is uploaded and the independent survey is done, as is the survey review with the course staff. We have our list of things to revisit for next time.
My TA said...1/
"People liked it! No surprise."
Which is kind of her, but a year ago, we had NO idea if people would like this.
I wanted a class that capitalized on students' position relative to the mobile stack to teach them skills that they would need in a practitioner or research role. 2/
That required teaching...risk analysis, automated testing, version control, IDE key bindings, ethical considerations, data privacy, feedback techniques, and the gravity of our jobs.
Ah—and at least two programming languages and two frameworks. 3/