In the software field, we pride ourselves on fairness, openness, and the fact that our workplaces are largely meritocracies. And compared to other environments, I would say this is certainly true. It's one of the reasons I love being a developer. And yet, if we look at programming jobs in Silicon Valley, you'll see that over 85% of them are filled by men, which means that less than 15% are filled by women. If we look at it from a race perspective, it's even more bleak.
Among the major tech companies like Google, Twitter, and LinkedIn, you'll see that over 90% of the employees are either white or Asian. Black and Hispanics combined make up less than 4% of the total employees, and it's probably an even smaller percent among developers within those companies. Given that they represent 28% of the U.S. population, this means that there are seven times
fewer black and Hispanic developers than there should be. Folks, this is wrong. We should all be doing what we can to help improve this balance, as it's not just the right thing to do, but we individually and as an industry will be better for it. This week, you'll meet Kate Hedleston, who gave an excellent talk at 2015 entitled, how our engineering environments are killing diversity and how we can fix it. What's
great about this is that it comes with ideas for improving things. I think you'll enjoy this conversation. I know that I did. This is Talk Python To Me, episode 55, recorded April 20th, 2016. Welcome to Talk Python To Me, a weekly podcast on Python, the language, the libraries, the ecosystem, and the personalities. This is your host, Michael Kennedy. Follow me on Twitter where I'm at, mkennedy. Keep up with the show and listen to past episodes at talkpython.fm and follow the show on
Twitter via at Talk Python. This episode is brought to you by SnapCI and Hired. Thank them for supporting the show on Twitter via at snap underscore CI and at Hired underscore HQ. Kate, welcome to the show. Hi, thank you for having me. Oh, I'm really excited about our topic today. We're going to talk about creating, reinforcing positive environments for programmers. That's going to be great. Yeah, I'm super excited. Yeah, yeah, cool. I saw you talk at PyCon and I'm really excited to share it
with my audience. But before we get into that, let's talk about your story. How'd you get into Python and programming? So I got into programming back in college. My brother is four years older than me, and he studied computer science and electrical engineering. And he told me that everyone who studies CS gets a job no matter how mediocre their grades are, because everyone's in desperate need of developers. And I was like, I can manage mediocrity. And so I tried out a few things. And then I took
an introductory computer science class. And I really enjoyed the material. And it turned out throughout the whole degree, regardless of kind of what grades I was getting. I really enjoyed the material. And that to me was a great sign. That's really cool. What was your first course in? What language? It was Java? Yeah, yeah. Yeah, yeah. Cool. Mine was Scheme. I'm glad to see Python sort of replacing some of these languages, a little more practical and easy to learn.
I'm so jealous of colleges that teach Python as an introductory language. But I think getting exposure to Java, and we went on to C++, and then C, I think that that was a really good background. Yeah, nice. So how do you go from Java and C into Python? You start working in web development out in the real world. And it turns out that in the real world, people are like, yes, yes, computer science languages are nice. But really, we need the thing
that's easiest for us to build something and maintain it. And it turns out Python is a really great maintainable language, you can build out entire engineering teams that use Python to build really robust technologies. And that is more important when you're actually building companies, then I don't know, using some obscure language that is technically better on some minute detail.
Right, right. You know what I find really interesting, and it's been admittedly a while since I've been in college, but just the disconnect between the academic environment and the sort of software engineer professional environment, it seems like there's still a pretty big step change as you go across that, which is kind of surprising, I guess. Yeah, it's kind of like, I felt this way about math, too. I got I loved math. And then I got to
college, and it turned into symbols. And I was like, this isn't as much fun anymore. Like I liked having numbers at the end. And so that I could academia, it's, it's great to know the theory. But there's a certain point at which I was like, I'm much more motivated by the goals around why I'm building something. And if I need to go learn the theory around, you know, why something should be
implemented a certain way, I'll do it. But I care more about the problem that's being solved than just learning academic things for the sake of knowing academic things. Right. It's interesting to understand how you would create a relational database. But if you actually went and did that, you might be kind of crazy and wasting your time, right? Yeah, like I'm not interested. That was never my personal interest. I like,
I like building things that people use. And so programming to me is a tool that allows me to solve human problems. And there's a whole camp of developers who love to build technical things for purely technical reasons, which is fantastic. I just don't happen to be one of them. Yeah, I don't think I would count myself in that space, either. I think, you know, people who are not in programming often think about programming as a solitary thing. And it's really not. And there's
lots of layers to that, right? Like, we were talking about your blog, and, you know, apps you write, and web apps, and so on. And you can reach 100,000 people quite quickly, you know, if you're lucky, right, with programming. And that's, you know, there are not many specialties or jobs that you get that power, right, especially as an individual, but also as teams, I think it's really interesting. And so maybe that's a good segue to talk about these environments, right? So what's the story behind
your PyCon talk? And what was the title for everyone? The title was a bit sensationalist. It's how our engineering environments are killing diversity and how we can fix it. You know, a little bit of pessimism, a little bit of optimism. I actually do believe that the problems that are facing, that are causing kind of like these diversity issues, I believe that they're solvable. But I do think that we need to start to take a look at kind of the
environmental and institutional problems that exist. You know, traditionally, a lot of people think of sexism or racism as one individual person being unkind towards another individual person in some sort of obvious way. And it's very rarely the case that that's what it looks like at scale. It's a whole bunch of little tiny details that kind of come from this environment and this institution that we set up. And everyone perpetuates it. And everyone has a hand in creating these environments
that hurt some people more than others. And so yeah, that's the theory behind it. Yeah, and they might not necessarily be, you know, have malice in their intent, right? They just, they might have negative effects that are not fully thought through or fully obvious. Exactly. And that was my audience that I wanted to reach is there's a lot of people who have really
good intentions, but they don't actually know how to make things better. Because it's really, really difficult to isolate some of these almost invisible problems, you know, they've become such a
fabric of the environments that we're in that they become really difficult to see. That's what I wanted to do with each one of these is kind of isolate, like a core, fairly nuanced problem that can be solved, that will actually have positive impacts on the environment and how diverse people are able to operate in that environment.
Yeah, and I think some tips for people on things, you know, actual steps they can take would be helpful, because environment and culture, especially as companies get larger and organizations get larger, it's just so super hard to even influence, right? You go to some company like, well, this is what it's like here. Like, I'm only one person out of this group, how am I supposed to change this, right? And I'm new, you know, something like that, right?
Yeah. Or just, you know, if you haven't experienced some of these problems, it would be really hard to identify them. And I know that there's a lot of rhetoric around, you know, how things need to change. And a lot of people have bought into that. And then the next question, especially for me, as a software
engineer, I'm like, okay, great, we're going to do this. How do we implement it? You know, and that was, I think that's where a lot of this movement right now is kind of stalling is like, what are all the, if diversity issues are death by 1000 paper cuts, how can we get rid of a few paper cuts at a time, basically? Yeah, yeah, absolutely. I think as I look across the industry, I know, you know, you can't make
complete generalizations, but I think most people are super good intentioned. But you know, they don't know what to do or how to make a change, or even that there is something that should change, right? So you have a really interesting story, analogy, a couple of analogies you started your talk with, and one of them was about mining. Can you tell that? Yeah, so basically, I wrote this in one of those moments of just like, sassiness. I was like,
women in tech, and marginalized groups in tech are the canary in the coal mine. And the canary in the coal mine was used to indicate to miners when there's too much non oxygen gases in the mines. So basically, canaries were more sensitive to things like carbon monoxide and other types of gas poisoning, and they would start to die before the miners were affected. And so if the canary was
dying, you need to get the hell out of the mine. But in tech, if these marginalized groups are the canary in the coal mine, instead of recognizing that there's a huge problem, people are telling the canaries to lean in, and, you know, replacing dead canaries with new canaries thinking, well,
if we just get more canaries in here, that will fix the problem. And that's not true. Like, if you think about it as an environmental thing, you have to look at what's actually killing the canaries, as opposed to looking at the canaries as the problem themselves. Maybe we need more efficient logistics to bring in new canaries. Truckloads of canaries. I'm totally, I'm sure that that will fix the problem with the mines.
Yeah, and it was just, I don't know, I do, a Sheryl Sandberg's book Lean In I did really like, but as with any piece of literature, and ideology, it can be used both for positive and for negative. And so, you know, sometimes there are problems that, like, marginalized groups themselves can try to fix. Other times, telling these groups to lean in is a little bit like telling a canary that's dying that it just needs to lean in a little bit more. Just breathe harder, canaries.
Just breathe harder. I'm sure that you can make it. And so, I think we need to be really conscious, too, when we look at kind of the ideologies and what we tell people to do in the workplace to improve their station. I think we need to be really careful that we're not putting the onus on these individuals who are in these environments and
these institutions that are perpetuating kind of systems that aren't fair. And then saying, well, if you just worked harder, like, if you just did, if you just followed this list, you could be successful. I think that's a really interesting point. I think that scales up and down society, right? Across getting, being more successful than your parents, potentially, or the situation you found yourself in. But the one that we have control over, the part of society that we have the most
control over is our engineering environments. And so, right, like, applying that idea there, there's really cool. So, you started out by talking about your environment. And you had two great analogies, I thought. One was around how the environment is kind of, you just acclimate to things. You know, I think it's, that resonates with me really well. Like, eight months ago, I moved to Germany Germany and spent a lot of time here. And when I first got here, it was like, everything was new
and everything was different. And the sounds and the smells and the sights. And now, you know, I barely notice, like, people walk by, I'm like, was that in English or German? I kind of understood what they said, but I don't even actually notice the language. You know, it just, it becomes, no matter how different it is, at first, it becomes natural in a sense. So, you have this story about fish, right?
Yeah, it's a David Foster Wallace quote. It's a, it's a story that he told giving a keynote speech. There are these two young fish swimming along, and they happen to meet an older fish swimming the other way, who nods at them and says, morning, boys, how's the water? And the two young fish swim on for a bit. And then eventually, one of them looks at the other and goes, what the hell is water?
He tells it, he tells it really well. It's, his whole piece on that is amazing to listen to. It's about, it's basically about consciousness, being conscious of the world around you and the environment and the fact that people probably have legitimate motivations for what they're doing. Yeah, that's cool. It's, it's great. But yeah, I mean, for all of us, right? Like, we get acclimated to our environments. It's, it's a lot of work to be conscious of every detail.
Yeah, that's how your brain basically lets you cope and actually think about stuff, right? If you had to pay attention to everything, you didn't just sort of go on autopilot for, you know, the normal stuff, then you wouldn't be able to get anything done. You're just like, you're like, oh my gosh, there's a door. Oh, look, there's a window. Like, no, go back to what you're doing. The doorknob is gold. Look at that. Wow. It's amazing.
It's why when you travel and you have all of these overwhelming new details, that time feels really long. I don't know if you've ever felt that where like, if you're paying attention to every second, you're like, time is moving very slowly. Yeah, I think that's a great analogy for like, our environment that we live in just fades to the
background. And it, it has an effect on us, right? Like whether or not we're always inside, or we get to go out and get the sun, you know, get exposed to the sun and fresh air, whatever that is that we do, we just that becomes normal, but it still affects us in our day to day, right? So you started talking about things that are common in engineering and software environments that are not necessarily
positive, right? So you had a list of them that you, you talked about, and you talked a little bit more in your blog post series. But the first one was criticism. Yeah, that one was the most popular blog post by far. It resonated with a lot of people completely
outside of the tech industry as well. The reason that I kind of discovered, discovered, I mean, most of the things, I should clarify this, most of the things that I'm talking about are not new ideas, I have found them from other places and kind of piece them together to write about the engineering culture specifically. But you know, you can find a lot of literature on
criticism. And so one of the things I noticed, though, in engineering cultures is that being critical of other people or of other libraries and frameworks is kind of seen as this badge of honor. there were these habits that I saw people having where, where they would really make fun of, of other people's work, as though that was appropriate. And at first, I was like, Oh,
that's just how things are done. We're gonna make fun of this, this library. And I had this kind of aha moments about criticism when I met the creator of a library that we had used at my company. And we had used it, and it didn't work out for us. And we pulled it out. And when we were pulling the library out, the engineers who were doing it were just they would just rip on it. They would just sit there and like absolutely rag on this library and why it was like the worst library that had ever
been written. And I had just met the creator at a conference the week before. And I remember sitting in that meeting going, Oh, my God, this is horrible behavior. This is this is really, really mean. And this is not okay. Why is this such a habit in engineering culture? And why do we take it for granted that we should, that we can walk around being really critical of other people's work? Yeah, it was just it was one of those moments where I woke up.
Yeah, sure. I imagine. And you're probably thinking, well, this person was really nice, and they seem smart. And then here we are just completely deriding them sort of through their work, not directly, but more or less, right? Right. And, and every piece of code is just, it's just one person's opinion about how a problem should be solved. And if you held me accountable for every opinion that I had ever had, like, man, that would be brutal.
Yeah, yeah, it absolutely would for all of us, I'm sure, you know, just on focusing on the code part of it for a moment, I think two things. One, you know, maybe that library was written with different constraints than it was trying to be put under, right? And so it might completely nail some problem, and it doesn't necessarily fit here. And so it should, you know, maybe a little hubris, and like a broader picture of the library. I, you know, we don't want to judge it, right? Like,
it doesn't make sense to do that. But just thinking like, well, maybe this was written under different pressure. And for that, that pressure really solves it well. Right, right. Yeah. And the other thing, the other thought that comes to mind is, we in the software industry, I think, pride ourselves on the fact that we try to make this a meritocracy, right? It's about the
quality of what we do. And I think you see that in a lot of ways. You see that in like hiring and experience, like somebody who went to a boot camp versus somebody who has a PhD, if their work that they can demonstrate to you is very similar, those people are basically considered equivalent, right? Because it's not, you know, the degrees you have or whatever. It's like, what can you do?
Awesome. But this is what you have to bring, right? And that's really a positive thing. But maybe there's something about where, because it's a meritocracy, people feel like if they attack a thing like that, they're attacking the idea of it, and that they get sort of disconnected from the real person, or the real feelings behind it. I don't know, that's just, what do you think? Yeah. And I mean, it's interesting, I think that we have internalized this ideology that,
that we are somehow fair, that it is somehow a meritocracy. And it's, that's, it's not entirely true, right? We're more likely to criticize libraries that people have built when that person is not present. Companies are still far more likely to hire someone who's a PhD and pay them more, and believe that they have more potential over their lifetime as an employee than someone who comes
out of a boot camp. And so it's interesting to kind of see these things and how they manifest. And one of the things I found is that you can really see the cracks in the system when you start to look at how, how people are treated kind of the less privileged that they have. A lot of these environmental factors that we talk about, one of the reasons that they hurt kind of marginalized groups more is that privilege is a shield. It's like, it's like armor. And the more privilege you have,
the more armor you have. And so some of these little environmental things aren't going to hurt you. And I've seen this, like, with my male friends, my boyfriend, my brother, right? You know, we'd be in the same environment. And I would be having a very different experience than they were having. And, and so, you know, when it comes to things like criticism, it turns out that people are far more likely to criticize women than men. They've done a bunch of research on it, people feel
much more comfortable. And we see this out in society as well, people are much more comfortable criticizing women's appearance, women's eating habits, like all sorts of things. And this translates into the workplace, people are much more comfortable criticizing women. And it has really negative effects, because it turns out that all humans, regardless of what they look like on the outside,
really hate criticism, we really don't do well with it. As soon as someone starts to criticize us, we go into kind of this defensive fight or flight mode, we hyper focus on the criticism and the negative things that we've been told, we're less likely to progress in positive ways. And again, this is true across, across genders, across races. And one of my blog posts on criticism and ineffective feedback
goes through some of the research about how that happens to people. But, you know, the biggest issue is if, if different groups are getting more criticism, mostly because they have less protection, then that's a huge problem. That's like a lot of subconscious bias going on right there. And so it's really difficult for people who are receiving less criticism to see that other people might in private instances be receiving more criticism, and kind of what those negative effects are.
Gone are the days of tweaking your server, merging your code, and just hoping it works in your production environment. With SnapCI's cloud-based, hosted, continuous delivery tool, you simply do a git push, and they auto-detect and run all the necessary tests through their multi-stage pipelines. Something fails, you can even debug it directly in the browser. With a one-click deployment that you can do from your desk or from 30,000 feet in the air, Snap offers flexibility and ease of mind.
Imagine all the time you'll save. Thanks SnapCI for sponsoring this episode by trying them for free at snap.ci slash talkpython. Yeah, that makes perfect sense to me. I personally hate criticism. I respond badly to it. I mean, constructive criticism is maybe one thing. I still don't like it. I try to learn from it or whatever. But, you know, one of my theories about work and careers is that we kind of go along more or less flat doing things,
and then we get inspired about something at some point. And you kind of do this step function jump of like, oh my gosh, I'm going to do this thing that I didn't think I could do or whatever. And you go and do that. And to me, constant criticism sort of kills inspiration. And I think inspiration is one of the things that really helps us grow in creative type endeavors. Yeah, yeah, absolutely. And you're not alone. Everyone, like literally everyone hates criticism.
There's no one out there. And if anyone's like, yes, I love criticism and do really well with it, you should be like, well, shut up. Like, we don't need critical environments just because you for some reason have figured out a way to not care about other people's criticism. One of the ways that I discovered this is back when I was coaching sports. So I used to coach JV girls water polo and swimming. I found that when I told the girls I was coaching what not to do, they completely shut off.
They basically, they looked at me, they had no idea what to do. They felt bad because they had done something wrong. Because when you tell someone what they're doing wrong, essentially, you're just, you're criticizing them, you're pointing out this flaw. And I saw none of the behavior that I wanted, which is I really wanted them to be, you know, more aggressive to go, go for things and, and to try harder. And instead, you know,
I saw them just shutting down. And so I switched all of my language over. And I was like, okay, well, I'm going to keep yelling at them from the pool deck, but I'm going to yell at them all of the things that I want them to do. So keep your elbow up. Keep your, keep your hips on top of the water. Swim faster. I yelled swim faster a lot at them. As a result of that, I saw exactly the behavior that I wanted, which is that if you tell people what to do, and you have good reasons for them doing it,
they're likely to do it. And they're likely to actually be pretty happy and pretty excited about doing it. And so there is a positive way to actually give people feedback and to motivate them in the right direction. And it generally doesn't involve telling them the things they're doing wrong. That, that really resonates with me. And, you know, thinking of things like code review or discussing in a group sort of whiteboarding architecture considerations and so on. I think,
I think there's a lot of ways in which you can make that positive as well, right? Instead of going, oh, this code you wrote here sucks. Do you know how inefficient range is for this much data in Python 2.7 or whatever? Like, why are you not using X range or, you know, some stupid thing like this, right? Like you could say like, look, this is a really good code you wrote, but if you actually did
this, you could actually make it better in this way or that way. Right? I think it, it sounds small, but I think, especially when you're new, like if you've been programmed for 20 years, you're like, yeah, whatever. Right. If that's your first year, especially, you know, like you're talking about people coming into the industry and then leaving, right? If that's your first year or two getting into the industry and your experiences, people criticize you all the time. Like, okay, that's not fun.
Right. Exactly. And also when you're new, you can't make those cognitive leaps. So someone with 20 years of experience, if someone goes, your code is really inefficient, they would look at it and they would theoretically have all of the tools and experience to go, okay, well, here's all the ways my code is
inefficient. And someone who's new doesn't have those tools. So saying your code is inefficient, you're coming in with this, this assumption that they were somehow bad because they wanted to be bad. When in fact, most of the time people are trying to do their best with only a rarefying few exceptions. And so if you're like, okay, Hey, like, I think that this would make your code more efficient.
Most of the time people are, are receptive to that kind of dialogue. It's not criticism. It's, it's like a, I think your code would be more efficient. Mentoring. Yeah. It's like mentoring or support or something like this, right? Which is, I think, really positively seen. Yeah. Yeah. So the first thing we should probably be on the lookout for, get it out of the water category and into the more like, Hey, there's something to do is like criticism, right? And across the board
in a lot of ways and how we can turn that on its head positively. The other one is arguing, right? Like argument culture, like we're going to basically, I think this sort of orbits around the meritocracy as well, right? My idea of how this problem should be solved or what to do next and your idea, they're going to fight. And the winning one, Darwin style is going to become our application.
Yes. And of course the ideological fight between these two concepts is pure and it's, it's completely based on the merit and the logic behind each of those concepts, right? Yeah. Maybe until it goes through human beings and has to come out with like, exactly until humans are involved in it. It has almost nothing to do with the logic. One of the things I always tell new engineers and even new engineering managers is that
being right matters very little with humans. So most of what you do is you spend time managing people's emotions and dealing with egos and argument cultures are really indicative of environments that kind of let people be too emotional actually in their discussions, which is funny because generally when people are telling someone they're being too emotional, that's criticism that's levied against women. I can't tell you the number of times that I have been very passionate about an idea and
been told you seem really emotional right now. You seem very frustrated. And I'm like, yeah, that's, that's horrible.
I'm like, I do. I have emotions right now. I can name all of them. Can you name yours? Like, um, and that's part of the problem is that we, we actually, we don't value emotional literacy as much as we should, but we have these environments that really allow people to try to express ideas and to win arguments using a lot of emotional manipulation tactics and aggression is one of them. arguments where you raise your voice, you use your size, you yell at someone, you insult them.
I mean, these are all like non-logical emotional tactics to try to win an argument that have nothing to do with the merit of your idea. And, unfortunately you see those tactics again, used against people who have less kind of privilege and less defense against them. Right. And even maybe physical stuff on your side, right? Like if, if you're a woman, you're on average, probably smaller than the guys. Right.
Maybe yell less loudly. I don't know. And so just, these are not necessarily a nice matchups, I guess, to put, use a bad analogy. So you, you talked about some really interesting places in society where argument culture is deeply embraced. One was the legal, legal courtroom area. And what was the other one? I don't recall. Maybe they both are the same. Arguments are kind of tantamount to competition, which is embraced in the legal system, uses arguments as
a form of competition and, and sports. They don't use arguments, but basically sports are the classic arenas for, for competition. Right. And the real big difference you pointed out was those have rules, right? Yes. And the reason that those, those arenas are important to look at is that the goal of argument, the distinction that I make, and some people disagree with this distinction, which I mean,
is your prerogative. The distinction that I make to clarify is that an argument is an exchange in which winning is the primary objective is the primary objective. And so those can look different. So I could be having a very passionate discussion with someone because there's equal trust on both sides. We're, we're actually trying to come to a common truth. and that's a discussion. And an argument though,
is where one party wants to win or both parties want to win. And the problem with winning being the goal is that people will engage in really bad behavior in order to win. So cheating, lying, uh, and that means that you need really strict rules around how people are allowed to argue. So the legal system obviously has a very strict system with how each side is able to present its argument, the types of words that are allowed to be used theoretically, how much they are allowed to
attack or not attack people who are participating in the case. There's a judge who presides over it. I mean, there's a lot of rules around a system of arguing. similarly in sports, you've got refs, you've got, no, they have a little less policing than they probably should have, but they, they have a pretty strict system of rules, right? and people still cheat. You have a instant replay and you can actually have like a, a television review of being like
up close in super slow mo, right? Like it is. Yeah. And it just, you break the rule a little bit, like no, the little bit of dust was kicked up as they stepped on the line. So we know this doesn't sound right. Right. And people are very strict about it. And even still though, you mean you have, what was it? Deflegate the deflated football controversy, which I mean, I can't comment on what happened, but like, I mean, there's still these massive controversies around cheating or lying or
lawyers being unethical. and so, you know, those rules have, have proven to be very important. And cause even if it's only a small percentage of people who are willing to lie and cheat, my joke about this is how many assholes does it take to ruin the workplace? Like one, it takes one. Yeah. Yeah. One, maybe two, depending on how big the workplace is. But yeah, it's, it's a very,
it's a very small number actually. so you really only need someone, one person being one, two people in your proximity being really aggressive and being, you know, really kind of unkind and in the pursuit of, of winning to make it a really miserable workplace for a lot of people. The major essence of that, I think, as you pointed out is that there's no, or very limited regulation and monitoring of sort of these types of arguments. You just, you had a meeting for two
hours. We all got into the conference room and argued about how we're going to build the next app. And then we decided. Yeah. And if someone's winning and they're willing to be unethical, then they're going to use kind of whatever weapons they have against you. And it turns out that the marginalized groups in tech, there's a lot more things that can be weaponized against them. So, you know, for women, the example
is emotions. Like when someone was like, Kate, you seem really frustrated. That's a way of weaponizing this idea that women can be inherently too emotional to be logical. That like emotions undermine logic, which is super funny because it turns out that you actually need emotions to make decisions. So if the emotional part of your, your brain is compromised, you become incapable of making decisions. So every decision is emotional, like period, whether you're male or female or whatever
it is. but it's a weapon that can be used against one group that, that isn't, isn't something that's used against the other group. And so you start to see these kind of like tiered systems of how fair or unfair it is for someone to kind of try to move up in that environment. One of the things, you know, in a real broad sense, I could say, well, how can we make this part of environments better? It's like, you know, argue less, right? But do you have a more
concrete advice than that? Like what should people do? Yeah, I would say like, there's a couple of different things you can do. The first is try to have a culture of discussions where the idea is finding the best solution for everyone. you know, a lot of companies try to do this, they call it Eagle list programming. So you basically set up a system where you do actually have rules and you reward people for discussing and acknowledging other
people's ideas, for really bringing up data that supports their ideas. And then you have to have some sort of system that deters or punishes people from using things like loudness and size and aggression in order to get their point, their, their ideas pushed through setting up rules around how you make decisions and how you communicate is not a bad thing. And there's a bunch of research out there on
things like brainstorms, setting up brainstorms, which is a certain type of discussion. And then as you converge and make decisions, kind of like setting up rules about how decisions are made so that it's the same every time. And people understand how to operate within the system is actually, I think, healthy for everyone. And it's, it's a good practice within companies and it would greatly reduce this kind of behavior. so you wouldn't actually have to worry about it.
That's way better than what I was thinking maybe is hire a bunch of lawyers to sit with all your programmers to judge. So the next, the next topic that you, brought up or the next point in the environment was about bringing people onto the team and this concept of team debt. Like we're all familiar with technical debt where we kind of rush through writing code and we make shortcuts for the sake of expediency. And then our software acquires this debt where it's, it's kind of,
it's kind of bad. There's something wrong with it, but it was worth it at the time. But if you do that too much, it'll sort of crumble down and you, you're in trouble. But what's team debt? Yeah. team debt is, is the same concept. when you build a feature, there's this idea that there's a certain amount of work that needs to be done in order for the feature to be truly finished.
And if you ship the feature prior to, you know, all of the monitoring and all of the testing and kind of all of the optimizations finished, then you have accrued technical debt and that will catch up with you at some point. team debt is the same idea that when you hire an engineer or, or a team member, in any department, there's a certain amount of work that needs to be done for them to be a
fully integrated, productive, happy, functional member of this team. And any amount less than that accrues as team debt. This episode is brought to you by hired hired is a two-sided curated marketplace that connects the world's knowledge workers to the best opportunities. Each offer you receive has salary and equity presented right up front, and you can view the offers to accept or reject them before you even
talk to the company. Typically candidates receive five or more offers within the first week, and there are no obligations ever. Sounds awesome, doesn't it? Well, did I mention the signing bonus? Everyone who accepts a job from hired gets a thousand dollars signing bonus. And as talk Python listeners,
it gets way sweeter. Use the link hired.com slash talk Python to me and hired will double the signing bonus to $2,000 opportunities knocking visit hired.com slash talk Python to me and answer the call. What's really interesting about team debt is that it actually topples startups. It's not something that people talk about nearly enough. You know, we talk about how the technology can go down and how
our web applications didn't scale. And there's not enough people talking about how team debt is, is one of these major things that can bring down engineering organizations. Because if you can't scale your team of engineers, why, what are you going to do? Like, I guess maybe optimize what you have. Yeah, I think. Yeah, I guess so. But yeah, that's a really good point. That maybe is a sub specialization or sub
point of this concept of culture. And you hear about companies growing too fast and their culture comes unglued. But it's one thing to say, you know, the culture has changed and we don't quite value this thing the same way we do, as opposed to the people who actually build the stuff don't really know how to work together or how to collaborate or how all the pieces work in the system, basically, right? That's bad news.
Yeah. And one of the things I used to tell the girls I coached is that your ability to win is the sum of your talent multiplied by how well you work together as a team. So talent is just a factor of summation. But teamwork, that's a multiplication factor. So a team that's theoretically less talented could beat a team that's theoretically more talented if they work together much better. And it can be a huge factor
in the performance of a team. And so that's essentially what team debt is. It's this idea that your team is not functioning together enough to even utilize their talent. So if teamwork falls below one, suddenly, what you have as a team where the talent of the overall team is actually being underutilized. And that's a team that leads to high attrition, unhappiness, because nobody likes to be less
productive than they are capable of. I mean, it's not a fun feeling to be like, I'm totally not fulfilling my potential here. Yeah. Unfortunately, I think there's a fair number of environments where people feel that way, right? Like, it just, like you say, it kills inspiration. And it makes you feel like, well, this is definitely not a place
I want to stay, because I go to work. And instead of doing what I want to do and building amazing software, I'm like, can't get anybody to close this pull request for this feature I just finished. You know, it's easy to view that as like an optimization problem, right? Like, well, if we can get these people all this a little bit more efficient, then we can, you know, get the synergy and they're this much more efficient.
But the negative of it is, is maybe even more important, right? Like that you kill, kill the joy. Yeah, yeah, it really, it does kill a team. Everyone likes to be on a winning team. I mean, what, who really enjoys being on a losing team? I had a coach in college who was like, at the end of a game, the only thing anyone sees is the W or the L next to your team name. And I was like, do you really need to tell a group of college athletes to win? I was like,
nobody here likes losing. Nobody here is like, yeah, I think that losing today is a good option. And so, so, you know, like people want to be on winning teams, they want to be on high functioning teams, and they want to be their best, at least as far as I have seen. And so it's, it's the company and the management teams failing, if they aren't able to put in place programs that really allow
teams to function well. And onboarding is a huge part of that, because whenever you add new people to your team, the team fundamentally changes, you need to realign values, you need to make sure that everyone's on the same page so that that everyone works together really well as a team. The reason that onboarding also has kind of a diversity factor is that when there is no onboarding, no, no official onboarding, people still have to get onboarded. It's just a thing that has to happen, right?
It, onboarding is literally someone new coming on board and being integrated into the team. And so if someone doesn't get onboarded, they'll leave the company. And if there is no institutional
onboarding, people have to figure out a way to do that on their own. And it turns out that people who are more like the existing group have an easier time getting up to speed when there isn't any sort of official institutional onboarding, which means that in an industry that is mostly white and mostly male, anyone new coming on board who doesn't look like the existing group kind of falls by the wayside.
And this means in some, in some teams, this can mean parents. And depending on the team, it can also mean that an introvert coming on board, a team of extroverts is going to really
struggle to get up to speed because they're not like the existing group. And so onboarding is kind of this, it's meant to be both a training program, but also an equalizer to try to make sure that regardless of what someone looks like, when you bring a new person on board, they have more of an equal chance at success in your company.
Yeah. And when you were part of that majority group, I think this is one of the places where the water, what's water comes in really clear is like, well, people just, they come in and they just start working with us. Like, I don't know what's, what's the big deal. Why do we need to worry about this? But that's a really good point.
And you don't notice. So, you know, everyone has their, their close friends. And a lot of times, I mean, we, most people have fairly diverse friend groups, but it is easier to talk to my female friends about certain things. Like our communication styles are just, it's just easier. We've been conditioned to speak the same way. We have similar interests. We have similar intonations.
And it's one of those things where if you are the majority group, you don't really notice that someone else might be having a really hard time with kind of this, this communication style and this culture that you have that is really ingrained, not only in your ideologies, but also in like, like your interests and your communication styles. And so I've seen that a lot at companies. Yeah. Well, I agree. It would be really easy to classify that as, hey, what's wrong with this new
person, right? They just don't seem to fit in. Right. Or something like this, right? Where it's like, yeah, why don't we try that? It didn't work out. When in fact, like they might actually be a great culture fit. It's just that they're a little different. And so like, like there needs to be a little bit more work to make sure that the communication styles are, are leveled out and that they really get up to speed, that people's
hobbies and interests as individuals aren't too ingrained into the company as a whole. So I mean, I've worked at companies where they love to play video games and video games are great, but I am not a gamer. And so I was like, awesome. You spend a ton of time socializing on video games, which means that like, I'm probably never going to fit in here. Like what am I, I'm not going to hang
out with you and play video games. Like that's just not, yeah, I'm never going to fit in. And you know, whether it's across gender or just like across bizarre interests, it's important to be like really cognizant of that. Onboarding is sort of one part of like an overall set of processes within a company, right? Like how people interact, how they get raises, whether or not they're a manager, whether or not they're a sort
of engineer or so on. Right. And you said a lot of these companies, they have what you called the null process. The null process. No process is one of my favorite things. It's like such a startup cliche where a lot of people worked at companies where they didn't like some sort of process or they came from a big company. And so they believe that having no process is like a better solution to whatever bad process
they experienced. And to try to convey this idea to engineers, I was like, well, having no process is like having a null pointer. It's something that points definitively nowhere. But it can still be misused and dereferenced. If it's dereferenced incorrectly, it can point to garbage. Right. And so null processes are often kind of a subset of bad processes. Good process is really the gold standard. And good process, actually, my definition of good process is that it's lightweight. It
conveys the fewest number of steps necessary for someone to complete the process. And it's just really easy for people to access and to understand. And so one of the suggestions I give for a lot of startup processes is write checklists. Checklists are an amazing way to just write down the steps necessary to get a task done and to make them a lot more visible. Because yeah, no process, people still have to get things done. So by definition, there is a process. It's just that everyone is doing a
different thing to get this done. And there's a lot of people who have no idea what to do. And if you're really early, it might be the case that you just haven't had time. And that's fine. But don't be fooled into thinking that no process is good process. Yeah, it's kind of like, you know, hate is not necessarily the opposite of love. Like apathy is that sort of thing, right? Right. It doesn't all make it a good process just because it's you're avoiding this thing that was bad. Yeah, exactly.
You talked about automating stuff too. Like checklists are awesome because it makes it easy for to automate humans, basically. But if you could do things like automated pushes to QA. So a new person come on, make some changes and just say, hey, here's my changes. And it flows just like everybody else's. Things like that would be really helpful. Yeah, automating as much as possible. It can be hard
to know what to automate. And so that's why checklists are a good start. And then if once like the checklist is really ironed out, because I imagine that you will go through some sort of iterations on on how to get to the best process for something, if you can automate any of those steps away, to reduce the number of things that a human has to do, that is always a best case scenario. Humans are, we're wonderful, but we're, we have a really hard time remembering things. We overwhelm ourselves a
lot with a huge amount of complexity at our jobs. And anytime that you can reduce complexity and reduce the number of steps that a person has to take, that is generally a good thing. Yeah, absolutely. And if it's something that can be automated, and it has all these steps, right, like, you're probably uninspired to do those steps. So if you could, if you could make that, you know, sort of increase the joy by automating that stuff, obviously, that's, that's great.
Computers are really good at remembering steps in a sequential order. And they do them really fast. I know, they're very quick. I love computers. Computers are really good at that kind of thing. And they're really good at remembering, whereas humans are really good at pattern recognition and subjective meaning. I think a lot of these concepts that we talked about are really, you know, I've been in a lot of
companies, I think they're pretty broadly applicable for a lot of engineering teams. And so, you know, hopefully people listening out there can reflect on their version of water and see if there's something they can do to make it a little nicer. Yeah, and I see kind of engineering process and engineering culture as, as iterative, you know,
progress is it's iterative, it's imperfect, and it's incremental, right? So if, again, if, if these diversity issues are death by 1000 paper cuts, if you take away even just a small handful of paper cuts, that is progress. And I think that's a really important thing to kind of support and be positive about because it can feel really overwhelming when we talk about a lot of these issues and,
and it can kind of turn to negativity and hopelessness. And I would rather people felt inspired and encouraged to try to make whatever small differences they can make in their own companies. Yeah, I think that's a great message. So one thing I wanted to ask you about, you know, we talked about
the better logistics for Canaries. You know, there's a big push around the world in the US and as well as like England and Australia to get computer science pushed farther ahead in the sort of education space to like maybe high school has like a year of computer science, or at least it counts like a year
of math credit instead of doing something like geometry. My view in the world is we would all be better logical thinkers if we solve problems through computer science rather than by trying to prove axioms in geometry. So, you know, there's, there's definitely room in the curriculum for it.
But do you have, you know, if you view it through this lens of what we just talked about, like, do you have thoughts on that other than just, Hey, you know, more, more people getting into programming is good, but what's positive? Maybe what should we look out for in that space? Yeah, I mean, I think it's great. Like I love, I love the idea of logic and computer science being added to education early.
I have done volunteering with like four to 12 year olds for the past few years. And it turns out like you can start introducing logic pretty young. And so I think those education initiatives are great. I actually don't think that the pipeline problem is actually a lot of people focus on the pipeline when they think about getting different groups into the industry. And one of the blog posts that I am about to write is,
it's that retention, retention is the beginning of the cross generational pipeline. So it's this idea that, you know, in the 80s, we've talked about there actually used to be more like 20 or 30% women in computer science programs and out in the industry. If, and we'll use women as an example in this case, if women are unhappy and they leave the field, what do you think that means for the next generation? Who is going to convince young girls to go into the field?
Yeah, not only is there probably a issue there that made them leave, it's probably worse now that the women are not even there. Right, right. And, and, you know, furthermore, having a mom who's like, well, I wouldn't really recommend this field is like, it's not a glowing recommendation for little girls.
And that's like one of my big theories about some of the problems is that retention is actually a really big deal. Because the more people that you can retain for an entire career, the more likely you are to kind of have this cross generational effect of, of they're going to convince, you know, their children or their nieces and nephews, or, you know, just people that they talk to, to go into this field, because they loved it. And they've had a wonderful experience.
Right. There's, you know, the people that you look up to, as you're growing up, you're like, I'd like to be like this person, or, oh, that person is great. What did they do that, you know, like, seeing that path for you and somebody else matters.
And if, if you don't see that in, if you're a young woman, and you don't see that in, in any of the women around you, like, well, maybe it seems interesting. I like computers, but you know, that's, maybe this actually is not for me, right? It could be a strong signal. And like you said, we're taking women to be concrete, right? It could be race. It could be class. It could be lots of things.
I do use, I use women as an example, but it generally is true across kind of like the different, the different metrics or the different dimensions that we should think about these things. But, but yeah, I mean, we, we do, we look at the adults around us, even if it's a friend's parent. And we kind of try on, you know, what do we want to be when we grow up and seeing a positive example of someone who looks like you or has qualities like you is so important.
Right now, most women in the field are what I call first generational women. They have been pulled into the field by men. So I'm a perfect example. My brother convinced me to study computers. And there's a lot of women in the field like this and getting more what I call second generation women, where they were convinced to go into the field by another woman who was really happy, I think is just, it's just so important for the future of computer science and the future of diversity in our field.
We were talking about the earlier computer science. And I also volunteered at Hour of Code at my daughter's school. I have three daughters. One of them is seven. And we did, we did an Hour of Hour of Code with first graders, second graders, third graders, fourth graders, and fifth graders, all separate. Like I think we did seven sessions or something throughout that week.
And certainly in first and second grade, there was basically no difference between the interest and the enthusiasm and effort and what came out the other side of the girls, the little girls who were programming and little boys, right? But somewhere between, between there and now, like things get separated and I don't think they have to be. And so the more that we can take away those things that strip some of the people out of the industry, I think we'll be all the better.
Oh, definitely. Yeah. And I think that like, you know, the media plays a big role in that. And there's, there's a lot of like messaging that I think is changing for the better around. Yeah. Basically kind of how we package up these ideas for little boys and little girls, you know, boys and girls toys. Like why, why is that an important distinction? Yeah. I think there was just a nerdy Barbie doll came out and that was like a big deal.
We're not really big into the Barbie dolls right here, but I think I saw that somewhere. The Reddit community, a couple of years, it would have been about five years ago now, got ahold of the voting for the next profession for Barbie. And they voted to have her be computer engineering Barbie. And one of my friends bought me one, which I thought was hilarious.
Oh, awesome. And I used to give them to, to a few of the women I knew who were like joining the company I was at or joining the industry. I would, I would give them a computer engineering Barbie as a joke. I don't know why, because it's funny. And, and then they had an entrepreneur Barbie, which I also own. I call them my aspirational Barbies.
Oh, those should be the same Barbie. Yeah. Cause that's awesome. Those should be the same. Well, yeah. Yeah. I mean, computer engineering Barbie then became entrepreneur Barbie. And so. Right. Exactly. She spent five years in the place with all the cubicles and she got inspired. Yeah. Cause my goal when I was little was to grow up to be Barbie. Not at all. Not, not at all. Yes. They only have a blonde one. I couldn't, I could never get into Barbie. I'm a brunette.
Barbie's a little bizarre and unattainable. There's some weird studies. Oh, Barbie's so weird. Anyways, that's why, that's why we think Barbies are really funny is because like, I don't actually think encouraging little girls to play with Barbies is good. But then they had a computer engineering Barbie and I was like, I guess when I grow up, I want to be computer engineering Barbie.
Yeah. I guess that's funny. All right. So I guess maybe we'll leave it there for the environment stuff. But I think what I really liked about your presentation was it had concrete positive actions that you can take. Like I'm all about people criticizing stuff and saying, this is not good. This should be better. But if, if it often just comes with pure criticism and no sort of like, and now we should, right. Like I think it's, it's not necessarily helpful to the discourse, but I really like that.
It's not necessarily helpful to the discourse. And I'll link to all those. And I'll also link to your PyCon talk, which is on YouTube. People can check it out. Yeah. So two quick questions before you go. Okay. One, if when you write Python code, what editor do you open?
So right now I use Adam, the new editor that was made by some of the GitHub folks. And I use the Vim plugins. So I use the Vim bindings. I used Emacs for a while in college, but I got like, I felt like I was going to get carpal tunnel from like all of the control X's, which I know you can customize and change. But then I switched to Vim and I love Vim. It's just, it's my favorite. Oh yeah. That's awesome. I'm definitely noticing a rise in the popularity of Adam. So that's cool. I like it myself.
It's really cool. I like it. It's easy to use. and it's like, it's an editor. It, it doesn't get away from the fact that it's just an editor. It just like lets you edit your code. Yeah. Yeah. That's cool. And they have, if you go to, what is it? Adam.io, there's a cool little like Jetsons futuristic video there that, that, you know, makes it fun to think about as well.
Then the other question I often ask on the way out is there's over 75,000 libraries on PyPI and we all have experience with different ones. And is there one that you're like, Oh, this is kind of cool. I use this and maybe it's not very popular, but it'd be cool. People knew about it.
Like I'm a huge fan of flask. I really, for like web applications, I think flask is just like a really nice, you can, you can pick the different flask libraries that you want to use. So you don't have to have everything. That's interesting. So like recommending flask is like kind of like recommending a hundred.
Exactly. And it's recommending the idea that like you can pick and choose your libraries, which is its own mindset. But, but I really enjoy it because I like to build very service oriented web architecture. And so for some services I need a lot less and for others, I need a few more things. And so I really like kind of being able to like build your own web framework. Yeah. Yeah. I like that philosophy as well.
Yeah. And then I'd say the other library that I really like is I do a lot of work with like AWS API and I love, I love kind of like the AWS Bodo library. They've actually done a really good job with it. Yeah. Bodo is sweet. I was using it just the other day for some S3 work and yeah, it's very clean. It's good stuff. All right. Well, Kate, thanks so much for being on the show. Is there kind of a final call to action you have for people?
I mean, not really. I think, I think we covered a lot of different things. Yeah. So maybe, maybe think about the, think about water, water in your environment and maybe, you know, what are the small steps you can do to make a change? Yeah. I'd say that's the big thing. Incremental change is still important change. I think we all know that as engineers that, that you spend a lot of time doing incremental changes.
And that's huge for culture and for engineering environments in the same way that that's really important for, for developing code. Yeah. Awesome. All right. Well, thanks for being on the show. It was great to talk to you. Yeah. Thanks for having me. You bet. Bye. This has been another episode of Talk Python To Me. Today's guest was Kate Hedelson. And this episode has been sponsored by SnapCI and Hired. Thank you guys for supporting the show.
SnapCI is modern continuous integration and delivery. Build, test, and deploy your code directly from GitHub, all in your browser with debugging, Docker, and parallelism included. Try them for free at snap.ci slash talkpython. Hired wants to help you find your next big thing. Visit hired.com slash talkpython to me to get five or more offers with salary and equity presented right up front and a special listener signing bonus of $2,000.
Are you or a colleague trying to learn Python? Have you tried boring books and videos that just cover the topic point by point? Check out my online course, Python Jumpstart by Building 10 Apps at training.talkpython.fm and learn Python in a more engaging way. You can find the links from today's show at talkpython.fm/episodes slash show slash 55. And be sure to subscribe to the show. Open your favorite podcatcher and search for Python. We should be right at the top.
You can also find the iTunes and direct RSS feeds in the footer of the website. And starting just this week with the launch of Google Play for podcasts, you can also find the Google Play link in the footer. Our theme music is Developers, Developers, Developers by Corey Smith, who goes by Smix. You can hear the entire song on talkpython.fm. This is your host, Michael Kennedy. Thank you so much for listening. Smix, take us out of here.