The Changelog: Software Development, Open Source - Mind the Gender Parity Gap (Interview)

Episode Date: March 13, 2015

Sarah Mei joined the show to talk through a recent article she authored titled "Mind the Gap" and why we’re missing our best chance for gender parity. We discussed our innate subconscious assumptions and prejudices towards one another, how we alienate women from the developer communities, and what we can do to step across this gap and make a conscious effort to combat those assumptions.

Welcome back everyone. This is The Change Log and I'm your host Adam Stachowiak. This is episode 146. Today Jared and I are talking to Sarah May about Minding the Gap and why we're missing our best chances for gender parity. And you much need a conversation on this show. Great having Sarah on the show today. She's the founder of RailsBridge, director of Ruby Central, and she's a chief consultant at DevMind. We've got some awesome sponsors for this show, CodeShip, TopTile, and CodeSchool.

We'll tell you a bit more about TopTile and CodeSchool later in the show, but our friends at CodeShip, they want you to deploy to production 10 times faster than you're doing today. They do it by this awesome new feature called Parallel CI. And if you want faster tests, you have to run your builds in parallel. And with Parallel CI, you can now split up your test commands into 10 test pipelines. This lets you run your test suite faster than ever before in parallel

and drastically reduce the time it takes to run your builds and get that code of production they integrate with github and bitbucket you can deploy to cloud services like heroku aws and many more and you can get started today for free by trying out their free plan which includes 100 builds a month and five private projects or you can use our offer code the changelog podcast again thatCAST. Again, that code is THECHANGELOGPODCAST to get a 20% discount on any plane you choose for three months. Head to codeship.com slash thechangelog to get started. And now on to the show.

Everyone back here with Sarah May. Sarah, how are you? Doing good. Thanks for having me. Yeah, we got Jared on the line too. You can't forget Jared, right? Jared, how are you? I'm hanging in there. How are you? Doing good. Thanks for having me. Yeah, we got Jared on the line, too. You can't forget Jared, right? Jared, how are you? I'm hanging in there. How are you?

Hanging in there. Well, you know, that's the best way to be, to be hanging in there. This is the first show in a long time. This show's being live broadcast. So if you're a member, you may be listening to this live. We didn't do a lot of promotion around it because Sarah wanted to be the experimental guest to be on the live broadcast. We're live broadcasting just to members. So if you want to listen to the show live, you've got to be a member.

That's the barrier to entry for that. So you can do that by going to the changelog.com membership. You learn all the details there. You get access to Slack, the live channel, and a ton of other stuff to sort of surround our community of open source enthusiasts. And Sarah, it's so great to have you on the show today. We got suggested to have you on the show by Matt Brixton, actually a member. He suggested having a conversation around your article,

which is, I guess, somewhat popular. What do you think? Mind the Gap? Was it popular? It was pretty popular. Not quite as popular as your other article you mentioned in the pre-call, but, yeah, still popular. Yeah's definitely at least popular. There's your other article you mentioned in the pre-call, but yeah, it's still popular. Yeah. Yeah. It's been, it's been interesting. It hasn't made the front page of, you know, the programming subreddit, but, but it's definitely sparked some really interesting conversation, especially on Twitter. Yeah. So let's give an introduction to you, Sarah. I mean, I knew of you, you know, Jared, in the pre-call, we talked about us being Rubius at heart. So we've known of you for a while. But for those who may not know who Sarah May is, who are you? Who am I? That's a loaded question, isn't it?

Well, right now I'm the chief consultant at DevMind Software, which means that I'm working with clients, mostly in San Francisco. DevMind's based in Chicago, but I am the San Francisco office. And I'm also a director of Ruby Central, which is a nonprofit that runs both RubyConf and RailsConf, which are the two largest Ruby-related conferences in the world. And I am also the co-founder of RailsBridge, which is an organization working to get more diversity into the Ruby and Rails communities. And let's see, what else do I do?

That's about it. I do a lot of conference speaking. I do a reasonable amount of writing, and I'm working on a book. And you also do the refactoring of the codes. I do a lot of that, yeah. Most of what I do in my client work is going into, I wouldn't say elderly codebases exactly, but going into mature codebases

and helping the team figure out where and when to refactor things. Elderly, I like that. It has a certain connotation to it, doesn't it? I feel like a Rails app can actually be elderly after like three months. No doubt. It just depends. Elderly. You know, it's funny too because we just had David

hand him our hands on this call before last week, and you're the director of Ruby Central, so you've got RailsConf coming up here in May. Because we just had David hand him our hands on this call before last week. And you're the director of Ruby Central. So you've got RailsConf coming up here in May. Some exciting stuff happened around that. Call of Proposals, I think, is closed now, right? Yeah, we've announced the program. I'm really excited.

We have a very strong program this year. And I'm super excited, of course, that David's going to come back and do his keynote, as he always does. Yes, of course he can't. Can't have a Rails conference without DHH giving the keynote, right? I know, right? What would we do? It's like Apple with no Steve Jobs. Yeah, and that hasn't worked out for them, has it? No.

No, I guess not. It has not. So on RailsBridge and DevMind, of course, as well, the work you do there. What's cool about RailsBridge? You had some recent news, too, about Bridge Foundry, so a slight shift in the way the organization is sort of organized, I think, from a nonprofit standpoint. Can you talk a little bit about RailsBridge and what you do there? Yeah, absolutely.

So RailsBridge, I started it with a woman named Sarah Allen in 2009, and originally our goal was to bring more women into the Ruby community in San Francisco so that I could go to a Ruby meetup and not be the only one there. That was essentially my goal. It turned into something much larger than that. And we've done hundreds of workshops now across dozens of different countries. And we've had, I think, last count, about 10,000 people go through one of our workshops, which is awesome. We've expanded our mission a bit and we're now focusing on bringing in members of other underrepresented groups as well. We did a workshop with the Black Founders. We have the curriculum translated into

