Rachel Nabors // @rachelnabors

OPENING QUOTE: I had to take all my life savings and buy a laptop. And this is money I’ve been saving from being a waitress for many years. Other people bought cars, which would let them go to work and school. I was like, “If I buy the laptop and have the internet connection, I can just bring the world to me.”

Brian: That’s Rachel Nabors, currently balancing open source contributions, documentation, demos, and community engagement on the React Core team at Facebook, and this is The ReadME Podcast, a GitHub podcast that takes a peek behind the curtain at some of the most impactful open source projects and the developers who make them happen. I am bdougie aka Brian Douglas…

Kathy: And I am Kathy Korevek.

Brian: Every episode, Kathy and I invite a maintainer or open source developer into our studio to explore their work, their story, and where the two meet.

Kathy: In this episode, we speak with Rachel who has been an illustrator, developer, author, speaker and teacher. These many skills have taken them all over the world giving keynotes, demos, workshops and inspiring people, young and old, to pursue their passions, against all odds. They grew up in rural Virginia, and found their way to programming through illustration. While a seemingly unusual correlation, in this interview we will connect the dots and discover just how their love for open source was established. We also explore documentation and all that they bring to React Core. Here, Rachel explains where their interest in computers first started.

Rachel: Oh, man, where do I even start? My interest in computers started, well, with my interest in computer games. I had my own Game Boy. I really wanted to build computer games. I made paper prototypes of computer games I wanted to play with other kids, and then played with them at school. I would draw the screen and give them, “This is your character.” And we would use our fingers to move them around on the screen. I was hooked on those kinds of games that Sierra used to release, like Mixed Up Fairy Tales, and The Treehouse, and I really enjoyed those, and playing on the computer was my favorite thing ever.

I wanted to make computer games but I did comics instead. I drew cartoons and comics based on my love for my other nerd hobby, which was Sailor Moon. So I ended up going in that direction and making comics instead of making computer games. But the way I made money off of the comics, as a teenager, was by hosting them online and building a community around them, using a Drupal site. I needed to sell the printed books, so I learned how to install osCommerce on a server, because we didn’t have Etsy. People needed a newsletter, so I installed TinCanPHP, because we didn’t have MailChimp. I got into social media because my audience was on Facebook, and I had to let them know when a new comic was up every week, so I went where my audience was.

And I was maintaining all of these online systems to promote the comics. I was doing more of that work than I was actually making the comics. I found myself sneaking off into the web development section of the Barnes and Noble when I should have been in the classical art and anatomy section. And I was like, “Well, okay, this is pretty cool. I wonder if there are jobs for people who do this.” Because comics was not paying for health insurance, and I needed to get some major jaw surgery.

And it turns out that, yes, you could make more doing web development than you could as a cartoonist. Unfortunately, though, because I was such a good artist, I got typecast pretty quickly at my first job as a designer. People didn’t see past the really cool comics. They were like, “Oh, you do HTML and CSS? Okay. Do some email campaigns for this client.” I’m a terrible designer. It’s not that I can’t do it. It’s that I have no respect for the client. They come in and they think they know what color the logo should be? “Get out. You don’t know what color you want.” I’m just way too much of an artist to be a good designer.

It turns out I love front end development, because the only people who have opinions about what you’re doing are people who actually have qualified opinions, and have thought about how to solve this problem before. No one walks up to you and is like, “Well, you should make this class bigger.” Nobody does that. Somebody might say, “Have you considered this other approach?” And you can weigh the pros and cons and be like, “I’ll think about it.”

So, it took a while.

Kathy: The winding career path is something that I love, how one thing inspires another. It’s always interesting to look back and see what leads us to where we are now. In Rachel’s case, they have so many talents‚—and they were exploring all of them in the 90s, far from an urban metropolis, where access (and exposure) was much harder to find.

Rachel: I didn’t get the internet for a long time because I lived on a farm in the middle of nowhere after that. And I remember having to basically do a presentation to my mom on how I could bring revenue into the house. “If we could get the internet, I could find a way to make money off of it. It’s only $20 a month.” And we lived right on the edge of what the copper telephone lines could support, so we just made it in under the wire.

