Gatekeeping in the Technology Industry

Noah: Thank you all for coming out today for our Fireside Chat. With us today is our guest Kat Cosgrove, Developer Advocate from JFrog. We have a bio page on Kat.

We’ll be talking today about gatekeeping in technology and your attendance to this event benefits Kat’s charity of choice, which is Memphis Choices.

We’ll be taking Q&A throughout the session. Use the Q&A panel in the Zoom webinar please, and we’ll get your questions when we can. If we don’t get to them, we’ll try and handle them offline at the end of the event. A round of introductions, I’m one of your co-hosts, Noah Abrahams. I am an Open Source Advocate here at StormForge. My other co-host…

Cody: Hey, I’m Cody Crudgington. I’m a Senior Consultant here at StormForge.

Noah: …and our inimitable guest, Kat Cosgrove, thanks for coming out Kat.

Kat: No problem. Hello, my name is Kat Cosgrove. I’m a developer advocate at JFrog, which means that my job is to be an engineer with social skills pretty much. I’m a software engineer, I just rolled like super duper high for charisma, so I talk to people mostly now. Hi y’all durren. I’ve noticed that there is someone attending who I actually know in real life from outside of my professional career, which is interesting so hi Nina! How you doing?

Noah: Always good to have friends in the audience. So getting started into this, one of the things that I found really interesting when you first presented this topic, because we always ask our guests for what topics they would like to talk about, and you presented gatekeeping in tech as a title and a topic, almost everyone that I presented it to said hey this is what the topic’s going to be, everyone said oh so it’s going to be a hiring conversation? And we know that’s not the case, but it was very easy for people to fall into that.

Kat: Yes.

Noah: That train of thought, so can you start with how much bigger it is than that. What is gatekeeping entail? Why I mean we know it’s a bit of a hiring problem, but we know it’s a lot more than that.

Kat: So obviously yeah it’s a hiring problem. When you hear gatekeeping in tech, you think like not being as likely to hire someone because they’re a woman, or because they’re black, or because they don’t have a college degree or whatever. Like that’s the kind of gatekeeping you immediately think of, but that’s kind of that’s an active form of gatekeeping. You are making it a decision whether it’s conscious or not to exclude somebody from the job based on some aspect that is largely out of their control. And that’s kind of it’s more malicious, it’s more insidious, it’s also more obvious when it’s happening. I think that there is a second type of gatekeeping that we all kind of do and we don’t really talk about. And it continues to cause problems for people once they’re hired regardless of whether or not they’re a part of some kind of like underrepresented group and it manifests in a lot of different ways, but one of the ways that like really really really bothers me is that we use a lot of jargon. I’ve also been told that I mispronounced jargon. I don’t care. I am from the deep south and I don’t have much of an accent anymore, but some things are just like not going away and the way I pronounce jargon is one of them, so deal with it. But we use a lot of jargon and it artificially raises the barrier for getting involved in certain technologies. DevOps and cloud native are particularly bad about this. We tend to describe tools or describe projects or whatever with a bunch of shorthand that makes sense to us and all of our peers because we work in this space and we are used to it, but it doesn’t make sense for junior engineers. It doesn’t make sense for newbies. It doesn’t make sense for people coming over from another tech space. And it is very little effort for us to just define the words we use in like written technical documentation, but we don’t do that. We also kind of don’t explain why something solves a problem. We just describe the problem it solves, and that also makes it really difficult for new people to understand. Like the definition, the actual Wikipedia definition, of a service mesh is super confusing and it means nothing if you don’t already understand why a service mesh is helpful, so like that’s still gatekeeping.

Noah: I’ve 100% been there, trying to explain early on what a service mesh was.

Kat: I have not been in this industry for all that long and some of this stuff was so much harder to learn than it needs to be. Like my favorite example to drive this home for people who work in tech and already understand these words is with two examples of jargon from other highly specialized areas that you’re probably not familiar with like, do either or either of you into esports, like do you play video games?

Cody: Not really.

Noah: No, not competitively.