Spanish. We've done a couple of Spanish language have the curriculum translated into spanish we've done a couple of spanish language workshops uh and recently we decided that the model that we've been using is actually super useful for other technical communities as well so we formed a parent organization called bridge foundry and under that we now have closure bridge which is pretty cool they've been holding events we have mobile bridge which does both ios and android workshops and then of course we've still got Rails Bridge under there as well. So we're excited to bring that model to other communities. We have a little bit of Rails Bridge here in the heart of the change law because Beverly Nelson, I think she's your Southeastern chapter manager.

Is that what you call? Yes, absolutely. So Beverly's been on the team for a while, worked with her at Pure Charity. She loves learning, does you know so beverly's been on the team for a while worked with her at pure charity she uh loves learning as you know so one of the things that she's tasked with here on the changelog not so much on the podcast but uh on our editorial side is really um like she just put out a post this last week called a huge list of coen's because everybody loves Ruby Coen's to learn Coen to learn Ruby, the enlightened way, of course. And so there's, you know, this splurge of other, um, of other languages using the Coen's, um, Coen's way of, of doing things.

So she's on the team and we're happy to have her. So that's, that's cool. There's some, some crossover there. Yeah, that's cool. I didn't know that. You didn't know that, huh? See, every day we've got surprises for you. Every day. In fact, she's working up a post right now about Bridge Troll. Oh, nice.

Which I believe is your guys' software. Is it a Rails app? It's an open source Rails app that we've built to manage the workshop process that we have. So it takes our SVPs. Originally, we did most of it through meetup.com. But as we got bigger, we discovered, of course, that meetup has some limitations being a service and being not within everyone's price range, certainly. So we decided to build this. And we also think it's a great way to, for our students, if they're interested in getting involved in open

source for them to sort of nice, easy into into the field because it's software they've already used and it's people they already know and it's uh so we've it sort of serves dual purpose in that sense i like the name bridge troll definitely cool name yeah i like it too any other fun internal names y'all use that you could share here today and internalinternal names. Hmm. I'm not sure. BridgeTroll came about actually because, mostly because we had, we had a workshop, I think once where we have, we usually have child care at our workshops. And at that workshop, the child care was in a conference room and the kids drew all over the, all over the whiteboards, which of course is fine. But one of them drew a troll and someone came in and said, hey, that looks like. So that's cool.

That's that's cool. That's a nice story, too, that it's funny, those happy accents sometimes. Right. Yeah. Yeah. Things happen like that. So let's let's dive deep into the heart of the conversation. So our show is roughly, minutes, 55 minutes-ish.

And today, like I mentioned, Matt Brixton, one of our members, has suggested – I've read the blog post before that. I didn't think about having you on the show to sort of talk about this, but we serve our member community, so they want to hear it. We're going to have you on the show to talk about Minding the Gap. And I certainly enjoyed the perspective that you brought to the table here in this conversation. It's really kind of going around why we're missing our best chance for gender parity. Can you talk a bit about the overall summary of what this article is about? And we'll sort of dive into some specific points along the way. Sure. Yeah, absolutely. So I wrote this mainly because I see a really interesting trend happening in the Ruby community and also in other communities right now, which is that we have a bunch of people who are coming in because of various code schools and

boot camps and things like that. We have never had an influx of this type before. And in fact, I think the Ruby community is about the first, we're the vanguard in that we are the first community to be seeing this because a lot of the early code schools taught Ruby and taught Rails. And so now we have this enormous pool of people that are junior developers and are in general much more diverse than the community we have right now. And so we've got this amazing opportunity to really bring a lot of diversity into our community. But in order to do that, we need to know what our own limitations are and we need to understand how it is that we got where we are and how we can not make the same mistakes when we're trying to hire people now. And the other thing that prompted this was

that I found, I love reading scientific research of various types that relate to things like programming teams and practices and how we write software. And I came across one that was a very basic, it was actually an economic study about the way that women and men are perceived when they're being interviewed or when you're look at a resume that is exactly the same, except one of them has a female name at the top and one has a male name at the top. And they will evaluate the one with the male name at the top more strongly than they will the one with the female name at the top. And it's unintentional, right? This is something we all do because it's part of the culture that we live in. And so the question is, what can we do to move away from that? What can we do to combat that bias?

Because if we just allow it to continue the way it's been going, what's going to happen is you're going to try and bring these people in, but you're not going to be able, it's much harder to get them into your interview pipeline, get them in to your company if you're not aware of this bias that everyone has. This bias, you say, has kind of exposed itself in what you might call an epic way in our specific community, the open source and startup community, which is kind of a microcosm of the larger tech industry which already has the problem some of the stats that you gave out there is that in the industry overall women make up 26 percent of developers which is already pretty bad right but you say in your world which is our world here so we're not even at 74 over 26. We're at 98 over 2. For every woman, you're looking at, as you said, a huge gap.

Meaning if women are 26% of developers in general and they're 2% of developers in open source and startup, there's one question, which is why are we only at 26% overall? There's a lot of people that are thinking about that problem. But the one that I'm more interested in is why are we only at 2%? Why don't we track the overall industry? Because you would think, right, you would think that if the overall industry was 26%, that we would be, you know, sort of within margin of error of 26%, but we're not. And so one of the things that I thought about that was that we have a very interesting culture in the startup and open source world that is not present in the big company world. And that is that we love people who are self-taught. All of our heroes are people that

were college dropouts, the Mark Zuckerbergs, the DHHs,ught. All of our heroes are people that are, were college dropouts, the Mark Zuckerbergs, the DHHs, for example, right? These are people that don't have computer science degrees, but have made incredible impacts on the world of programming. And you can see that also in the way that we have shifted our hiring practices to be more, to take more into account things like your GitHub profile, like how much open source do you do? What kind of things do you contribute to? Can I look at your code, right? So we depend much more on these informal qualifications than does the rest of the industry. So if you walk into a Google interview or a Microsoft interview or something like that,