Kathy: So you made the presentation, and she bought it.

Rachel: Yeah. True.

Kathy: So you were successful? That’s cool.

Rachel: Yeah. It was a bit of a hard sell. And then I had to take all my life savings and buy a laptop. And this is money I’ve been saving from being a waitress for many years. Other people bought cars, which would let them go to work and school. I was like, “If I buy the laptop and have the internet connection, I can just bring the world to me,” which is true to some extent, but the community college offerings online were not that great at the time.

Kathy: Well, Rachel, I’m from Alaska, and I also grew up, born in the eighties, grew up in the nineties. So very similar kind of life path. I totally understand the “grew up in the woods and wanted nothing more than to connect to the outside world.”

Rachel: It’s interesting, because you grow up in the woods, and you don’t necessarily have the same interests as other people in your community. I know I was not into the things that the local kids were into. I was homeschooled, too, so I was super isolated, but I was obsessed with Sailor Moon, and Sailor Moon was a Japanese cartoon, is a Japanese cartoon. They keep rebooting it--yes! But it’s by this wonderful woman named Naoko Takeuchi, and it’s really popular in geek girl culture. A lot of us had our favorite Sailor Moon character. Mine was Sailor Jupiter, although a lot ... Like the token guy. Oh my gosh.But yeah, they stopped broadcasting and translating the series at one point in the nineties, and it left on a cliffhanger. You didn’t know how the season ended. And everyone was like, “Well, what happened?”

So I was inspired to, one, go find all the resources about them in Japan, which you could get through the internet, and two, learn Japanese. And that was what kept me going back to the library to borrow the computers and internet access they had there, was, “I have to find out how the season ends.”

Brian: We hear so many stories about how people get into tech—and this is a great one: Because Rachel wanted to know what happened to one of their favorite characters. People find their way into careers in tech in many ways though, some of which involve formal education and others learn on their own. I wondered how these early experiences with technology shaped that next step.

Rachel: It’s one of those things where I wish someone had been like, “Rachel, computer science. You like game development. You like code. You should be a computer scientist. You know they have courses for that, Rachel.” Oh my gosh. I wish someone had told me that. No one told me that. So I was just like, “I have to work really hard to save up money to get jaw surgery.” No one was like, “Rachel, you know that you can make as much money in one year at a tech company, if you put in a couple of years going to school, as you’re going to save in multiple years working during a recession,” which by the way, you do not want to know what my starting salary was. It haunts me to this day. But anyway, nobody had made those suggestions. I was just learning on my own.

And still, there’s a part of me that’s just like, “I just want to go learn about programming in a school for fun. That sounds awesome. Yeah. That would be my job, would just be to learn about programming.” It’s kind of what my job is now. Don’t tell Facebook that. Don’t tell them, but I’m kind of getting paid, so I get paid to do what I would have paid money to do. I feel like I’m getting away with something here.

Kathy: You’ve hacked it.

Rachel: But anyway, so it was a recession, I mentioned, and I wasn’t really into being a designer. I really enjoyed CSS. JavaScript was difficult because there were a lot of people who were familiar with Flash and Java, and there is this whole, “JavaScript is not really a language. Real interaction developers and designers use Flash and ActionScript,” which is a sister of JavaScript, actually. And there was just a lot of that going on, and the JavaScript community didn’t feel warm and inviting.

But the CSS community, when I was taking my cool illustration and comics techniques and combining them with CSS to do things like animated music videos, the CSS community was like, “Well, come to Hawaii and give a talk.” And I did, and I felt like I found my people. I unfortunately never felt like I found that at any of the local jobs. So given that I’d started at such a sad salary, I just sort of thought, “I’m sure I can find a way to make this money some other way and not have people telling me to make the logo bigger, so I’m just going to go do cool things with code, and I’ll find this change under the couch somewhere, I’m sure. I’ll figure it out.”