Kat: Okay cool perfect. So if you were playing Overwatch, which is a competitive 6v6 shooting game by Blizzard, it’s very popular, and somebody said hey let’s go goats, would you know what that meant?

Cody: Absolutely not.

Kat: Yeah most people wouldn’t outside of that and there’s a reason why we don’t really say let’s go goats anymore. It’s because the amount of lore involved to know what somebody means when they say let’s go goats is ridiculous. And so goats is a hero composition, where you play three tanks and three supports on your team. You don’t play any dedicated damage dealing characters and you might think that it’s called goats, because “goats” is short for like greatest of all time, but that’s not why we call it that. We call it that because the team that popularized that competition, like four years ago, in Blizzard’s semi-professional league was called goats. So the team name the team comp ended up called that, but nobody knew what the hell that meant if they weren’t really into esports. So like people casually watching Overwatch League, the like televised professional thing, they didn’t know what that meant when [broad]casters said goats. So Blizzard came down and said hey you have to call this something else. People don’t understand it unless they’re already like deep into esports so they made the casters call it 3-3 instead because that makes sense on the face of it, but goats doesn’t and like the tech industry has a similar problem where we give things like cute names that require lore to understand and that sucks.

Cody: Yeah so this is an interesting point. So essentially what you’re saying is we’re limiting the path of success or we’re delaying the path of success to certain groups of people…

Kat: Yes.

Cody: …because we’re not being inclusive enough or explaining what in general terms what we’re talking about essentially.

Kat: We’re shooting ourselves in the foot, I think. Like we really are because we need new people. We need junior engineers and we are making it way too hard for them to understand what we’re even talking about. And there’s a pervasive attitude that this was hard for me to learn, so it has to be hard for you to learn too. It’s just hard. You see this a lot with people talking about Kubernetes and I think that’s an attitude that really sucks.

Cody: It goes back to the old RTFM, right?

Kat: Yeah, it’s just not good. It’s not nice. Like why are we doing this if we’re not doing it to make things easier for people? So like artificially keeping things difficult to learn is crappy and it’s not within the spirit of what I think we’re all actually trying to do. So just like define your terms. I included glossary in all the workshops I do because sometimes using jargon is unavoidable, but I include a glossary so…

Cody: Do you think this is a bigger problem? So there’s been a lot of a lot of different programs recently, especially in the Kubernetes compute community, to move forward with like mentorship programs and like to help people be more involved in the Kubernetes community and how to contribute back. Do you think those programs are helpful, not helpful? Do they kind of set the path forward where we want to go, or is it a bigger issue? 

Kat: No, I think they’re super helpful because like they don’t teach this stuff in college. I didn’t go to college, I mean I did, but I dropped out, and I didn’t go to school for computer science, but regardless they don’t teach you cloud native technologies in college. They don’t teach you cloud native technologies in most coding boot camps. The one I went to now does have like an Ops 401, but they don’t go into Kubernetes that much. So like the literal only way that we teach people stuff like this is through community efforts. Things like hosting community workshops, community content creation, and through things like mentorship, so I think that’s super important and it’s currently our only path forward to make it like to educate newcomers. I also think if you’re a senior engineer or a team lead, it is your literal job to do that and if you aren’t actively functioning as a mentor for the juniors on your team, you aren’t doing your job, like straight up that’s dereliction of duty, IMO, like you’re you’re detrimental to your team if you’re not doing that. That’s part of the responsibility of being a senior to me at least. I’m willing to fight about that… 

Noah: I agree with you on that, but I want to go back to the mentoring idea for a second. Do you think that it is a problem that mentoring is the primary path forward? Like it’s great that we have mentoring, I’m all in favor of mentoring the younger or newer generation and getting internships getting new and fresh people into the ecosystem, but is it sort of I don’t know almost taking a an easy way out to say well we’ve got this mentoring program we don’t necessarily have to put as much effort into other things even though we know that people are still putting effort on there. Do you think it takes away from the mental initiative?