they're going to expect you to have a computer science degree, and they're going to expect you to have all of the knowledge that a computer science degree brings. And that is not necessarily true where we are. And so sort of in compensation for that, because we like to think about ourselves as being sort of the self-ught, bootstrap-type people. We fill in the gap with other things like GitHub profile and conference talks and blog posts and that kind of thing. And those are the things that are more subject to the bias that I spoke about earlier. And so what that means is that as a community, we are more reliant on evaluation methods that are subject to that bias.

And people with formal educational degree, people who have computer science degrees, who, for example, have worked at Google or worked at Microsoft, those folks have formal qualifications that can sometimes compensate for the gap. But if they're self-taught, which is what we see all these people coming into the community from the code schools, most of them are self-taught and don't have computer science degrees. Those people are going to find it much harder because they're going to find that the evaluation criteria that people use is much more subject to this gender and racial bias that we all have. Yeah, I think, you know, it is this gender and racial bias that we all have. Yeah, I think it is definitely a gender and racial bias. I think it also kind of leads itself into, you could call it age discrimination or even lifestyle bias, because the ones who may not have the strong open source contributions or the excellent list of conferences that they've spoke at or keynoted, it's because they're doing other things with their free time. Right. I mean,

yeah, absolutely. And with women, you know, traditionally it's at home with kids or, you know, the housework, the things that you bring up in the article, you know, the same can apply probably less so in the West to men with kids. So what do you think about this whole GitHub as resume as a thing? Is that just a bad idea that we all kind of stumbled into, or are we just kind of doing it wrong? I think that it's definitely an interesting idea. One of the things that I think, though, is interesting about that,

I actually did a talk about this last year at nickel city ruby is that if you look at my github profile i basically don't contribute to open source so you look at my contribution graph it's basically completely blank there's a few little green squares here and there where i did some bridge usually yeah i was right so you look at that and you're like, huh, well. Sarah, geez, what's going on here? Well, and the interesting thing was when I was at Nickel City Ruby, I looked at all of the other speakers' contribution graphs and they were all extremely impressive. Lots of green squares. It was great. So you look at that and you're like, well, I mean, if you're looking at GitHub as your resume and you look at my GitHub, you're probably not going to get a really good sense of what I can do, right?

And, you know, I think I'm an extreme example because I have surfaced in other ways within the community. But for people who haven't done that, the question is like, how much are we losing by depending on public publishing of code? Like how many people are we missing out on? Because that's one of, you know, that's the thing that we depend on the most. I think it's definitely something that can be taken into consideration, just like everything else. However, I don't think that it's great as a filtering mechanism. I think some of it plays into the whole passion conversation,

which is something that the startup and open source community have in common is that we value the desire, the passion as something that is a characteristic that we like. And so we look at lack of contribution or lack of public code or what have you as you don't have a passion for this craft, which is sometimes the case and sometimes it's a complete red herring, right? Right, exactly.

I don't think those are necessarily comparable statements. I agree with you that that's what we're looking for is the passion, but I think that the mechanism that we've chosen for that is insufficient. I agree. We started out talking about the industry overall. Could maybe you better define what the industry overall is when you say that versus – because it feels kind of like a slightly us versus them or at least when it comes to stats of 26 percent of developers and only two out of 98 are women. Who is the – what makes up the industry overall when you say that? The industry overall includes, in addition to sort of the startup and open source worlds that we,

that we're in, it includes both sort of the larger, what I would consider to be the larger open source companies, things like Google, and also larger, more traditional organizations, your IBMs, your HPs. And also even more than that, it is the non-technology focused organizations that employ programmers. So for example, banks, insurance companies support, provide millions and millions of programmer jobs, most of which are not, most of which we don't see living in our GitHub world. Well, we got to take a quick break here to listen to a word from one of our sponsors. We'll come back in just a second. TopTile is the best place to work

as a freelance software developer. If you're freelancing right now as a software developer and you're looking for a way to work with top clients on projects that are interesting, challenging, and using the technologies you want to use, TopTal might just be the place for you. Working as a freelance software developer with TopTal means that your days of searching for long-term high quality work and getting paid what you're worth will be over. Let's face it, you're an awesome developer and you deserve to be

like one. Joining TopTal means you'll an awesome developer and you deserve to be competent like Juan. Joining TopTal means you'll have the opportunity to travel the world as an elite engineer. On top of that, TopTal can help provide the software, hardware, and support you need to work effectively no matter where you are in the world. Head to toptal.com slash developers. That's T-O-P-T-A-L dot com slash developers

to learn more and tell them the change law sent you. All right, Sarah, we're back. I think some of the things we've been talking about around this perceived competence is what you describe as the credibility gap. Can you talk about that a little bit? Yeah, the credibility gap is a phenomenon where if you have two people that have more or less equivalent skills and the difference between them is gender, then people will make assumptions about the gender of the people are, you will usually assign a higher competence to a male programmer in front of you than to a female programmer in front of you. And you can see this come out in a lot of different ways. So for example, if you go to a meetup and you see a woman in a meetup, it used to be that you could pretty much assume that she was a recruiter and not necessarily a programmer. But making that assumption can be dangerous because if she is

a programmer, then she is starting from this deficit of competence that you have sort of projected onto her. And even if you get corrected, even if you talk to her and discover she's not a recruiter, she is a programmer. In fact, she's a better programmer than you are. Like, that's great, but it doesn't make up for initial uh gap that you perceive and that you assign essentially to her and uh that's you know it's it's a psychological phenomenon i think i think of it as a it's a bug in our wetware meaning like it's it's something that our brain does that we don't want it to do necessarily and so at this point what we need to do necessarily. And so at this point, what we need to do is understand that it does it and work with it. In golf, they call that credibility gap a handicap.