Well, speaker fees, they’re not that great. Books, I did write a book, Animation at Work, with A Book Apart, but those royalties, they don’t put food on the table. I think someone once told me a book is like a really big business card. It’s not actually a source of income. And then of course I have launched online courses, at courses.rachelnabors.com. And you can also find them on LinkedIn Learning and Frontend Masters, et cetera. Most of these things have to do with animation and the Web Animations API, but all of this teaching, and traveling, and speaking, and giving trainings, and showing people how to make really cool things with CSS, and animations, and your user interfaces, it allowed me to do some cool things with people like MDN. I got to document the Web Animations API. It was a commission. That’s another way you can find change under the couch cushions. You can get paid to write documentation for MDN, at least back in those days. I didn’t get paid to be an invited expert at the W3C, but because of my work with the animation and documenting it, I had a lot of opinions about how to write the web animations API. So I got to hang out with those people and that actually led to the lovely role that you usually need a computer science degree to get at Microsoft. So, yeah.

Kathy: Incredible. Rachel found so many ways to build an income and share their knowledge and skills. But it can be hard to do so many different things and feel like you’re building your career. After putting together a site for Firefox, devtoolschallenger.com, Rachel came to the realization that all these skills could translate into a job that would offer them the support that they had been looking for.

Rachel: It was around then that I realized that my goodness, people with my skills could work at big tech companies like Microsofts and Facebooks and Googles. And they pay what? That’s like three times what my starter salary was. Man, and, and their health insurance benefits cover what? Oh, my gosh. When I found that out, I was quite sad, but point was I did take a very roundabout way, but eventually I ended up working big tech jobs and it turns out even big tech giants do need people who are good at explaining things and making cool things and good at building communities.

Kathy: Yeah. I have so many follow-up questions, but I want to take it back to you. You mentioned Action Script and Flash, and because you’re a cartoonist and illustrator, I’m just curious. It kind of seems like the Renaissance of animation of the web happened during the Flash days, which was a little while ago. And so I’m wondering kind of from then, what lessons do you think that we’ve learned from that period? And do you miss anything about it?

Rachel: Flash was... It allowed people to get started quickly? There’s this visual editor that Adobe invested in and it actually used Action Script. Action Script was a flavor of it. So if you knew Action Script, you could use JavaScript and vice versa. The visual editor made it very easy for people to get started. I think it was an on-ramp for folks who were visual and creative like myself. I didn’t get started in Flash. I got started with JavaScript because I don’t know, I like pain and I didn’t want a visual editor because I wanted to prove that I could write my own code. I don’t know. I think at that time it was apparent that Flash was not going to make it after the iPhone was released and basically said Flash is big and bulky, and we’re not going to support it.

And I think that was the problem with Flash was that it was big, bulky, and difficult to support. You still see this actually with... Like you’ve got iOS supporting Safari and WebKit. They maintained WebKit as their own browser engine. It’s a very efficient engine. And Blink, which Chrome and Edge run on is like a fork of WebKit that’s got way more features implemented. And these features tend to be more intensive in their requests from the system and their power.

You can do more Flash-like things, but it also means that those specs are a little harder to get adopted into WebKit. So you don’t always get to use the web animations API, for instance, for the longest time it was not available on the iPhone because it gives the browser direct access to basically the animation engine. And that is... Oh, that’s pretty power intensive.

So the standards bodies have to work very carefully to arrange these things. So I think basically by cutting off Flash, we lost a very good on-ramp for creative people into the web. We lost years of work on a visual editor for interaction developers, which we come close with plugins and things like Framer Motion and Figma. We’re getting there. But the point was that just sort of slammed the door shut on that. And that I think we still are reeling from. And we’re still... We are finally, I think, getting to the point where you can build for the web, the same things that you built with Flash. You’ve got HTML Five audio, you’ve got the web animations API on mobile now.

We’re getting to that point finally, where you can do just as much, but we still lack a common editor. There’s just not an agreed upon industry favorite. And you see sites like new grounds where people had created all this content, these games, these videos, these cartoons, you can make anything with Flash. None of that content is really accessible anymore. It’s a graveyard of creative ideas now.

