The ongoing Code4Lib discussions on diversity and welcoming-ness plus @bibliotechy pointing me to this webcast of Jessica McKellar (of hyperinvolvement-in-Python fame) talking web frameworks and diversity outreach reminds me that I meant to post about my experience TAing at the latest Boston Python Workshop.
tl;dr: If you have the chance to take, TA, or organize one of these workshops (they’re not just in Boston!), do that. FYI: the Library Code Year Interest Group will be adapting the workshop as a preconference at ALA Annual next year. So if you’re coming to Annual, you have a chance to get involved . (Drop me a line if you’re interested in TAing or organizing; I’ll be talking up registration for students in the spring.)
What BPW is
Boston Python Workshop is an evening-plus-a-day introduction to Python for women and their friends. It presumes absolutely zero prior coding background; much of the first evening is devoted to getting your development environment set up, and it’s careful about defining terms and breaking concepts down into small steps. That said, a lot of it is also self-paced, and we had a lot of TAs, so the workshop could accommodate a wide range of skill levels. (We had students with lots of programming or sysadmin background wanting to add Python to their toolkit, and students with no technical background there to learn along with their code-crazy kids. And it worked.)
BPW’s also an open-sourced curriculum; lecture notes, projects, etc. are published in lots of detail, allowing for the program to be replicated elsewhere. I know people who’ve participated in Philadelphia and Chicago Python Workshops.
And it’s also part of a pipeline that let the Boston Python User Group grow to over 1800 members and over 15% women. Hooray!
First, it’s absolutely mindblowing to be in a room full of technologists that’s about 90% female. And includes people of many different races and ages. I had never seen anything like that before. And in a way when you’re in the middle of it it’s not special, right? I mean, these are the students, and you answer their questions and it’s just like answering any students’ questions anywhere. But then you get half a second in which to step back and see the whole room and — whoa.
Second, when I said it’s just like answering any students’ questions? I lied. Because I kept getting chances to name impostor syndrome. And students would look at me with relief and this shock of recognition. They’d never heard the term but they knew exactly what I meant and they’d thought they were the only one. No (sadly)….Every single smart woman I’ve ever talked to about this. And some of the men. All of us. Just naming it, just labeling it as a real thing, visibly did so much to leach its power. And they’d had no idea.
Third, the thing that really stuck with me? I hadn’t realized until I was in that room how much time I’ve spent in technology waiting for the other shoe to drop.
To back up for context: the instructional culture was incredibly nonjudgmental. We were constantly modeling our own fallibility — “oh, I don’t know that but so-and-so knows a lot on that topic, let’s call that other instructor over”. “Gosh, I can never remember the syntax of that one; I always ask Dr. Google.” And, again, that look of relief from the students, realizing they didn’t have to be perfect.
Or, sweeter but sadder, they’d ask questions (students, right?) and preface them tremendously apologetically. Sorry for not already knowing the things they’d come there to learn, sorry for bothering people who had come there to teach. And then we…wouldn’t judge them for not already knowing. Just start from where we were at and move forward together and be happy and engaged with the process. And they’d look not just relieved but grateful. Because they hadn’t been expecting that.
And I realized, I’ve expected something else too. Literally my earliest memories of encountering other people interested in code was that they already knew so much more than I did that I could never possibly measure up. And my earliest memories of code culture are all about people swapping jargon, not (or not just) because they’re workshopping a problem, but as some sort of posturing, demonstrating who has the highest social status by who’s got the most of the
malloc spec at their fingertips, or whatever. And that’s a big part of why I didn’t get into code until recently. I wasn’t interested in playing those status games and moreover I never could — I can sketch out conceptual answers on the fly to questions my husband asks senior engineer interview candidates, but I’m going to have to look up the details of syntax every single time. Everything I saw of software culture in high school and college said there was this bar — you must be at least this cool to play with our toys — and I was already way too behind to measure up, and didn’t have the right kind of brain for that metric anyway.
So that’s the shoe that didn’t drop in that room. We simply didn’t have a “you must be this cool” bar, an expectation that the only socially acceptable entry point is way past the beginner level. And I had no idea how much energy I’ve poured into building the armor, into being tensed against the not-cool-enough strike about to come from some unknown quarter, until I TAed a workshop and the strike never came.
It turns out it’s okay to be a beginner, and it’s okay not to know, and we can build a culture where you can start wherever you’re at, and someone will smile and hold out their hand and say, hey, wanna walk forward with me?