That word. Yeah. Because, right, so if you're a golfer, right, if I don't play golf often enough, but I know enough of the terms, but they call the idea of the game shooting. So if you shoot, I don't even know what the number is, Jared. When's the last time you played golf? Never. I'm just kidding.

Par 72, man. Right. There you go. Par 72. So just to give me some baseline to run some numbers off here. There's like par – don't worry about the golf terms. I messed that up. But nonetheless.

They do call it a handicap. The point is that if I come into the game and I'm not as good as a pro or somebody who's better than me, I come in with some shots ahead and they call that a handicap, which is somewhat similar to what you're talking about, which is actually a perceived gap, which is me or someone else placing a deficit of ability on someone based on their gender, race, or creed. Exactly, yeah. A handicap is trying to actually level the playing field. In the case of the credibility gap the problem that Sarah suggests is to kind of give that benefit of the doubt, almost to give a woman that you don't know a handicap until you have more information to act on because she's operating at such a deficit already that it's unfair. But you also said too, Sarah, that you first noticed yourself make the same kind of mistake a few years ago at a conference. Can you talk a little bit about that situation and how. And before I did that, I had this, you know, I do what everyone does, which is that I looked at her and I was like, well, she's dressed pretty nice.

Probably she's not wearing a T-shirt and jeans. Like, hmm, she's probably a recruiter or, you know, maybe she's a product manager or something. And it wasn't necessarily a conscious judgment, but I looked at her and I made a decision about what I thought she wanted to talk about, for example. And so I started to talk to her and I realized about three or four sentences in that she was a developer. In fact, she was a developer with way more experience than I had. And I had just mistaken her for essentially a non-programmer based purely on what she looked like. So did you put your foot in your mouth or? Yeah, I totally did. Did you have to apologize or did you?

No, it's one of those things where it's like, it's more like, it was more of an internal thing. I think I'm sure she noticed because I noticed when people do it to me, but most of the time I don't mention it. And she didn't mention it, which I was very grateful for. But you know, what that shows is that even people who are in that group make that mistake. Right. I make that mistake. All women make that mistake. You know, and when you see this come through also in race, you'll know you'll you'll see that white people make this mistake in assuming that other white people are more competent.

But black people also do it. They also will rate people who are white higher. And so it's just part of the cultural milieu that we're living in and it's unescapable for all of us that are here. Yeah, I know that, you know, just in the fact that we all discriminate that way, I think it's, as you said in your post here, it's sort of like cultural, it's sort of subconscious that you start to get pulled into this and you may not even do it intentionally even if you can bleed to the nth degree that you're not racist or biased or whatever the terms you might apply to a negative connotation on that is that we tend to just do that i think it's part of societal upbringings to a degree, and we see it in media. We see it in marketing.

We see it almost everywhere we go, people being objectified, not just women but also men, also different religions and race and creed. It's sort of this systemic issue that we have. the, you know, as you mentioned in the pre-call, this subreddit, the subculture of where we kind of hang out, which is like in the open source community, the developer community, where I guess the rubber meets the road, so to speak, that none of this we do is really intentional, but we do do it day to day. We do. And sometimes these assumptions are correct, right? And so that's when it's even hardest to see it. Like when I see a woman at a meetup and I assume she's a recruiter and I'm right, then I don't notice it, right? I don't notice that I made that judgment. And so one of the things that I've been thinking a lot about is how can I practice not making that mistake? And so what I've been trying to do

is when I meet a woman at a conference or at a meetup, I assume she's incredibly technical and I will start talking to her as though she is. And then sometimes I'm wrong, but I, what that does at least what I'm hope that it does is that it, it levels the playing field a little bit so that if she is technical, that we can talk about, you know, we can, she doesn't start with the same perception gap that she would otherwise. And hopefully over time, what that'll do is it'll recalibrate, hopefully, you know, at least a little bit recalibrate the way that I evaluate people at a subconscious level. But I think that that's a, that's a long-term goal.

How does some of this play into the passions that come back to Sarah? The Sarah that goes to RailsBridge, the Sarah that co-founded RailsBridge that does all this stuff. How does this play into this topic, play back into how you treat your work there and how you form community and bonds there inside of RailsBridge? It's interesting because RailsBridge has exposed me to many more female developers than I ever knew before. And so I have seen an incredible variety of people come through RailsBridge. We actually have quite a few people come through RailsBridge who are developers from other communities that just want to learn Rails,

in addition to people that are new to programming. And so I've met all kinds of female developers of various types, system administrators, DBAs, PHP devs,.NET people, Java people, and so on. And it's expanded my idea of, and that has helped me expand my idea of what a female developer looks like, because I've seen so many more examples. I think part of the problem that we have is that we don't have that many examples. Because we're at 2% and because we don't tend to go to conferences where people from insurance companies hang out,

we don't see those people. And part of the goal of RailsBridge was always to integrate, not to have our own little island of women doing their own thing, but to integrate back into the larger community. As I said, my original goal was to not be the only woman at any given SF Ruby meetup. And so to that end, we've always brought in men from the community to teach, to TA, to volunteer. And we have, our workshop structure is set up fairly deliberately so that there are social opportunities to, and not just sort of on the teacher-student level to get to know people in the community. And so an interesting side effect of that is that around San Francisco, at least, and I've heard this from other communities that have strong Rails bridge contingents,

the men in the community have gotten better at teaching, which is an interesting side effect. And they've also been able to see more varieties of female developers than they can see just at their job or at the meetups where it used to be 2% to 3%. So I think that part of where this comes from for me is that I feel like we need to, as a community, we need to see the variety of developers along many different axes of diversity in order to start normalizing their presence in our community at all. Well, in your blog post, you did have some prescriptions for us. So maybe it's a good point here to sort of talk about some of those prescriptions in terms of what we can do to sort of do this. And the first thing you mentioned was, I guess is the summary of your blog post, which we didn't really talk about the intro, which I loved a lot too, which was your trip in London,