Kathy: One of the things Rachel is currently most known for is their work with React. In many ways, React deals with these discrete UI components they were just speaking about. And I was curious how they contend with illustrations that kind of break that convention and use the framework in different ways, ways that perhaps weren’t intended at all.

Rachel: When it came to React, I did a bunch of interesting things after Microsoft. I worked on motion design guidelines for design systems, which are awesome. Always been a big fan of CSS. And I love how design systems kind of separated the need to have a CSS gatekeeper from producing great interfaces. And design systems tend to be built really well with React and modular component libraries like React. You can store all your interaction and display behavior in discrete components, and you can add them into your interface without having them blow away other things. Back when we did flat file design, where it’s like you make HTML, you style it with your JavaScript, and then you style it with your CSS, and then you sprinkle it with JavaScript so it’s interactive.

That sounds great until you are having like 50 engineers working on one messenger client and suddenly someone adds a bit of CSS and it blows away the experience for people in a certain language group that had those features turned on. It’s not very maintainable or scalable, but when you start packaging these bits of UI as discreet... Well, atoms. This is a kind of atomic design principle there, as like atoms and molecules, and they’re completely self-contained. You’ve got the CSS there. They’re completely oriented around how people interact with them. That’s something I love about React. It’s more like JavaScript sprinkled with Markup. It’s all about the behavior you want to facilitate with the user. And it just makes it so much easier to get something interactive onto the page. So I was naturally curious about this because there’s still some territory between where these libraries are today and how they work with animations.

There’s still ground to be covered there. And I have familiarity already with interaction through the web animations API. And I was like, I want to understand how this works. I’m really curious about this. How can I get a job where my job is just to understand how this works? Because I don’t know about you, but I kept learning React from the ground up, over and over again. But I never really felt like it was sticking for me. And maybe that’s because I learned HTML, CSS, and JavaScript the old fashioned way, in that order. But I thought there’s an opportunity here. And I know that if I can learn something, I can teach it to pretty much everyone. And that’s why I came to the React team. I was like, “Hey, React team, would you like to have me learn once and then teach everywhere?” And the React team was like, “We actually would. Here, start with React Natives. Make the doc site good, make it easy to teach people here.”

Kathy: That’s really cool. Speaking of teaching people and docs, docs are such a good... I mean, obviously such a good way of teaching people. And one of the things that I think we’re trying to do at GitHub is introduce a lot more of the like here are some lessons, here are some tips, here’s some code examples, those kinds of things. How do you get people... Thinking of it from that perspective, how do you get people to think of animation as a core part of their product thinking, of their product design, of their approach to developing products with React? And not just like this decoration or this thing that they think about after the fact.

Rachel: That’s a great question. One of the things I think that really helps is to switch from thinking about your design as like a pretty picture that then some engineers go and implement, but think about state-based design. You’re not just designing a pretty picture. You’re designing different states. Like imagine you were a God and you’re creating a new life form. Well, you could just like, here’s a fully grown... Here’s a butterfly, right? Here’s a butterfly. I’ve made a butterfly. Great. Well, how does it get to be a butterfly? Well, it starts as an egg and then it becomes a caterpillar and then it becomes a pupa. And then it becomes a butterfly. You want to design this system, you have to think about it at all stages of its life.

So thinking about what you’re building, instead of as a static point in time. I’m building a butterfly. Thinking instead, I’m building a life cycle for a creature that is a butterfly. I don’t even know if you can call caterpillars butterflies--that it is its own thing. So when you think about this holistic approach to design, you start thinking in terms of state. There’s the logged out state, the logged in state, there is the state of things loading on the page and those states are really nicely connected with animation.

So this is one of the things I love about thinking in React is that if you approach what you’re building from an interaction informed place, a user informed place. I am a user. I have landed on this page. What is the first thing that I see? What is the next thing that I do? What happens if that content doesn’t land in time? And you start thinking about all these different alternate universes, and you start designing around that. One, it’s a lot easier to implement that for engineers.