Kat: I don’t think it takes away from it, but I do think it’s unfortunate that it feels like our only path forward right now. It’s probably unreasonable to expect university programs to start teaching like cloud native technologies or DevOps, right? Because the curriculum changes really really slowly and this technology changes really really fast so it’s unreasonable to expect them to add that as a standard part of the course, but I also don’t think it’s fair to put the onus on the community to train every junior developer that comes up. It shouldn’t be just a handful of people with time to mentor strangers doing this. I think if we all make a series of small changes it becomes less of a burden, and just mentoring people is not going to solve all of the problems we have. Because there are some pretty gross problems in hiring that don’t have anything to do with like bias against race or gender.

People don’t understand what any of this stuff is and the people who are writing the job descriptions definitely don’t understand what these things are. There’s a slide in a talk I have about this where the day before the talk, I went looking on Indeed in Seattle for a junior DevOps engineer position and one of these junior DevOps this was like in the first page of results in Seattle. It had, where is it, they wanted three years of support or equivalent experience in a customer-facing role, a solid understanding of AKS, Azure, no specific service listed just Azure, cluster, Kubernetes, experience in windows and windows Azure platform services like virtualization, hyper-v deployment, active directory, like there’s the five programming languages listed here, experience administering linux, all kinds of stuff and this was for a junior position. That’s a whole team and definitely not junior. That’s like four senior engineers and they’re calling it a junior and like that kind of stuff is super poisonous because you and I look at that job description and we know it’s absurd, right? We look at that and think they’re trying to underpay someone or somebody who’s not technical wrote this and just doesn’t understand that it’s ridiculous and we apply anyway, right? But junior engineers don’t know that they have no idea and they don’t have anybody to tell them that it’s absurd if they’re fresh out of college. So they look at that and they get super discouraged because they think well I can’t imagine knowing all of this and if this is what I’m expected to know to be able to work in this sector, why bother. And it makes people feel really crappy. So that’s the… Go ahead. 

Cody: No, I was just gonna say let’s talk about the pipeline problem because I’ve been… In preparation for this talk, this has been a subject for years now, right? Especially like I remember being a there was solid conversation around it back in like 2016 or somewhere around there, Google was in hot water, right, and someone, I had to go look back up this quote, and it was by Dr Joy Rankin and she said, if we want to claim it is a pipeline problem, we have to have first hired what’s available in the pipeline. 

Kat: Yep.

Cody: Yeah, I mean and that’s kind of like it hit me upside the face four years ago, five years ago, and it re-hunting it down again today, it did it all over again and it’s like come on. What are we doing here?

Kat: Yeah, it’s not a pipeline problem and I hate it when people say it’s a pipeline problem. I got a lot of friends that need jobs, yo, like a lot of friends that need jobs that aren’t white dudes, so if you are currently in need of a software engineer or an SRE and think that it’s a pipeline problem that the diversity of your teams sucks, reach out to me, and first I’ll yell at you because it’s definitely not a pipeline problem, and then I’ll grill you about your company culture to make sure that I’m not referring my friend to somebody who is poisonous, and then I’ll refer you to my friend if you seem chill. So it’s really, it’s not a pipeline problem. It’s super isn’t and a bigger issue is that is the sheer number of at least women who leave tech within five years, there was a study from a women in tech organization, that showed that something like 46% of women are sexually harassed at work in the tech industry in the course of doing their job. So we leave. It is signing up for a career where you’re going to be underestimated, overworked, underpaid, and probably your boss is going to hit on you at some point and that’s hard to tolerate, so people leave. It’s not the pipeline. It’s the keeping people here, which is a cultural problem that like industry-wide has to be fixed because not every woman in tech is as loud and outspoken and mean as I am.

Cody: Yeah, no I agree completely… And I’ve seen things from past jobs I was at previously and some of it can be pretty disgusting. What do you think about, like obviously it’s a big problem and it’s not, I don’t know if there’s an easy way to solve it. What do you think about like blind hiring practices?

Kat: I don’t think that I would like for the entire hiring practice to be blind.