talking about this idea of the gap when you're walking off the tram. But, you know, first in your list of things to do that you can do to fight back is to notice the gap, recognize and acknowledge that these assumptions are in place when you make them, you know, sort of like you did at that conference or sort of like I might do when I'm at a meetup and I might make an assumption about someone that they are not a developer or just in general is to

just notice this gap, period. Yeah, I think that's the first step. And for me, it took a while before I knew what to do about it. So I, I sort of, I just, for a long time, I just sort of kept an eye on it. Like I would notice when it happened, I started to try and pay attention to it. So to, you know, so that when I met women, other women at meetups and at conferences and so on, I would just sort of keep track of like, Oh, I made an assumption about that one.

I didn't make an assumption about that one. That's interesting. And I think just noticing it is the first step because none of us, you know, I don't think that I am sexist. I And I think that it's important for us to understand the cognitive skew that we are subject to, because that's the only, just being able to see it is the first step to being able to do something about it. I agree with you. Absolutely. I think some of the best things that we can do to help one another with regards to these subconscious prejudices that we have is, first of all, just to raise awareness that this is a possibility, that this is something that you do. And then secondly is to put a name on it, which at least for me, you've done for me. Credibility gap is not something that previously had a name in my mind. But as I was reading your post, I can definitely go back in recent history and be like, yep,

I did that there, I did that there, as I could commiserate with your experience that you recorded there. And I think it's incredibly valuable, first of all, that we just have these conversations. And secondly, that we can actually put a name to something that, to a bias that we have. Just like in software, when you can put a name on something, it becomes more concrete. It's a lot easier to check yourself if you have like some sort of hook by which to do it. And I think just having that term credibility gap kind of empowers us to judge our own thoughts before we project those onto other people. Yeah, absolutely.

Well, let's pause here for an ad, and we'll be right back. It is time to put the program books away. Put them away. Put them down. And learn by doing with CodeSchool. offers a variety of courses to help you expand your skills and learn new technologies such as JavaScript, Ruby, iOS, Git, HTML, CSS, and many more. CodeSchool knows that learning to code can be a daunting task. They combine experienced instructors with proven learning techniques to make learning to code educational as well as memorable, giving you the confidence you need to

continue past the hurdles. They're always launching new courses on new technologies and offering deep dives on tried and true languages, so if you don't see them you need, suggest a course and they'll build it if there's enough demand. CodeSchool also knows that languages are a moving target. They're always updating content to give you the latest and greatest learning resources. You can even try before you buy. Roughly one out of every five courses on CodeSchool is free. This includes introductory classes for Git, Ruby, and jQuery, which allow free members to play full courses with coding challenges included. You can also pay as you go.

One monthly fee gives you full access to every CodeSchool course. And if you ever need a breather, take a break, you can suspend your account at any time. Don't worry. Your account history, points, and badges will all be there when you're ready to pick things up again. Get started on sharpening your skills today at CodeSchool.com. Once again, that's CodeSchool.com. All right. Well, we're back. It's a little weird because we're not doing those pauses.

So just if you're listening and they sound a little abnormal, this is the first time we're doing them. So we at Ryan, we like to experiment and we do things abnormally sometimes. So the second thing that you talked about, Sarah, in terms of what we can do is to step across the gap. What do you mean by that? You say make a conscious effort to combat those assumptions, but I think we kind of touched a little bit there

pre to the sponsorship there, but what is some ways that we can step across that gap and begin to break down those barriers? Yeah, one of the ones was what I mentioned earlier, which is that when I meet a woman or a non-white person at a conference, I make a conscious decision in my head to assume that they are technical until I am absolutely proven otherwise. And my hope with that is that I am making up for a little bit of that gap, the credibility gap that has embedded itself in my brain. Another thing that I do that I've found that's been really effective is that when I'm hiring, before I look at anyone's resume, I have somebody take out all of the indications of gender. And that's not just the name. It can be things like, you know, if they went to a women's college or a traditionally Black university, like they need to take that kind of stuff out, so on and so forth. So there's a lot of things beyond the name that need to be adjusted. And you'll find out what those are over time when you start doing it.

But the nice thing about that is that it allows me to look at a resume without making assumptions about the gender. Then if I, for the people that sort of make it through the first screening, then I actually ask my HR person to print out some of their code from GitHub and show it to me without, basically I want to see it without their name attached. Because this bias will also affect us when we're looking at code, when we're judging someone, when we're doing code review, when we're evaluating conference proposals, and so on. And so any way that I can remove that bias from the preamble, I mean, certainly once you're like talking to somebody, it's pretty difficult to ignore. But the steps leading up to that actually seem to be where a lot of the women drop out of our process. And what I found was that once I started doing that, we got a lot, we got a much more diverse set of folks in the door for interviews. And this is part of the,

you know, the problem that we have where a lot of companies will tell me, well, I don't know what to do because no women applied for my job. No women submitted a talk to my conference. There's a problem there in terms of reaching out to people and asking them to apply and asking them to submit. But even once you do, if you are then evaluating what they send in, knowing their name or their other demographic information, what you find is that fewer women get through that phase. So I think that it's absolutely critical that we remove that information from whoever it is that's making that decision about who moves on to the next section of the interview. You find that causes a lot of management overhead?

I know you mentioned a little bit, but is it a real pain to get those names scrubbed before you do the code review? It can be. I think that sometimes it's difficult to evaluate. There's sometimes when it's, it requires so much information to be taken out that it's then difficult to evaluate, right? Yeah. I try to do that case by case, right? And, you know, part of how people could help me with that is if they could, I'm not quite sure how to make the suggestion, but if they could write.