You get the use cases right out of the door. Two, the designer can start thinking in terms of designing different states, instead of just different pictures. They can think in terms of “How does this evolve over time?” And three, that’s when you start thinking about animations. Animations come in usually when there’s a need to get someone’s attention or need to show that something has changed on the screen or that something is waiting. Animation to connect states is a key... Well, I like to say it’s a “key part of a balanced breakfast,” but that’s when it really does its heavy lifting

Brian: There are all these different things that we know feed each other, regardless of how disparate they may seem. Rachel is now based in London and given the many communities Rachel has worked in, what did they end up bringing to their React team at Facebook and how did they get started.

Rachel: The first thing I did was I ran surveys and I talked to people in the community because I didn’t know what React Native was. I’ve never worked with anything on iOS or Android before. I work on the web and I barely worked with React. So I thought, all right, I’ll just learn about all three of these things at once. This will be great. So I immediately started reaching out to people in the community and asking them, “When do you use these? How could they be better?” And they were like, “Well, I’d really like interactive examples.” “Sometimes I need to reference the APIs and I get something weird back that I wasn’t anticipating.” And I formed a hypothesis, ran some greater surveys to the community to confirm or deny some of these hypotheses. And I was able to say, all right, we’ve got to update these API docs.

Okay. We’re missing an on-ramp for people who come from different backgrounds. The first thing the doc said when I arrived was, “Oh, you probably already know React so here’s how you do it from mobile devices.” Yet we had 60% of our traffic coming from people who had mobile backgrounds, not web backgrounds. Some people came in with none, and imagine what it’s like. You’re an Android developer, you land in these docs and they’re like, you already know React so here’s how you build for native platforms. We weren’t even addressing these people as Android developers, which is a badge of honor, or iOS developers. Those communities are very proud of what they’re doing and maybe they’ve just landed on a team that’s using React Native for X, Y and Z reasons and they’re trying to fit in and here we’ve just othered them.

So completely overhauled the docs for more inclusive language on many levels, stripping out easy, referring to people as Android and iOS developers and creating on-ramps for folks from different backgrounds and pro-tips for people with different contexts. You might be familiar with this concept from web development because it’s similar to how a design system works.

Brian: You had a great tangent, but I think your approach to having language that is inclusive, but also addressing the fact that one thing is that React Native, it’s a tool to make it easier for folks who write JavaScript or React to build mobile applications. Understanding that there were existing folks who were already there. I’m going to use this term with big quotes, but some folks who already do iOS could think, “Oh, now Facebook’s colonizing our environments and now they’re building a whole other thing to build mobile apps.” And the hearing that you’re able to address that in, not broad strokes, but address it subtly in the way you approach it, it speaks to your background and the fact that you had a metamorphosis in your career to eventually get there and feel like you could provide input.

Rachel: Yeah. And most of the time, React Native is used as a way to let teams do more things. What I found from engaging with the community was that most teams using React Native, they’ll have the person who is amazing at Android development, the person who’s amazing at iOS development, the scrappy startup that can not afford two teams of developers, but can afford a bunch of JavaScript engineers, and these anchor developers and they have this mastery over this entire platform, they end up porting that knowledge and the JavaScript engineers end up becoming mobile developers as well. And it’s a really interesting sort of, I don’t know how to describe it, but React Native teams tend to be melting pots. It’s really more like React Native is allowing the teams to move faster and collaborate together to ship more product with less resources. But that’s what I saw with that.

There are larger teams out there that have different layouts. So I can’t speak to how people actually arrange their teams. I don’t know. Sorry, I’ve gone off. I’m just saying, a lot of the people that I interview come from small startups and they’re trying to make their project available on as many different platforms as possible. And this allows them to do that regardless of their background knowledge.

Kathy: Speaking of coming to the table with many different interests, Rachel mentioned a melting pot of people who come from varying backgrounds. Given Rachel's strong creative side, have they had any struggles or are there any advantages to thinking the way they do when they sit on a team with a lot of engineers?