I recognize that I will take some heat for this on social media from people, but I think that you do have to actively make a decision to attract and specifically hire talent from underrepresented groups until we have parity. I don’t think that there is anything morally wrong with doing that. White people are radically overrepresented. Men are radically overrepresented, and I don’t think it is unfair to give other people an advantage temporarily because it’s… Getting them in is not the problem. Keeping them is and if we can get closer to parity then maybe keeping them will be less of a problem. Because the feeling isolated thing is a big issue, and I know that I’m like saying a lot of negative things about being underrepresented in tech, but like I’m fine and there are people here if you would like to be here that will absolutely fight for you to have a place and to keep you here, so I’m not saying don’t. I’m saying the ride is a little bit rough right now, but I don’t I don’t think fully blind hiring is a solution to that, unfortunately, for the same reason that conferences don’t often do completely blind talk selection because they have to balance for some types of diversity metrics in the lineup.

Noah: I mean there’s also implicit biases that we have to deal with, so if you’ve already got a hiring team that is, just pick a number out of a hat, and say it’s 80% white men, then the questions and the intent and the review in the hiring process would naturally bias towards that, with everything else being equal.

Kat: Yeah and it’s like we do that unconsciously, right? It’s not something we actively think about ourselves doing, but it is something we do and that’s why it’s called unconscious bias, right? But it really isn’t malicious and it is a form of like more passive gatekeeping doing that. I don’t think it’s…

I don’t know how to fix that other than just…

I’m a big fan of the paradox of intolerance, so for a society to be truly tolerant, we have to be aggressively intolerant of intolerance, and being loud and mean is the only way I know how to help fix this problem.

Noah: So what are some of the best ways to put a spotlight on some of these things when we see them if we recognize them, other than just loud and mean is a pretty big box in certain contexts. What have you seen be really useful?

Kat: It needs to be the people who already have power calling it out and it needs to be done like loudly and firmly and quickly without forcing like a member of the group being victimized to do the speaking up for you. There’s a difference between speaking up in defense of me and speaking up for me. I don’t want people to speak for me, I can do that myself. But I do want people who have power or privilege that I don’t to step in before I have to. So if you’re in a position of power at your company and you see like a crappy hiring practice happening, or you see some kind of behavior that feels like it excludes someone unfair occurring, you call it out. Don’t make them do it. You call it out every single time. It’s not the jobs of marginalized people to fix this. It’s the jobs of the people in a position of power to fix this, just like it’s my job as somebody with considerably more experience in the tech industry to make sure that the way I talk the way, I the way I communicate, the way I teach things is useful to people who don’t have as much experience as me. That is ultimately my job to make things more useful to more people and like language is a big part of that.

Cody: 100% and do you think, I mean it seems to me anyway, that we are trending towards something better than what it was maybe five years ago?

If you had your choice of what to do next, what would that be? Where do we go from here?

Kat: Well I’m a weird person to ask that because I’m not a big fan of capitalism and I don’t believe that anybody should have to work to survive. So…

If I could have anything I wanted right now, it would be like some kind of universal basic income or whatever because I don’t think you should have to toil to survive. I really just don’t. But if we’re talking about the tech industry specifically, I would like to see more tech unions actually. Because unions don’t just include developers. Developers make a lot of money, that’s true. We are highly prized and that’s great and all, but there are lots of people who work in tech who aren’t developers and they aren’t being compensated fairly for their work, or they’re being overworked like technical writers. Technical writers don’t make enough money. I love technical writers. Developers love technical writers because developers don’t like writing documentation, and good documentation is really important because good documentation means it’s easier for new people to use our stuff, which eliminates one of the areas of passive gatekeeping that I think is a problem for us. So consider unionizing.

Cody: There’s a big push. There’s a big push for it right now, massive, right? 

Kat: Yeah, at Amazon. I would love to see it. 

Cody: Google too I think.

Kat: Yeah, Google has a union.

Cody: Oh, they do… It’s already done. Huh, okay, wow.

Kat: Yeah, which I think is pretty cool it’s a pretty small union, but they have a union and that’s good because collective bargaining is good. And it doesn’t just defend the rights of us overpaid developers, it defends the people making less money than us. It defends like your janitorial staff, or like the front desk staff, or whatever. It’s for everyone. Unionize. 