Some software that'll do it. No, well, I mean, when they send in a resume, try to make sure suggestion but if they could write um some software that'll do it no well i mean when they send in a resume try to make sure that there's nothing in the body of the resume that would give away gender or race for example right so for example sometimes occasionally people will refer to themselves as a third person right so you know if you're talking about something like he did blah blah blah at this company right right? That kind of stuff, you know, which, you know, resume style guides tell you not to do anyway, but we see a reasonable amount of that. You know, things like that. But, yeah, I think that it's definitely been overall positive because it does mean that we get a lot more women in for like the in-person interviews.

And, you know, there's another set of problems once you're in the in-person interviews. But at least – You talked about that a bit, didn't you? Was that another – you might have another post I read that just the boardroom kind of look. You know, you come into a – you mentioned Google earlier in the call, but the in-person interview can be just as hard as just getting in the door or, you know, getting your proposal looked at. Then getting a face-to-face with someone can be just as hard as actually getting there in general. Yeah, and that's true. But I think that there are – we have to combat this bias in different ways at each stage of these processes. And so, you know, step zero really is getting resumes in the door. And then

step one is making sure that you can evaluate those resumes in a way that is less subject to bias than it would be if you just looked at them the way they came in. I think it's a smart idea too, to sort of protect yourself. You know, this is more like um i guess that's maybe a bad way to put it but it's protect yourself from yourself for the betterment of the community because you know there you go with when you say make a conscious effort to step across the gap you know that you have some sort of uh subconscious prejudice whether you like it or not that happens whether you like it or not it's just some sort of innate subcultural thing that we sort of judge people based on some attributes to remove those abilities to judge. And then you kind of get an even playing field and even look at a person's proposal for a conference or a job application or what have you.

You sort of protect yourself from that evaluating them in a bad way. You give them a chance before where they may not have been a chance. Move us closer to what we all as programmers want is like a meritocracy, right? Yeah. Where it's just purely based on merit. And we can't do that without some barriers to biases because they're so ingrained in us. So I think on the, on the coding side, it seemed like a pretty decent chance

of writing some open source software where you could point to a specific thing on the web and maybe you'd go and scrub it of any names for certain adverbs, or not adverbs, pronouns and whatnot. On the resume side, definitely harder as they come in so many forms. But we've definitely seen some conferences doing that as well.

I think maybe you mentioned that you also do that for your conference talks. It seems like a great way of leveling the playing field for picking conference speakers as well. Yeah, we've actually had pretty amazing success with that at RubyConf and at RailsConf. We use a piece of software that we developed ourselves, actually, which is open source, which anyone can use. And it follows a process where there are reviewers, and reviewers will go in and assign a rating to a talk, but they

don't see any of the demographic information. So they don't see the name, they don't see the bio. And we ask people in the call for proposal text to please not put any identifying information in their proposal itself. And some people, you know, some people still do, but usually how that works is we just kind of ask them to take it out before we start evaluating it. And then once we have a first round of scores, at that point, a smaller group of people goes in and looks at the talks, including the biographical information, including the name,

and then evaluates them based on, you know, there's a lot of stuff that goes into making a balanced program, certainly for a big conference like RailsConf, or I should say, big for the Ruby world, although it's fairly small overall. But for something like that, there's definitely a set of topics that we want to make sure we cover. And so at that point, we're taking a lot of different things into consideration, including

the experience of the speaker and things like that. But it allows us to get a first round, at least, that is less subject to the biases that we all carry. That's a good starting point. What's the name of that software, if you recall? I think it's called CFP App. Nice creative name. There's a link to it in my blog post. Found it. Ruby Central slash CFP dash app. We'll link that up in the show notes.

I also liked what you said too, that Sarah, when going through this process, that some known good speakers may not actually get through because of a crappy, I think you actually said, but crappy proposal. So it sort of strikes a balance there where get your proposal in order, even if you're a known, credible speaker, get your proposal on par, and you might make it through. And you actually take it based on not so much who they are and what they've done, but what the actual proposal is proposing for the conference. Right. Yeah, that's exactly it. I feel like

this process has actually improved overall the quality of the proposals that we get. Not just the number of them or the diversity of them, but actually I think everyone's proposals have improved. Because I think we have to, right, if you want to make it through the first round. And, you know, we do consider who the speaker is at some point during the process. So that's not something that we don't consider at all. But I think that it's some conferences in the Ruby space, I feel like have become a collection of people that I have seen before, right? And it's sort of the same set of people that you see at every conference. And I am one of those people at this point, because I've

done so many conference talks. That's one of the reasons why I'm doing fewer of them is because I feel like it's someone else's turn, essentially. But I think that one of the things that this process can help with is help us to discover people who are going to be amazing speakers and find them, even if they haven't done a talk before, or even if they've only done a talk at their local meetup or something along those lines, and get them onto the circuit, get them into our collective consciousness. Well, I know that we could probably go quite a bit further when talking through this. I know that this is certainly on our hearts when we think about prejudice and biases to our peers. And it's something that I certainly want to be mindful of. But at the same time, your last point, which is not to stare too deeply for too long into this gap because you might go a little crazy.

You didn't say that. That's my words. I said that. Well, I think that it's something that you need to think about. But it doesn't mean that it needs to consume everything that you think about. And you need to give yourself permission to still screw it up because it's going to happen. You're going to make the human, you know, I mean, we're going to exactly. We're just we're just broken people.

It's going to it's going to happen sometime. Yeah. And my the way that I try and deal with that is just when I notice myself doing it, just be like, wow, I just did that thing and I'm sorry about that. Let's move on. So I do apologize these days when I notice myself doing it because I think that it's important for me to acknowledge to other people that I made that mistake and I'm sorry. But then I move on. And I think my hope is that over time, it'll make at least a little bit of a difference in how I perceive people. I think it goes back to your second prescriptive, which is make a conscious effort to step across. I think part of stepping across is admitting that there's something to step across of and, like you said, apologize when it might happen. you may have offended, whether it's face-to-face or digitally somehow via email or something passive, it gives you a chance to apologize right then and there and kind of bring it