Rachel: So one thing to be aware of is startup culture versus established culture. I’ll get to the advantages of having a many splendid history in a moment. There are places in this world where having a lot of abilities is super valuable, especially at startups. They don’t need the person who’s an amazing line manager yet. They need somebody who can put out different fires and come up with good ideas to solve real pressing user problems. But as companies get bigger and more established, they tend to form hierarchies. You will be a this, you are a that, you are a product manager and you are an iOS engineer, and you probably don’t want to go from working on product to working on iOS. That’s a completely different trajectory, different leveling system. And that’s one of the more intimidating things about big tech companies is that you do end up getting labeled, you do end up kind of staying in your lane.

But when you work at a startup, when you work at a company that’s trying to come up with ideas that solve problems… This path has taken you through many things, these great resources inside you that you can draw on are very valuable. So if you’re looking at your career and you’re looking at the places that you’re working and it’s just not working, think to yourself, are my skills aligned with what this particular kind of company needs right now? If you were an amazing, an amazing C++ engineer who could run circles around anyone when it comes to making shaders with the GPU. The right place for you is probably not at a game startup, that makes things for mobile. It’s probably you are going to do great working on an operating system like on Apple or a Microsoft, or even at a Google working the mobile operating system.

But if you were a person like me with lots of many awesome skills, community building, teaching, problem solving, et cetera, you probably feel frustrated if somebody is like, sit down and just do this one thing. And you might feel like, “Oh no, I’m no good at anything because I just can’t seem to deliver what these people expect from me. So try to pull back your view for a little bit. There are places in companies where that kind of problem solving, that kind of multidisciplinary ability is going to be really useful and labels will mean less or be more flexible. And there are places where the labels are super important, and these are important things to weigh when you’re considering what you want to do with the rest of your career.

For me, the React team is like its little ecosystem inside Facebook. We’ve got React Native, we’ve got Relay, we’ve got React. All of these core teams, they have their own different cultures, but they all have one thing in common, which is they really care about the open source community and they want to teach people and they need somebody who can help them teach. And they’ve got a bunch of really passionate engineers who want to teach, but their day job is engineering. So my job turns out to be, how can I show these great engineers how to teach better and how can I enable them to get their tribal knowledge out to the rest of the world? And that’s actually pretty gratifying to do. I enjoy it a lot.

Kathy: That’s really cool. So we’re coming into the end of the interview now. So maybe we can switch gears back to who you are and what you’re interested in in particular. I’m curious. You’ve worked on a whole range of things and you’re specializing very much in docs at React right now. If you think about your career, how far you’ve come and where you want to go next, where do you want to leave your mark?

Rachel: That’s a great question because we’re going to launch the docs this year, and it’s an exciting time. It’s going to change the lives of millions of developers. No pressure. To be able to teach folks how to think in a functional way about their user interfaces is special. I’ve learned a lot from this journey and I’ve learned a lot from the team that I’ve been with. I don’t actually know what comes next after this. I feel like there’s still a lot of work to do in the React lands. But I think for me personally, the next mountain I want to climb to the top of is growing my own team. I really love working with people and I love creating a space for people to do their best work. So that’s the dream for me. I don’t have to be up on stage giving talks or hand offering everything myself, but I’d love to see other people taking the things that I’ve learned and using that as a springboard to do their best work.

Brian: That’s excellent. Yeah. I look forward to leveraging those docs when they get shipped as well. And I also look forward to... because you’ve mentioned early in the conversation about ActionScript and how the door was closed. I look forward to continuing to see this React door open as you make it more inclusive and also take an account where people are coming from and what experiences they have too as well, whether they align with your experiences or my experiences or someone we’ve never met experiences too as well.

Kathy: Bringing it back to the beginning of this conversation, Rachel didn’t know and hadn’t necessarily been encouraged to pursue tech as a career and yet they made it happen. Given their past, how do they hope to influence young people in the future?

Rachel: There was a young lady who was interested in interning at a company I worked at and she was in multiple high school programs and her parents really wanted her to be a doctor or a lawyer. And she had a lot of pressure on her because her parents were that first-generation American and they were like, “You got to be the new standard. Don’t let us down.” A lot of pressure. And she was so excited about engineering and computer science. And it’s early at that age to be deciding what you want to do for the rest of your life. But the fact that she was there, even though she wasn’t getting support from her parents on this.