Noah: So that’s got a lot of strength in the capitalism side of the house, but what about it like the open source side of the house where there isn’t necessarily somebody paying the bills?

Kat: Sure…

Noah: But you still see the same behaviors? Do you see analogous efforts that could be undertaken there? 

Kat: In open source, I think that is more of a we. We have to bootstrap it as a community. Like so with a certain someone making a return to the free software foundation recently, we’ve seen a lot of public outcry very very rightful that I hope has legs. I would like to see him gone or I personally won’t have anything to do with the FSF, but open source does have a problem of overworking people for free and a lot of us are doing it because we’re passionate about it, right? We’re passionate about building a community, we’re passionate about building things that are useful just because they’re useful to somebody else, and not because we want to get paid for it, which I think is is great, it’s it’s very noble and I love it, but I don’t like it when companies take advantage of that. I don’t like it when large public very profitable companies rely on open source software as part of their paid offering and don’t contribute back to the project in some way. It doesn’t have to be money, you can contribute pull requests, contribute code, but that bothers me a lot and I think there should be more pressure on big companies with some kind of revenue stream to contribute back to the open source projects they’re relying on. As far as just community standards, the only way that gets fixed is if we are all very aggressive about shutting it down when we see something gatekeep-y or see something toxic. Having a good strong code of conduct and an actual documented way to enforce that code of conduct and file a code of conduct complaint is really important. Most open source projects I have anything to do with have one. That’s pretty much a non-starter for me at this point, there has to be one, but otherwise you end up with situations like that particular person rejoining the FSF and I’ve gotta hope that the extreme amount of community outcry over that puts a stop to it, but it does give me hope. I don’t know anyone personally who was excited that the FSF let him back in.

Noah: I feel like that’s the collective voice of the open source together, that pretty much is the manifestation of a union, isn’t it?

Kat: It is, it is a large group of people saying hey no or else we’re out, and that’s a lot of pressure. A ton of companies rely on open source for their actual paid products, right? A ton of them. So open source maintainers, which includes the people who write documentation by the way, have a lot of power that they can flex and it’s nice to see it be flexed because that’s all that is all community driven it’s there’s not a motivation behind it beyond build a cool thing that solves a problem for someone else, which is, which is nice, which is wholesome. More wholesome tech.

Noah: Yay, well you’ve sort of got to go through the steps, right? You gotta identify the problem and then you have to figure out what the solution is, and then you have to implement the solution. It sounds obvious to say it, but you have to go through the steps otherwise you don’t actually get the solution done.

Kat: Right, you just end up with a whole bunch of too many cooks in the kitchen situation just kind of like flailing around trying to do something, but nobody’s talking to each other. Like the Docker Shim incident was a lot of that. Not talking to people. Should I explain what that is for people in the chat who don’t… Okay, so a few months ago Kubernetes announced via just a change log that they were going to be deprecating something called the Docker Shim. The Docker Shim is a small software shim that allowed a Kubernetes cluster to get at the instance of container D inside of Docker and use that as the container runtime. So some people, lots of people, were using the entire Docker tech stack as their container run time, inside of Kubernetes instead of just using container D directly. And the way it was announced that this was being deprecated created a lot of panic because it was just a line in a change log. It was going to break a lot of people’s clusters and also a lot of people who are vaguely related to Kubernetes, but don’t actually touch it themselves, don’t understand what it is or how it relates to Docker. A lot of people conflate Docker with Kubernetes, and so it created like really really really widespread panic and this was ultimately just an issue of not talking to each other, but it was exacerbated by the fact that nobody knows what Docker is because it was named badly. Docker is not just one thing it is a bunch of things. It’s a whole stack of stuff and also we’re in a situation where there are now multiple Dockers, like I’m honestly not sure myself, which pieces of Docker are owned by Docker the company, and which pieces are now owned by Mirantis, which is a separate company that bought Docker enterprise. So we named something badly and it created a ton of confusion even for people who do work in the industry, like actively, which is I guess technically another example of jargon because we’re just we’re not defining our terms clearly, but one line in a change log turned into a firestorm that took over Twitter for about 36 hours and created a pretty extreme panic for a large section of the developer community, and also a large section of Kubernetes maintainers, myself included, because we had to like freak out and panic to clean up this mess by putting together a very hurried blog, after my very hurried series of tweets, and it was just it was a big mess, and the problems were not talking to each other, not communicating clearly, not knowing what each other knows, and naming things poorly. So it was kind of… It was extremely messy and ultimately that one boils down to, please talk to each other, you cowards.