back to even to a degree and hopefully have made a friend versus an enemy. Yeah. And I worry less about offending people. I worry more about alienating them. Yeah. I think that we've got these people coming into the community now and we are, you know, it would be very easy for them to have a couple of bad experiences and say, you know, screw this. I'm going to go back to being an economics professor

or whatever it is. And I think that that's, that's the thing that I worry about. I worry about alienating these people that we really, really want here. Absolutely. I think related to that, when we talk about the business case, because sometimes we have to appeal to our basest desires, which is to make more money. And I think at the end of the day, there's, of course, the social and the moral reasons of fighting towards these equalities. But there's also a strong business case for diversity inside your company, which you link to in your article. Do you want to touch on that real quick? Yeah, it's interesting. There's been a bunch of interesting scientific research around the fact that if what you are doing could be considered creative, which means that there's more than one way to solve a problem, which, you know, sounds a lot like programming to me, then often your creative problem solving

process will benefit from a team that is diverse. And they may not even look on paper as qualified as a team that is less diverse, but they will routinely do better. And I think that that's fascinating. There's also been some interesting research around things like startups that have women on the board are routinely more successful and things along those lines. So there's a growing body of research that says that anytime you're doing something creative, which includes, in my opinion, programming and creating products, a more diverse team is actually going to get you a better outcome. Absolutely. You also mentioned, Sarah, I can't remember, was it in the pre-call or was it in the early call? You mentioned your article, Pairing with Junior Developers. I also wanted to talk quickly about this because it sort of bleeds into what you do at DevMind and what you

do at RailsBridge. How does all this play out, I guess, in what it means to pair with junior developers? That was a huge article for you and even, DevMind, 29,234 views. So congrats on that. Yeah, in two months, which is more than I was expecting, for sure. It's interesting because the Ruby community is an interesting place right now because we are the vanguard for all of these new folks coming in from these code schools. And so we are figuring out a bunch of stuff such as how do you work with someone that's junior? What cultural changes do you need to make within your team in order to be able to welcome a junior person into the team? And what code-based changes do you need to make in order to be able to welcome a junior person into your team? And so that

post was basically my first set of steps of like, here's what you need to do. Here's how you need to think about it when you're working with someone who's junior. And we've had a bunch of different apprentices at DevMind. In fact, we're hiring more apprentices right now. And the interesting thing about it is that it really has changed both how we organize our teams and how we actually write software. And maybe that's a subject for another post. What, you mentioned some job opportunities at DevMind. Where can someone go? Is it slash jobs, devmind.com slash jobs? That might be it. Yes.

D-E-V-M-Y-N-D.com slash jobs. I'm asking you a rhetorical question since I know the answer. That might be it, yes. And you also mentioned your apprenticeship as well in the same area. So if you're interested, take a peek at that. Maybe now, Jared, it's a good time to tail into some of our super awesome ending common questions. Yeah, let's start with the old saw. Sarah, please tell us, who is your programming hero? Who is my programming hero? You can't pick just one. I know, there's so many, right? We'll let you pick a couple.

So I've always been inspired by Grace Hopper, who I'm sure you're familiar with, who mainly because she became a programmer at the age of 39. Wow. She did all of her best work in her forties. And as someone who is heading into that direction at this point in my life, we have a mythos in our culture that all of the best work is done by young people, that everyone's best work is done by the time of 25. So one of the things that I love about her story is that that shows it's really not true. All of the amazing work she did with the compilers and so on was all done in her forties. And that gives me hope, I guess,

as someone who's getting there that that may be my best work isn't behind me. Yeah. I don't subscribe to that rule of thought either. I'm a, you know, I'm post 25. I'm actually next month? This month. Jeez, in a few days. Matter of fact, next week is my birthday. Happy birthday, bro. On the same day. I turned 36. Yeah, over the hill, dude.

That's the thing. Your best work is behind you. Oh, man, my best work. My best work. I was a terrible, terrible programmer when I was 25. I was too. That's the amazing thing. I mean,

I don't know. Thank God for amazing Grace Hopper to show us the way. Awesome. Well, another closing question that we ask. We have to adjust it a little bit. Usually we ask, what's a call to arms or something you would say to the open source community with regard to

some project that you're working on? But in the case of Mining the Gap, I guess here's an opportunity for you, Sarah, to have a call to arms to those listening out there, how they can help you and us in this effort. What would you say? I would say the first thing that you can do is to volunteer at a Rails Bridge workshop or a Rails Girls workshop or any of these other things, or even at one of the code schools that's working with diverse students. Start to meet people that are programmers that are not who you're used to looking at. Just meeting them and even just

for a day, even just going in and doing RailsBridge for a day is actually an incredibly eye-opening experience. It was for me anyway. And people continue to tell me that that is one of their favorite things about it is that they meet people that are so different from the folks that they encounter every day in their work. You know, that brings to mind, how can someone take part in a Rails bridge? So you mentioned you got Mobile Bridge now, you got Closure Bridge. What's the easiest way to find out what's happening in that community at large and in those micro communities as it relates to a certain language or a certain camp? That's an interesting question.

We've actually been thinking about that quite a bit ourselves. Right now, the best way is to look at Bridgetroll, which I think it's bridgetroll.org. Although, don't quote me on that. But that's where we have all of the workshops that are coming up in all of the different bridges. And we've been thinking about how we can evangelize both the individual communities, but also, you know, get other communities interested in doing this type of thing. And we've got some ideas in that, in that direction, but we haven't quite put anything into action yet. But so for now,

Bridge Troll is the best way to find out what's happening. Just to confirm for everyone, it is bridgetroll.orgorg so just like you would spell bridge and just like it's spelled troll bridgetroll.org uh i like that i like the the the troll too he's he's very shrek like yeah he's a friendly troll he is you know it doesn't bite exactly um. Let's see. The next one we should ask, I'm looking through it. I guess this one fits no matter what, no matter who you are. What's on your open source radar? If you had a weekend to hack on something, what would it be? Would it be a new language?

