Bridget Kromhout

Ops Sundries

Let Me Google That for You

Late-night after Velocity Santa Clara, the crowds filling the hotel lobby bar earlier in the day have scattered. A few conference-goers with morning flights remain, ranging from speakers to conference committee members to attendees taking it all in. We decompress, talk tech, play games, drink, and eat ridiculously rich Nutella chocolate cake. We enjoy these last few hours with new friends and old.

After midnight, the discussion takes a serious turn. One pretty awesome guy who’s been waxing poetic (tomorrow and tomorrow and tomorrow) in his Werewolf defenses says, “I want to ask women in tech about being women in tech, because you’re the ones who know the most about it.”

Katherine Daniels and I look at one another before simultaneously saying, “No.”

We tell the half-a-dozen (or so) men we’ve just met about Lara Hogan’s Mean time to “women in tech” post, and explain that well actually, we are just tired of talking about Being A Woman In Tech OMG. Katherine is a web operations engineer at Etsy (a world-famous monitoring company that also is a marketplace for handmade goods) and is co-authoring an O’Reilly book with Jennifer Davis! I’m a devopsdays global organizer and run Docker in production at DramaFever! We have lots of stuff we come to tech conferences to discuss, but if we aren’t currently on a panel about being women in ops, then that’s probably not what we want to discuss right now.

But why not? After all, we live it every day. We know so much about it, and you are asking us because you respect us and know we have things to say!

Okay, let me put this in terms everybody reading this will understand. You know how when you have questions about open-source software, and there are times and places and people to ask? There might be a repo where you can open issues or an irc channel or a mailing list, and the people listening to you there are willing to help. And even they will ask you if you’ve read the faq, the README.md, the quick-start guide, the tutorial – because you’re an intelligent person who can get started on your own before you need someone else to hold your hand.

And if you go on the dev mailing list where they’re doing a deep dive into the regressions in the latest release candidate with your “I tried the intro walkthrough and it was confusing”, you probably shouldn’t be surprised if the answer is “that’s off-topic here, and while some of the mailing list members might end up wanting to help you, they didn’t all sign on for that in this specific context. Take this question over here instead.” There’s a time and place for every kind of question. Not every forum is appropriate for every question, because that would just lead to a chaotic mess of the sort that makes ops folks cry tears of unfathomable sadness.

There are lots of resources around learning about the issues affecting women (and other marginalized people, although this post is specifically about women) in tech. Being an effective male ally is a great goal (and that post, written by Ian Malpass, has plenty of links). I’m glad you want to learn! You don’t actually need a specific woman to walk you through it. You’ve got this.

So wait, am I saying that the answer to “I’d like to make tech better for women – how should I do that?” is “pull requests accepted”, by which I maybe mean “fuck you if you don’t come up with a solution on your own”? Heck no! I’m saying that the best communities are the ones where, in a clearly delineated and accessible way, people who know things reach out to make it possible for new people to join the conversation and get the help you need to start. But even in the most supportive of communities, you’re expected to do your homework, and then ask people who’ve opted-in to answer, in the place they’ve offered to do so.

You probably wouldn’t open an issue in the Consul bug tracker and insist that they walk you through launching your first AWS free tier instance. You probably aren’t going to watch Joshua Timberman’s defense of curlbash and then @mention him on Twitter, asking him to explain the command-line flags for “curl” to you, and then decide that clearly those infrastructure as code people are just mean and unhelpful because he doesn’t want to be your named pipe to Google.

Respect for each other means we do our best to learn before asking for someone’s time. You’re busy, I’m busy, we’re all busy. And none of us need lmgtfy links to find out that “women in tech” has been discussed many times in many forums for years, and you don’t need to require the women you meet to start from the beginning with you.

DevOps may be made of equal parts empathy and artisanally-crafted yak-hair sweaters, but just because Katherine and Jennifer taught an all-day training on Effective DevOps doesn’t mean that you’re entitled to have Katherine teach you to knit at the bar. So why assume that she should use her limited stay in Pacific Daylight Time explaining othering or unconscious bias just because you asked? Maybe she wants to play Jungle Speed instead! (Jungle Speed, for those who haven’t played it, is like the pattern-matching card game Set, but with the addition of melee combat which may lead to broken glassware.)

“So I’m going to offend a woman I know just because I ask her about her experiences? That’s pretty much bullshit, and plus, my friend/co-worker is fine with it!”

Hey, when you’re operating from a place of mutual respect and you already know each other, you can ask politely. When you’ve just met someone, you don’t know what kind of table-flipping sexism or web-scale data loss she might have endured in a previous job, and maybe she doesn’t want to have those painful conversations with you until you know one another better. Assuming that an arbitrary woman wants to do the work of educating you about sexism is not the most effective choice, any more than assuming any random open-source contributor wants to provide tech support for you, on demand, on your timeline. This may be the first conversation you’ve ever had about the experience of women in tech. I will need to commission a custom hand-knit hat to eat if it’s the first conversation she’s ever had about it. It may not even be the first conversation at that conference or that day.

So when should we ask people for help? First, start where you already have an established rapport with the person, instead of trying internet or conference randoms. I’ve asked Jason Dixon for help with Graphite, Julian Dunn for Chef advice, Seth Vargo for clarification on tricky Consul details. Key facts: I already could call them friends so I wasn’t asking these questions on first meeting, I asked if questions would be okay, and I didn’t assume the answer would be “yes”. I tried to formulate reasonably informed questions so as not to waste their time. And if they’re sick of those questions, I would be fine with them just saying “this is the thing you should read”.

Just because someone will probably have answers for us does not mean we’re entitled to their time on our questions. (But I am grateful to all three of those fine folks for their generosity of time.) And if we actually know each other more than in passing, I’m willing to chat more about this. If we don’t, I’ll give you my elevator pitch on why “ops guys” shouldn’t be in your vocabulary, as long as it takes less than three minutes and we talk about actualfax tech afterwards.

So yes, I have plenty of experience being me-in-tech. This doesn’t actually make me an expert on All Women In Tech Ever, any more than I’m an expert in all Docker in production ever. I can only speak to my own experiences. And I’m happy to talk with you, but fair warning: I mostly want to talk about the wider Docker ecosystem. The Geek Feminism Wiki can help you out with the 101-level women-in-tech stuff, because I would much rather hear about your experiences with Kubernetes and Mesos.

When we respect each other’s time, I’m a lot less tempted to answer, “let me google that for you”.