Noah: So from what I know of all the Kubernetes sig meetings that I’ve ever attended, which is quite a few when I was trying to find my place, I’m confident that this was discussed widely and expected that it was going to be open because it was in somebody’s meeting notes or because it was in a recorded meeting that 99.9% of other people would never go look at. Yeah, we’ve known for like two years that this was coming, like this was a planned thing, and the maintainers just made an assumption that everybody knew, but like nobody knows. If I’m not reading the change logs regularly and I talk about this stuff for my actual job, then you can be really really sure that end users are also not reading the change logs, or the sig meeting notes. I have never read the meeting notes for a sig that I am not in. Ever. And in fact I barely read those, I’m going to be honest with you. 

Cody: Like a brief run through before the next meeting.

Kat: Yeah, pretty much. It’s an accessibility of information issue. We caused a lot of problems for a lot of people because we just assumed they knew and because we just assumed that people understand what Docker is and nobody knows what Docker is anymore.

I have no idea. 

Cody: Right, so Prashanta said something in the Q&A here and I’m going to point it out because I think it’s fairly interesting. So essentially what they’re saying is their own views about what good code is with regards to mentorship that maybe they’re limiting someone else, someone else’s abilities, based on their own view of what good code is and isn’t. 

Kat: So, I’m going to steal an idea from a friend of mine and I will be happy to hand out the link to his talk article on this subject, but good code doesn’t exist. It doesn’t exist. So I went through a phase where I was trying to write the smartest code I could, right? It did what I wanted and it did what I wanted in a clever way. I optimized the hell out of it and that was fine and I was very proud of myself because I thought that that was what writing clean code meant, and that’s not true really. If the code… If it runs, okay, if it runs if it does what it’s supposed to do, if other people can read it, if it’s easy to like, extend, maintain, and delete then that’s good code. That’s clean code to me. I also don’t like the clean code as a phrase because I am deeply allergic to the man who coined the phrase, but I think it depends on what you’re nitpicking in this case. If they’re just doing something in a way that’s different to the way you would do it, then I would say let it go. If you think they’re doing it in a way that is confusing or not ideal, then I wouldn’t nitpick it at first. I would ask them to like walk you through it line by line and explain why they made those decisions. That’s what I do when I’m TA-ing students – I do still TA and tutor students from the same boot camp I went to – and that’s how I handle situations like that because new people especially, I did this when I was new, do try to write like clever code, and clever is not always good. You don’t want to… try to solve something with a map filter and reduce nesting like a ternary in there for good measure is not always the way. That’s hard to read and that’s hard to maintain even if you document it well. If it’s not necessary to do that, you shouldn’t be doing that. So I would say just ask them to explain first like why they made these decisions and if you still think that it’s not ideal or it’s got some super negative trade-offs then maybe explain your hesitation, but there’s a lot we can learn from people who don’t really know what they’re doing yet still. So remain open to the idea that maybe they are right. Maybe they are doing something in a more ideal way and we just kind of get stuck in the way we learned to do things. So it’s easy to, I don’t know, forget what it’s like to have to learn something new and experiment. So I wouldn’t shut it down, I’d talk to them. 

Cody: Do you think that our own preconceived notions or our own ideals about what, again, what is good code and what isn’t, do you think that’s also a form of gatekeeping in a way? 