Would it be a new framework? Would it be curriculum? What would it be for you? So one of the things I've been realizing recently is that I look at a lot of Rails apps. Being a consultant and being someone that goes in and tends to go into projects that are already going, already a going concern, I see a lot of different code bases, but they tend to all be Rails apps. And one of the most interesting things happened to me last week. I was on vacation and I paired on fixing an RSpec bug with Sam Pippin, who's a member of the RSpec core team. And looking at the RSpec, the interior of

the RSpec code base was amazing because all of my assumptions that I carry with me from Rails apps about what makes good code are all wrong. It was really amazing. And so I think at this point, what I would do is I would want to look at more, look at RSpecs more, look at other gems and the interior of them and just try and figure out like, what are the different assumptions that they have that lead to such structurally different code? Well, if you do that, you should write about it. So I can read about your findings that'd be spectacular I've done a conference talk about that before actually but maybe I should write it down did that get on video is it online somewhere I think that was that's the one that I did at Nickel City actually

so I think it is on ConFreaks you know something that you just mentioned there, too, Jared, reminded me of a whole different post, but something in the same vein, and maybe we can spend a minute on this, or if you've got an opinion, was that even conference talks from those who are often judged or biased against or towards, I'm not really sure the best way to sort of say that, but are apprehensive about giving a talk because it often ends up on video. There's some sort of like, you know, always this artifact where you just want to sort of meet in person. And I even saw Jan Leonard the other day talked about,

I can't recall which conference, but it was super neat, was how they had colored bands. You might know this for Yes, I can't recall which conference, but it was super neat, was how they had colored bands. You might know this. For Yes, You Can Take Pictures of Me, maybe If You Ask Me, You Can Take a Picture of Me, or No, Not at All. And they had different colored lanyards based on, you know, how you felt about showing who you are or just, I guess, showing your face or, you know, in public. But having this artifact that sort of lives beyond

conferences, what do you feel about the thought of someone possibly not giving a proposal because they don't want to be on camera? That is a really interesting thing. You know, for some people, there's definitely some safety issues involved, right? You know, for example, someone has, you know, an abusive ex-spouse or something, you know, things like that, where they just don't want to end up even in, you know, even in sort of incidental photos of the conference. And beyond that, I think that it's good for us to support different ways of being at a conference.

I think that, you know, it's always the's always the case that if we want to talk, we can always... Whether or not it's on video can always be a point of negotiation. So obviously as a conference organizer, we'd love to have all of the talks on video so that we can use them to promote next year's conference. However, it's not required. I think that we would be missing out on a bunch of talks if we made it mandatory to have them be filmed. So as much as I would love to have films of every single talk, I don't know if you've looked at the ConFreak site recently, but there's like thousands of them already there. So I think it's, you know, if you want to do a conference talk, but you don't want it to be recorded, it's certainly something that

you can ask the organizer about. Yeah. I think that's the point there too, is just being able to, you know, sometimes when you're newer to a community, you feel like you have less authority or less ability. And I think part of that is an invitation, sort of an open invitation to the world. Hey, if you're coming to one of my conferences or conferences I'm involved in, if you can't go to the organizer, come to me directly. And if you have some concerns, we'll figure it out. Yeah, absolutely. I think that's the point there. Well, Sarah, it was definitely great having you on the show. I know we had a little bit of rescheduling there, but with your travel back from Denver and London and everywhere you've been, where have you been out recently? Last three weeks.

Let's see. I was in Denver last week, and then the week before that, I had a week at home, and then I was in Chicago, and then I had a week at home, and then I was in Melbourne, Australia for Ruby Conf at U. And you have a daughter too, right? I do. I have two kids, actually. I have a daughter and a son. Does either of them travel with you? I'm actually about to go on my first conference trip with my daughter who's nine. We're going to go to New York. So very excited.

Good old New York. Yes. Well, it's been, it's definitely been fun having you. Thanks to Matt too. One of our members who suggested the conversation to have with you, Minding the Gap, but definitely enjoy the article in this fun having you. Thanks to Matt, too, one of our members who suggested the conversation to have with you, Minding the Gap. I definitely enjoyed the article in this conversation with you. Is there anything we can do towards RailsBridge or anything around the things you're doing? Anything you want to mention as we're closing and how to connect with you? Any ways I can step into RailsBridge or anything like that whatsoever?

Yeah, RailsBridge is an open source organization in that we publish all of our stuff on GitHub and that anyone can pick it up and do a workshop where they are. And so we are trying to expand geographically. So if you are living in a place where you think a Rails Bridge workshop would be useful, do get in touch with me. You can find email and so on. I believe if you look at my Twitter account, you'll eventually find my email. And definitely get in touch because we are looking at doing some geographical expansion in 2015. So when you say all of your stuff is on the GitHub, you mean curriculum, right? The curriculum, all of our notes for running a conference, sorry, a workshop. We actually organize all of the workshops through GitHub issues. So you can actually see workshops being organized.

We do most of our things like board meeting notes and so on also through GitHub issues. So we actually make fairly heavy use, non-traditional use, you might say, of GitHub in order to have a very open process. Awesome. Well, Sarah, it has been a pleasure. We'll link up your Twitter and your GitHub on the show notes. So if you're a listener, go to the show notes for the show. It's episode 146.

Get links out to Sarah and all the stuff we've talked about today. So if you've got any questions whatsoever, don't worry about trying to jot down the link while you're trying to drive and listen to this podcast. Just head to the show notes. They're going to be there uh and with that everybody let's uh let's go ahead and call this a show and say goodbye all right well thank you so much for having me thanks for coming on sarah appreciate it Outro Music