Process is culture and values

A truism in software engineering, and I think engineering in general, is that your process IS your values. If you value code correctness your process will require the creation of unit tests. If you value UX then your process will involve user testing and feedback and the inverse is true. In my reading about racism, CRT, and anti-racism, time and again I find paragraphs, pages, chapters, and whole books about racist and damaging processes, procedures, and policies.

What I find difficult, however, is that in discussions with folks people are very comfortable identifying these bad processes and policies but are deeply uncomfortable with the idea of crafting good ones. It is maybe not surprising that this happens but I remain annoyed by how quickly people seem to run from attempts to craft antiracist policy. We would rather talk about how things went wrong, instead of crafting rules to attempt to guarantee that they will go right next time. I understand this fear – what if the process or policy we create is ineffective or counterproductive?

A problem with this, however, is that when we educate and change hearts and minds it is largely a one-by-one process. What’s worse is that antiracist research and behavior asks a lot of each person who undertakes it and puts them at a comparative disadvantage to those who do not. This work often requires the creation of large networks that are hard to maintain. They require not using populations of convenience in your research and more work before and after your research to make sure you are properly giving back to your participants.

Additionally, when people join your community, how are they to know that it is an antiracist one if they missed last years trainings, readings, and meetings? How will you transmit to them the shared understanding, the implicit rules that were set when the community put time and effort into thinking about how to do better?

The answer to all of these things is to turn implicit rules, shared understandings, and values into explicit rules policies and procedures. Give them some wiggle-room and update them regularly but make sure that they are explicit and required. Have your new members read and understand them. Use confusion and discomfort with these rules as signals and opportunities for teaching and self-education.

p.s. I wrote this post rapidly and out of an immediate sense of annoyance. Let me know how I can improve it?

Why Tufts

I have chosen Tufts twice now. The first time was for a Masters in CS and, to be entirely honest, it was a choice of convenience. I had been working as a software engineer in the Boston area for 6 years at that point, and neither I nor my girlfriend were interested in moving at the time. So I looked at highly ranked CS Masters programs in the area and settled on Tufts. What I found when I got here was really amazing. The CS department had an amazing student culture. This was the before-times and you could find students from first years in CS1 to ABD Ph.D. students in Halligan Hall, the CS building, at all hours of the day and night doing homework, socializing, and educating themselves and one another. 

Spending so much time in that building listening, learning, and collaborating inspired me to be a TA in the third (and fourth) semester of my Masters. I also, somewhat on a whim, signed up for a course called Engineering/STEM Education taught constructively by Dr. Julia Gouvea. The one-two punch of teaching, and learning about education, made me realize that I really loved teaching and learning. So I decided that the next step was a Ph.D. in Education, with a focus on computer science ED, and started looking for schools. It quickly became apparent to me that Tufts would be the best place for me and the reason was Dr. Gouvea and what I was learning in her class. The class was very weird, especially for someone very used to a more standard, CS, educational style. Every week we were assigned readings and when we came to class we discussed them, and did fascinating, odd, thought provoking activities. There was no exam, and the few homework assignments we turned in were remarkably vague in specification. But every week I learned something fascinating, hard to explain, and important. It was a class about constructivist science education, in many ways, taught in a constructivist manner. It was a class about responsive teaching being taught by a professor who was constantly redesigning and rethinking the course based on what we were thinking and doing and then we read “Discovery Learning and Discovery Teaching” and I realized that the Tufts education department must be full of people wanting to teach and learn in this way. 

In a stroke of luck, I found out in the same week that Tufts would ask me to defer for a year and that my alma-mater, Cornell College, wanted me to come work as a lecturer and although I applied to other schools last December I was pretty sure that Tufts was where I wanted to be.

I am back at Tufts because I want to teach Computer Science this way. I want to find out if love (aka social caring) can help students better understand algorithms and data structures. I hope to prove that every student can discover how to code. I would love to find out what happens in a 5th grader’s head when you hand them an AI powered robot and tell them to explain its behavior. It also doesn’t hurt that at the Center for Engineering Education and Outreach I get to play with a seemingly infinite supply of legos.

This post should also show up here at some point soon: https://sites.tufts.edu/asegrad/