Kat: Yeah, definitely because it shuts down new ideas for sure. It absolutely shuts down new ideas. Every major innovation we’ve had in technology has been a result of somebody going, wait a minute what if we did this weird thing instead? So let people do the weird thing. Don’t stifle people’s creativity. Let them do the weird thing, let them try the weird thing, and if the weird thing sucks, they’ll figure it out eventually or somebody will step in and say hey actually this is a good idea, but it doesn’t actually work for this reason. Yeah I think it’s definitely gatekeep-y to tell people that they have to do things a certain way just because you learned it that way. Also I don’t write production code so nobody has to deal with the consequences of my absolutely bonkers decisions, but me so that’s exciting too.

Noah: So I feel like there’s another question embedded in what Prashantha said and it’s sort of a bi-directional thing about communication. When either you’re in a position to be gatekeeping or you’re in a position where somebody else’s practices, whether it’s coding practices, whether it’s office culture, whether it’s whatever it is, that there’s a communication aspect of being able to bring up and broach these types of issues without also having an effect of either squashing or being squashed.

What do you think are some really good ways that people can get ahead of sharing their experiences, feeling heard, being seen, in addition to just like confidence? You can… It’s easy to say yeah just have confidence go do it, but what are some practical things that you think people can do to really help that bi-directional communication?

Kat: Yeah, so this takes work on both sides, I think. For new people who have questions to ask or like aren’t sure about something, to you I say please ask the question, even if you think the question is stupid. Knowing when to ask questions, knowing like being able to recognize when you don’t understand something and need help is a skill and it takes practice. It’s one of the things that differentiates junior engineers from senior engineers. Senior engineers know when they don’t know something and they know when to ask a question and they know how to ask the question. So learn that skill early and ask questions often as a junior developer. It is your job to ask questions when you get stuck, but I understand that it’s hard to feel safe doing that. There’s a fear that people are gonna think you’re stupid or that you’re gonna get fired because you’re asking too many questions and you’re not like producing as fast, and fixing that requires the support of the people who are in mentorship positions. You have to make it clear that you expect questions and that none of these questions are stupid and that it is safe to ask them and that they should be asked. So it requires the two of you communicating about your expectations, and just by virtue of the mentor being in a position of power, I think the conversation has to start with the mentor. This will maybe become less of a problem as we learn to like speak and document things better, because for me at least a lot of the like feelings of inadequacy and difficulty with asking questions early on in my career came from the fact that so much of the technical documentation and quick start guides and whatever for the tools I was trying to use were written as if like I was already an expert. So the implication within the like very manual I am trying to like RTFM being that I’m already an expert, like that makes you feel bad it makes me feel kind of stupid, which is also why I don’t like to see the word easy in technical docs. In marketing copy it’s one thing, like I’m not going to tell marketing what to do, but in technical documentation I don’t think you should literally ever use the word easy, at any point. Because that has an effect of making new people feel alienated. It’s very gatekeep-y because it’s probably not easy. It’s easy for you because you’re an expert and you have forgotten what it’s like to not be an expert, which is normal it’s human nature, but you need to make an active effort to remember that it’s not easy, it’s just easy for you.

All right, I love it. We’ve got another question in the chat, which is from your friend Nina!

Kat: Hi Nina!

Noah: What do you think a rebranding of the tech industry would look, like at least to start? Obviously with things like unions being a catalyst for making that happen, and do you already have or know of something already in the works for changing the way things are currently?

Kat: Oh geez, I don’t know. I barely dare to dream what it would look like. I think it would be outstanding if unions were a normal part of the tech industry, but I think it’s gonna be difficult to get there. There are a lot of people that are very loud about this on Twitter and getting louder about this, and most of them are around my age and or younger, which is fantastic to see. The upside to that is a lot of us have power now. A lot of us are getting like juicier job titles and more control over the way businesses operate and more employees reporting to them. So I think it will be slow, but I think this change is already kind of happening as people like me move up through the tech industry and the like old billionaires get kind of pushed out. I really… I hope to see this kind of radical change in my lifetime. I think we’ll get pretty close, if people like me and my friends end up with enough power to do so, but we’re trying. We are actively working on that. I also don’t really like the way the tech industry is affecting some places I care about very much. My hometown is getting very expensive to live in because of a certain company with a large box on their logo and an arrow, so that’s a thing that I would like to see slowed down, but we’re getting there. There are a lot of people in the tech industry that are actively working towards this and some of us are getting quite powerful, so… We tryin’.

