A guide to student activism in computing education
Over the past few years, I’ve written and spoken extensively about the need for more critical perspectives in to computing education, to balance out the more utopian, solutionist rhetoric in computing. I wrote a book, I gave talks about programming + politics, requirements and oppression, structural inequities, CS culture, and my lab’s research. And I’ve published a lot with my students, investigating belonging, exclusion, identity, critical pedagogy and more. And throughout, I’ve learned an incredible amount about how to think about computing education critically. I’ve also found others working towards the same or similar vision of a computing that acknowledges and shares its power, ethically, responsibly, and equitably.
While I learned a lot about how CS faculty respond to this vision (some skeptically, some hesitantly, some enthusiastically), what was most striking was how uniformly students expressed support, but also how powerless they felt. Hundreds wrote me, feeling oppressed and isolated in their CS department, asking what they could do with their limited power to make change. As I replied to each of these emails, I realized how little I knew about how to advise students on how to advocate, organize, and demand change. And so I read and learned and started finding better answers. I also reflected on my own position as an academic leader responding to demands for change, and on how my academic leader peers have responded for change. I tried to focus on the kind of advocacy that I felt would be effective for pressuring me and my peers to take action as a leader.
Eventually, I felt like my advice was good enough — albeit amateur — that it was worth sharing more broadly. So I wrote this guide for student advocacy in computing education. It’s a collection of activities that might help you, a student in higher education computing unit, work toward more equitable and just computing education locally, regionally, or nationally. I’ve roughly ordered from easiest to hardest (which roughly correlates to least to most effective). It’s primarily meant for post-secondary students in democratic countries, but some of the advice probably works well for high school and graduate students as well, and perhaps even for some students in non-democratic countries that have some tolerance for protest. And for those who have far more student-led advocacy practice than me, please send feedback and I’ll update this guide with better advice!
But first, one disclaimer: for centuries, people in democracies have developed many strategies and tactics for social change. This guide couldn’t possibly capture all of that expertise, nor am I an expert on social change. You shouldn’t reinvent that expertise and neither should I! Fortunately, many experienced activists have organized their knowledge. For example, the Activist’s Handbook is a wonderful guide on the theory and practice of making change when you do not have the power to make it yourself. Read the entire thing and then find someone more experienced to learn from. This guide focuses on advice specific to computing education.
Read
We understand a lot about the problems with computing education. I maintain a reading list for people new to computing education research, and many of the works on the list specifically examine issues of diversity, equity, inclusion, belonging, and justice in computing education. These works are one way to understand the status quo with more depth and nuance, which is key to focusing your advocacy efforts on the root causes of problems, rather than superficial symptoms.
As you read, however, remember that reading research is going to give you an incomplete picture. Researchers haven’t studied every possible aspect of computing education and its ills, and in some cases, have systematically ignored certain kinds of exclusion. (For example, there is a severe lack of research on race, class, ability, and capitalism in computing, though this is slowly improving). So you may find that the specific problem you want to address in your university has no guidance. That might mean you have to do your own research about your local context.
Listen
If you are a student in a dominant group in computing — predominantly cisgender, heterosexual, non-disabled, white, Chinese, or Indian middle to upper class men — build on the knowledge you’ve gained by reading by listening to people in computing not in those dominant groups. Attend talks by students and faculty with marginalized identities; learn how to be an effective ally and follow the marginalized people in your community who are leading advocacy. No matter how smart you are, they almost certainly know better than you what’s broken about computing education because they see and suffer it every day.
And if you are in a marginalized group in computing, remember that you aren’t freed from listening. Even the most marginalized groups in computing have something to learn about the experiences of other marginalized groups. This learning is key to building a mutual respect and understanding of the typically common root causes of different groups’ oppression (e.g., class, nationalism, white supremacy). Movements by groups at the margins don’t move forward without becoming a bigger group built on mutual trust and respect.
None of this means you can’t have your own perspectives on issues. As you listen, develop perspectives and beliefs. But do so with humility, remembering that your beliefs can and should be easily discarded when someone’s experience provides counter-evidence. Social change often requires, paradoxically, an inexhaustible confidence to persist, but also an agility of perspective, to change how you see the structure of a problem as you encounter new perspectives and needs.
All of this can be exhausting. Give yourself the time to learn and grow and wrestle with internalized assumptions and ideas that drive your own behavior. Listening can be transformative, but only if you let things in and let them change you.
Connect
Never try to make change alone. It’s isolating, frustrating, and ultimately ineffective: when you don’t have power as individual, most of your power is in numbers. The Activist’s Handbook has an excellent section on community building.
Fortunately, in computing, many communities are already organized to some extent. Organizations like NCWIT and ACM-W, for example, have long organized around various kinds of gender exclusion (and CRA-WP for computing researchers in particular). And many NSF funded projects have organized around particular types of exclusion in CS; for example AccessComputing helps students with disabilities participate in computing education; the Computing Alliance for Hispanic Serving Institutions (CAHSI) focuses on Hispanic students across the United States, The Institute for African-American Mentoring in Computer Sciences (iAAMCS) focuses on Black students in computing. And Black in Computing brought together numerous Black scholars in computing to demand change.
These are by no means the only organizations, or the only ones necessary. Nor are they all perfect: building community is hard and often under-resourced (if at all), and many organizations that narrowly focus on broadening participation in computing do not challenge computing as it is, only focusing on helping students gain access to and survive computing cultures without changing them. It is almost certainly necessary for your to find more local organizations as well, using the more national communities above to get resources, guidance, and mentorship.
Organize
Community is great; trusting relationships are a central resource in social change, and they’re critical to maintain. But a community of relationships is not enough to make change. That requires organizing.
Organizing means having more than just relationships. It means having proposals, processes, plans, and possibly even resources in order to build capacity for action. Organized communities are ready to respond to crises, have a vision for how they’d like their local, regional, or national CS context to be, and actively work towards that vision. That means taking the time to form a vision, share it, build community around it, and take action to realize it.
Organization also requires leadership. That means reckoning with the tensions in who is trusted to hold power, how they earn it, and how they give it back when a community wants to be led in a different direction. Many computing communities organized for social change flounder when their leaders have been ineffective, or when their communities no longer trust them to make change. Take the time to cultivate and develop leadership in a community by sharing power. And if you never imagined being a leader yourself, but think you might have the skills for it, that might make you a good candidate to lead: especially in social change, leaders should be skeptical that they deserve power and eager to give it back, but capable of wielding it when needed.
Analyze
Before it’s possible to make meaningful change, it’s quite important to determine who actually has the power to make a change. Imagine, for example, that you wanted to demand change in a CS curriculum at a college. At any particular college or university, that might be decided by a number of different people: 1) the faculty, 2) a program director, 3) a curriculum framework, like the ACM Curriculum Recommendations, which many colleges and universities follow, 4) college-level curriculum committees, or all of these together. There might even be one particular powerful professor whose opinion on curriculum has great influence, even if they aren’t formally in charge. Find out who the people are that can actually make the change, talking to trusted people in your local community that know the power structures.
Power structures also change. Faculty retire and are appointed to new positions; chairs and deans come and go, especially in computing, where growth often leads to higher frequency turnover because of the abundance of opportunities in academia. Demanding change requires tracking these shifts in power, so you can be sure that you’re advocating to the right person in the right way. In my position as our undergraduate program chair, for example, I regularly receive advocacy from students for things I don’t control, like university or state policy. Because I want to amplify student voices, I usually let them know I’m the wrong person, and then decide whether I can relay the message to the right person, but it is often far more effective for students to speak directly to the person with the decision making power.
Sometimes students have more power than they think. In computing, this is often because faculty aren’t aware that they have power, and so often don’t use it when they could. In fact, I’ve found that many computing faculty have an extreme disinterest in power and are eager to give it up if a group demonstrates a desire to take it. And so in some cases, the more organized you are with other students, the more power you will have to demand change.
This is certainly not always true. Some faculty in computing have an extreme overconfidence in their beliefs and a strong resistance to ideas from others, especially students. If you think this is the kind of leader in your community, prepare for a bigger, longer battle.
Demand
An informed, connected, and organized community of computing students is in a strong position to make demands. The Activist Handbook has numerous strategies for making demands; many of them focus on destructive approaches like violence. In computing, these more extreme measures aren’t usually necessary for change. I’ve found most computing faculty to be highly conflict-avoidant, and so collective forms of written demands and peaceful civil disobedience are likely more than enough to effectively communicate demands.
Unfortunately, those alone aren’t enough to make change. As a professor and decision maker who is highly responsive to demands for change, it’s still hard for me to prioritize change over all of my other priorities in research, teaching, and service. There’s just so much work to do and all of it is important to someone! To get our attention, you have to create pressure, and pressure requires conflict, and conflict comes with risks. Here are some examples of how you might do that in a computing learning context.
Politely ask. Have your organized community send a well-considered request to the person with power. Maybe your leaders are reasonable, student-centered folks and will prioritize your needs. I’ve certainly encountered many academic computing leaders who are highly responsive to demands for change; I aspire to be one myself. And even if they can’t make the change, responsive leaders will hopefully transparently explain why they can’t and invite you to help problem solve within whatever constraints they surface, growing your coalition to include the leader. This comes with no tangible risk, avoids conflict, and in my opinion, is generally how change should always work: leaders solving problems for the community they support and becoming allies and resources for change.
Sometimes — maybe most of the time— asking doesn’t work and you do not find an ally in charge. In these cases, you might start by shaming. This strategy simply involves making the injustice you’re trying to correct visible to the broader community (maybe other faculty, students, and staff). This might mean writing in the student paper, or contacting local newspapers, or using social media. If you truly believe something is wrong, you’re likely to find others who agree, and this can create pressure for leaders to reexamine their position. This has low risk, but also may not be particularly effective, as the forces preventing change in computing can often be quite strong (e.g., lack of resources, state law).
If shaming doesn’t work, boycotts might. For example:
- Boycott learning. If you refuse to come to class, faculty will be forced to decide whether to respond to your demands or fail everyone that doesn’t attend (which actually can hurt the CS departments finances by reducing revenue or leading to graduation delays that reduce a department’s ability to admit more students.). There’s a risk here that you might actually face consequences in a course if the faculty are particularly unsympathetic (or that you might not learn something important).
- Boycott teaching. Many CS departments rely extensively on undergraduate teaching assistants and graders. If you refuse to do this work, the work falls on the faculty, and that’s the last thing they want. There’s a risk here that you might not get paid or you might get fired, though student unions can aid in mitigating this risk.
- Boycott registering. Is there a professor you are trying to protest? Organize a large group to refuse to register for their class. Most classes that don’t lead to a certain level of registration have to be canceled, and some classes are critical to graduation pathways must be taught in order for students to proceed toward graduation. This risks delaying graduation, but can result in leaders changing who is teaching a course.
These more passive forms of protest target the resources of an academic unit, which are one of the many forces that prevent change.
More active forms of protest might be effective. Computing faculty are not use to public protest. Sure, it happens on campus, but not usually about computing. Having a large group of students outside one’s office would be terrifying for most faculty and incredibly disruptive to their other work. I suspect many would gladly respond to demands in order to get an organized group of students to stop. This risks the loss of resources like letters of recommendation and student employment, but strength in numbers had distribute this risk to a negligible level.
If after all of that, nothing is working, more destructive forms of advocacy might be effective. For example, a community might sabotage learning infrastructure, disrupting computing education. For example, some students end up with significant control over learning technologies such as autograders or learning management systems in their role as teaching assistants or staff. Sabotage might involve planning disruption of learning technologies in a classroom until demands are met. This is obviously a much higher risk to the individual with these platform privileges, but again, coordinating such protest across many students reduces the risk to any one person.
It might seem strange for a senior full professor in an academic leadership position offering tips on how to destabilize their work. Or hypocritical — after all, if I believe that change is necessary, why don’t I just make it? The reality is that most academic leaders in computing don’t have the power to make change unilaterally: we have to convince our colleagues, our universities, sometimes our state and national governments, and sometimes the entirety of the computer science research and teaching community. One academic leader rarely has enough power to persuade so many. And so change in computing might actually need students to organize in order to empower leaders to make big changes possible.
Of course none of these strategies should be necessary, nor should any of the risks that come with them. Leaders should just do the right thing when you ask. None of these risks above should be necessary; I often feel extreme guilt that I don’t prioritize student needs, because I know they are important. But so many other things are important too, and it’s hard for me to set aside what I think is import for what students think is important. Collective action like those above are a way to make the significance of some demand salient, and help leaders reprioritize their many critical tasks to align with your community’s needs. It’s not fair that so much of the burden for making change should fall on the groups experiencing the most oppression.
In fact, one change I’ve contemplated is funneling resources to organize student groups to advocate to me and others. This might be an interesting place to start activism for students in computing: start by asking your leaders to fund student organizations (if you don’t have them already) that are charged with organizing for change, and then grow and sustain those organizations so that they have a greater capacity for demanding further change. Consider whether student chapters of the ACM are the right place for this — many are narrowly focused on skills or inclusion and not change—and start organizing.
If all of this sounds scary, I can confirm that it is. Advocacy still terrifies me. Writing this post terrifies me — I’m teaching students how to make demands of my colleagues, which is probably going to make me a very unpopular person! But what keeps me going is knowing that if I don’t advocate, the broader academic community and industry I care about most is going to continue to exclude trans folks like me, and countless other marginalized groups, producing a world that works really well for some, at the expense of others. That existential threat is far more terrifying that engaging in some social conflict.
If that doesn’t resonate with you, then go find the Black women, the differently abled, and the trans, non-binary, and queer folks in your CS department and go learn some courage from them. In the often toxic world of computing education, they have no choice but to be brave and demand change.