I remember talking to her and I was like, “Do your parents understand that if you get a job working for one of these big companies, you’ll have a six-figure income? You’ll be able to freeze your eggs, be able to have kids whenever you want. You’ll be able to take care of them when they’re old. There are programs for that. These are some of the best jobs you can get in the world right now. In the world. And do they understand that you taking off in this industry sets you all up forever? Eternally. This is as good as those other jobs. Maybe they think you just want to be a game developer, but trust me, this is the door, it is open. It is for you.” And I had that conversation with her and I don’t think they had realized that.

When I was a cartoonist, I used to be very like, “Do what you love. You don’t listen to what the other people say. Money’s not important.” Then I need jaw surgery. Some things are very real and you have to think selfishly sometimes. And I think in this situation, I think that it was a matter of reconciling her needs and wants with the expectations that she was facing. I still think that a role in this industry empowers you to live whatever life you want, to channel your resources to whatever you want. You don’t have to lead a selfless life to have a major impact on your family and your community. You can just be successful. You can just be in the room and change the company’s makeup. You change things just by being there and it’s enough. And I know it feels like you’re never doing enough. You could always be doing more. You’re probably already doing 110%, but just remember, it’s enough.

And people might not see that at first. They may think you should be doing even more, but just to have confidence that if you step in this direction, you’re enough and you should be able to have the data points to back up this decision to the naysayers. So the punk rock Rachel is like, “Don’t listen to them, follow your heart.“ And the current Rachel is like, ”And do it in an industry that compensates you well for doing what you love.”

Kathy: For sure. It strikes me that the parallels between what you were just talking about when working in open source, I think that advice for folks who are going into open source would really help out a ton too, because like you said, you’re working 110%. You’re probably not getting paid for what you’re doing. And you’re probably having people who are using your tools, beating down your door, asking for 120%. And I love that just by being there, just by being in that community, you’re contributing much more value than you could probably even imagine.

Rachel: I think there’s something to be said, speaking to what you said about how in open source people tend to take a lot of responsibility. I’ve seen it. I work with some of these people, and this is true across the board. If you’re lucky, you get a corporate sponsor or you get to work for an altruistic company like MDN, sorry, Mozilla. If you’re lucky. But a lot of people in open source, it’s a pet project that they did in their spare time to solve a specific need, but the responsibility keeps growing and growing and growing, and it doesn’t always lead to a bigger, a better job. You might just be someone in your basement trying to support a vast network of people who depend on you.

It’s important to know how to set boundaries. I say this as a person who once had 400,000 teenage girls reading her comics every week who were always demanding more and would get very upset if I did things with characters that they didn’t like. You have to set boundaries for yourself and remember what you’re getting out of it. Remember what you started doing this for and make sure that you’re not letting other people tell you how to spend your time.

Kathy: I love that. Well, Rachel, it was really fantastic talking with you. Thank you so much. I’ve learned a ton.

Rachel: Thank you so much for having me. It has been great to chat with you all.

Brian: Rachel was so inspiring and we loved having them on the ReadME Podcast. To learn more about Rachel, please visit rachelnabors.com, that’s r-a-c-h-e-l-n-a-b-o-r-s dot com.

I am Brian Douglas, and I am a developer advocate here at GitHub.

Kathy: And I am Kathy Korevek, I work in product. The ReadME Podcast is a GitHub podcast that dives into the challenges our guests faced and how they overcame those hurdles. In sharing these stories, we hope to provide a spotlight on what you don’t always see in the lines of code, and what it took to build the technology that inspires us all.

Brian: It’s been really great spending time with you. The ReadME Podcast is part of the ReadME Project at GitHub, a space that amplifies the voices of the developer community: The maintainers, leaders, and teams whose contributions move the world forward every day. Visit github.com/readme to learn more.

Our theme music has been produced on GitHub by Dan Gorelick with Tidal Cycles. Additional music from Rhae Royal and Blue Dot Sessions.

The ReadME Podcast is produced by Sound Made Public for GitHub.

Please subscribe, share, and follow GitHub on Twitter for updates on this podcast and all-things GitHub. Thanks for listening!