Noah: We will continue to get better every day.

Kat: Yes.

Noah: So that’s bringing us near the end of our time slot. This has been a really good talk. 

Cody: I got one… I’m gonna ask Kat to leave some partying wisdom for anybody who is mentoring or is in a senior role with junior developers underneath them. You’ve already gone over quite a few things, but if you wouldn’t mind recapping just some advice or parting words.

Kat: Yeah, the first piece of advice is that just because it was hard for you to learn doesn’t mean it has to continue to be hard to learn. Suffering to learn these things is not like some kind of weird rite of passage. It isn’t required. I don’t know why so many people feel that it is, but it isn’t. It’s our job to make this more approachable, so don’t just… Never let your mentee struggle. I don’t let anybody that I am tutoring struggle and bang their head against a question trying to figure out the answer for more than like 20 minutes, at which point I start trying to help them unravel it themselves. So don’t don’t let people struggle. It is your job to help them struggle less. So please do that for their good and for your own good because you’re creating problems for yourself, you’re creating problems for your team, you’re creating problems for the industry at large when you allow this perception that, for instance Kubernetes has to be hard to learn, to continue. So that’s my number one piece of advice.

My number two piece of advice would be to make sure that your mentee is comfortable asking questions. They might lie to you out of self-defense and it’s your job to kind of like pick it apart and figure out when they’re not being entirely honest out of fear. So make sure that they feel comfortable and safe asking questions even really really silly questions or questions that they might feel are silly. Because some of this stuff is still very hard and it’s ultimately our fault that it’s still very hard because we’re not explaining it well. So be patient and encourage them to ask questions, even dumb ones. I still don’t know what a monad is. I’ve had multiple people try to explain to me what a monad is. I don’t know. I don’t get it and that’s okay. I’m not stupid obviously, but I don’t know what a monad is because nobody’s been able to explain it to me correctly, and that’s just gonna be that’s gonna be my like bar for have we fixed this yet? Does everybody understand what a monad is? Like no. Do you all know what a monad is?

Noah & Cody: No.

Kat: Yeah, see nobody does nobody knows. Yeah, so those would be my top two pieces of advice. Further, if you see something that feels discriminatory or it feels gatekeep-y, if in any way the barrier to entry is being raised, you’re in a position of power so you are better equipped to try to fix this. So speak up in defense of other people if you see them being mistreated or marginalized or kept out for whatever reason, and it doesn’t just have to be like underrepresented groups, it could just be like hey we’re using a lot of really weird shorthand in this thing, in this doc, can we include a glossary? I don’t want to open 40 tabs to Google like every other word in your quick start guide. I really don’t want to do that, so just link out to a definition of something, or include a glossary. It’s a really important thing that is not a whole ton of effort to put together, or hire a technical writer, pay them a lot of money, and have them do it.

Cody: Sound advice. That’s fair, that’s fair. 

Noah: Speak out. Do your part. Hire technical writers. Well awesome. Thank you for coming today. Thank you to the folks that asked questions in our Q&A. I’m going to share our closing slide here.

Kat: Thank you for coming and allowing me to get people to donate money to this charity I care about, which Nina should be familiar with because we know each other from Memphis.

Cody: Nice!

Noah: So if anyone has any additional questions, Kat has graciously offered to join us over on Twitter for any follow-up questions, AMA style. We’ll be doing that right after this session closes. We hope to see you on our next fireside chat. We are currently planning for a fireside chat next month that will be closer to a panel or round table, talking about cloud waste! So look forward to that. That’s going to be…

Kat: Spicy!

Noah: …Fun talking about finances and environment.

Kat: Ooh yeah.

Noah: So thanks everyone for coming out and we’re going to end the stream now. Bye.

Cody: Thanks, Kat.

Kat: Thank you!