Kent C. Dodds: 0:00 Hi, everyone. My name is Kent C. Dodds, and I'm super excited to be joined by my friend, Jenn. Say hi, Jenn.

Jenn Creighton: 0:05 Hi, everyone.

Kent: 0:07 Jenn and I...Oh, sorry. I was just going to say whenever I do these, I like to remember when the first time was that we met. I think we started interacting on Twitter because of the apropcalypse tweet. Oh, my gosh. This is so great.

0:26 It was 2018 was when I made the Simply React talk. As I was working on it, I wanted to find the open-source component that had the most number of props. I just tweeted about it. It was so perfect. Jenn replied with, "I call that an apropcalypse." That was so great. I used it in my talk. I just loved it. That's as far back as we go.

0:52 Then, we met in person the first time at a conference, or maybe...

Jenn: 0:57 React Conf.

Kent: 0:58 Yeah, React Conf.

Jenn: 0:59 Wait. No maybe one before React Conf.

Kent: 1:02 Maybe React rally. I can't remember now.

Jenn: 1:05 Oh, Atlanta?

Kent: 1:08 No, that may have been it...I remember I came out to New York, I think 2019 to do something and I...

Jenn: 1:17 [inaudible] Cross just know...

Kent: 1:18 We've done a couple of things.

Jenn: 1:20 Various ways.

Kent: 1:23 Anyway...

Jenn: 1:24 We'll get people that like that tweet, by the way, the apropcalypse, and I know it comes from you using it in your talk.

Kent: 1:30 It was so good, just classic. Jenn, I've got to know you the last few years and enjoyed following you and everything. Why don't you introduce yourself to everybody else who hasn't had the pleasure yet?

Jenn: 1:45 Sure. I'm Jenn. Hi. Last name is Creighton. You can find me on Twitter @gurlcode and gurl is spelled with a U, if you want to follow me there. I am a senior staff engineer working on open source at Apollo. Specifically, I work on the Apollo Client.

Kent: 2:03 Awesome. Apollo is definitely a name that most people watching probably has heard before really popular tool. I think that's awesome, so thank you for your work on it.

2:17 You started the beginning of the year with them, right?

Jenn: 2:20 Yeah.

Kent: 2:21 It's been nine months now?

Jenn: 2:24 It's about six months, actually. I started in March. I took a little bit of a break.

Kent: 2:28 OK, Six months. In March of 2020, none of us remember that.

Jenn: 2:35 It was a good time to switch jobs. [inaudible] . It was very scary.

Kent: 2:41 Oh, my goodness. Well, I'm glad that the things have been going OK. Your experience was transitioning. Before you were working on a product, what was that?

Jenn: 2:54 I've been working on products in my entire time in tech so far, so that was about seven and a half years of just straight-up-product work, and sometimes with B2B companies, and sometimes with consumer products.

3:09 The last two places that I worked was ClassPass and then the Wing. Those were both products. They were used a little bit differently. One was a pretty free ranging consumer app that pretty much anyone could sign up to work out book time at gyms or book a fitness class somewhere.

3:28 Then the second one was members-based. If you were a member of the Wing, which was a coworking space, then you would use that app, still products for consumers but just a little bit different.

3:41 Then, I transitioned into open-source full time. I was already doing some community open-source work beforehand, but now it's my full-time day job.

Kent: 3:52 That's interesting. I think anybody who's done much work in open source has some feelings associated with it. For me, it's mostly positive, but there are definitely some struggles with open source.

4:08 I'm curious what it's like to transition from doing some open source on the side, or maybe it's part of your job a little bit to being like full-time open source. What was that transition like? I'd love to hear both the positives and negatives of doing open-source full time.

Jenn: 4:25 For me, it's been such a relief not to work on products anymore, just because I'd been doing it for a long time.

4:36 There's definitely interesting problems to be solved in product engineering, but I was done with it. I was like, "If I build another button component system, I'm just going to lose." Everything in my brain will just fall out. I can't build another thing like this.

4:58 To be honest, I was always interested in open-source projects and so I spent a lot of time late at night crawling through code in repos, trying to understand how things worked, or checking out GitHub issues, pull requests, reading comments, especially in the React repo, because I was using React Dev.

5:20 The majority of these jobs, I've been working with React four or five years now, I was just curious about what the open-source side of that look like, how did things work, what could I glean about what the team, like how they work together.

5:36 Then I'm doing some work in open source, I contributed to some projects, and then a lot of my work has been more community stuff, talks about React and things like that, or community events.

5:49 Then transitioning into actually doing the work on the open source side is so very different. It is so different, and in some good ways, and in some bad ways, but mostly in very good ways for me, ways that I feel very comfortable in.

6:03 That whole thing, where I'm reading repos at night, that is my day job now. I just do that during the day and get paid to understand how things work, and check out new architectural decisions, and try and figure out why we do things a certain way. That is like, "Oh, my God, that is my catnip."

Kent: 6:24 That's awesome.

Jenn: 6:25 It is a thing I love most. That's so great.

Kent: 6:29 It's tons of fun to be able to have for your day job, the thing that you're doing on the side before, right?

Jenn: 6:36 Yeah.

Kent: 6:37 Very cool. Coming from my perspective as an open source maintainer, I spend more time in GitHub, on github.com, than I do in my editor. Is that similar to your experience? If so, why is that?

Jenn: 6:58 I am absolutely on github.com constantly throughout the day. It's because that's where all of the knowledge is. If you need any bit of knowledge, it's not just...I think a lot of people think that open source maintaining is just writing some code, spinning up a pull request, looking at a contribution, maybe trying to merge it in, look at an issue, going to your editor to figure it out.

7:22 A lot of it is this historical, digging through things, especially when you weren't always the maintainer of the project. You're coming in either new, or with a new group of people, or it's got a varied history like the Apollo Client does. It's been around for a while, it's gone through iterations.

7:42 AC3 just launched, which my coworker, Ben, he's the architect of all this, put in a ton of work behind. A lot of my job now is actually going through various pull requests and issues from Ben. Trying to figure out the history of things, so that I can answer someone's question about why something might not be working or know if an issue that needs to be looked at or not.

8:07 That's just where I spend most of my time. I'm very rarely actually, in my editor writing code. I'm more doing this archeological digging, looking for clues, sort of Sherlock Holmes thing.

Kent: 8:21 Are you pretty happy with that arrangement or would you like to spend a little bit more time coding?

Jenn: 8:26 I'm actually really happy with this arrangement. I actually have a project that's specific that I'm leading. I would just do a rewrite of the Apollo Client DevTools. When I actually do write code, it's for that project. That one's a little bit more a product in the sense of the traditional sense back what I used to do.

8:50 Then the rest of it is like this archeological digging of Apollo Client, answering questions, figuring out how things work. I'm only six months in. Actually, in open source, there's not a lot of time to get really spun up on an entire library with an entire history and entire set of why things were done, or why they need to change. Right now, I really like the measure of work that I have.

Kent: 9:18 Especially, six months on a project the size of Apollo Client, and it's not just the Apollo Client that you have to understand, but also all of the pieces that it interacts with, as well, and the entire idea of GraphQL. I don't know if you were using GraphQL before, but that's a pretty big thing too.

Jenn: 9:40 I actually wasn't. A lot of my learning over the past six months has also been GraphQL based. I have always wanted to use it at a job and then it can be very difficult to convince a company to go that way. There's overhead involved.

10:03 There were two or three companies I worked at that really wanted to use GraphQL and then just the consensus of getting all the engineers on board with this change where it just fell flat at some point.

Kent: 10:15 That is too bad.

Jenn: 10:16 You used it at PayPal, didn't you?

Kent: 10:19 I never used it myself, but PayPal absolutely uses it. I worked with teams that used it. I built one app that used GraphQL. We only had a couple of areas where we used GraphQL. Two or three mutations, a couple queries.

10:41 I couldn't justify adding Apollo for something like that. We used GraphQL request for that. It was great. GraphQL is pretty cool.

Jenn: 10:56 It is.

Kent: 10:56 It's got some pretty interesting aspects to it. PayPal when I left, they were working on some cool things where we had a single GraphQL endpoint for all of PayPal's APIs, which are many.

11:13 It's cool that GraphQL makes something like that. I wouldn't say trivial. It's not trivial, relatively trivial. If we wanted to do the same thing with REST type of interface that would be non-trivial.

11:31 It's cool that you're able to contribute to the GraphQL community through Apollo Client, which is used by a silly amount of people.

Jenn: 11:40 We're talking about this before this call started. I've usually been in the react JavaScript eco here. I am moving myself a little bit more towards GraphQL state management libraries in general. Still sticking with React because, of course, Apollo Client is primarily used with React applications.

12:02 I moved a little bit, but I am still pretty close to React. I'll never fully leave the React community. I love it too much.

Kent: 12:09 It is a special place. I like being here. I like that you're here too.

12:14 What's it like to maintain a project that's used by so many people? What's your experience been as an open source maintainer?

Jenn: 12:27 So far, my initial thoughts being only six months in, I'm terrified all the time.

12:33 It's a lot of pressure. When you are building a product, yeah, a lot of people are going to eventually see your decisions. It was pretty easy to like, if you made a mistake, it somehow made it to Prod. Usually there were steps between that would catch it, and it went out.

12:56 It didn't break other people's work, but it's very different in open source. You could break people's work. In that way, it's very terrifying.

13:10 In another respect though, people have a great love and affinity for Apollo and Apollo Client in particular. It feels really good to work on a project that people already have a sense of love for. That they find lovely to work with.

13:27 Especially with a lot of the changes that Ben made for AC3, it's even nicer to work with. I have building applications with it for fun. I really like it.

13:40 Two sides. One, terrifying, could break everything. On the other hand, this is a well loved open sourced project, lots of people who want to be involved. Lots of people with questions, which can get a little tiring. It's also very motivating to do your best work to figure out how best to serve someone.

14:02 I enjoy serving developers. It's nice to be able to build something for developers. It feels nice to know you're helping people in a different way.

14:15 The same way I used to do a Tox where I was clearly my audience was trying to help developers. I get that same gratification out of working on Apollo Client.

Kent: 14:26 That's wonderful. I've been doing open source on the side.

14:34 When I worked on open source at PayPal, it was PayPal projects that we were using. PayPal was financing my open source. I was working on open source during the day often.

14:44 Now, I do open source during the day. Now, because I work for myself, I'm financing my own open source. That can get interesting.

14:51 I haven't technically been full time open source before. I can relate to the joy and satisfaction there is in knowing that you're enabling other people to make the world a better place however they do that with the technology that you make.

Jenn: 15:10 Or just to do good work. We all like doing good work. It's easier when your tools are good.

Kent: 15:18 Absolutely. If I were coming into a new project as a maintainer, or maybe wanted to become a maintainer of a big project, what are some of the things that you'd tell me to look out for? Some pitfalls or maybe some things that I can do to better prepare to be an open source maintainer and be successful.

Jenn: 15:43 My first question when I was interviewing to join Apollo was, "Tell me about how you managed your work-life balance on open source?" That is the first thing that is going to get you is completed and utter burnout.

16:02 Open source doesn't have any 9 to 5 hours. You would on a regular job where you're going in and people are only online for a certain time.

16:14 In the open source world, it expands the entire globe. You're getting questions in times that you're asleep. Maybe you're not asleep like some people on the React team that I know are answering Twitter questions when I'm like "It is 4:00 AM in London. What are you doing?"

Kent: 16:34 For real.

Jenn: 16:35 It's a serious problem, open source burnout. If you want to work in open source either as a full-time job or you're passionate about a library and you want to start become a maintainer, the first thing you have to look out for is yourself. Making sure that you're OK and that you're still giving as much as you can to your job and your friends and your family.

17:00 These are the other things in your life that are going to make open source possible, but if you don't have that backbone, if you ignore it, you're not going to be able to do anything in open source.

17:11 Some of my other advice for people who generally want to get into open source, I think there's a lot of misconceptions about what it means to contribute to a project. There's also a lot of misunderstandings about what the collaborative aspect in open source is going to look like.

17:34 If you're expecting people to be immediately available all the time, immediately be available to answer your questions, immediately be able to provide feedback, that's not how open source unfortunately works.

17:47 Usually, in open source, you're dealing with small maintainer teams. Like you said are often not doing this as their full-time job.

17:56 Even at Apollo, the Apollo Client team is three people, that's it. That's a big project. It doesn't just span Apollo Client, it spans all the tools that go into that, including all of our libraries that have to do with React, or the dev tools extension. There's a lot of work. We can never take on as much as we want to.

18:20 We also can't answer questions, can't provide feedback in a super timely manner, so patience is the second thing that is absolutely required if you want to contribute to open source.

18:31 Also, let's see, the third thing kind of goes along with the work-life balance, but is about keeping yourself on track.

18:39 All your work is usually in GitHub, you can lose track of issues that you need to look at or PRs or other things that you are doing. You have to find some sort of management tool for that.

Kent: 18:52 I've got a couple of questions actually. These two are kind of related. I'm curious what you've found to be an effective management strategy for you. I'll tell you mine first, and then I want to hear what yours is.

19:08 Pretty much, I go 100 percent on email notifications. It gets into my inbox, and if I'm done with it and then I archive it and if I need to deal with it, it stays in my inbox. I'm an inbox zero kind of person, so if it's in there, then it's going to get dealt with eventually.

19:25 One drawback to this, and I'm curious if this is your experience too, is, like you said, open source...People are constantly using and asking questions overnight while you're sleeping, so when I wake up, it's very common for me to wake up to 15, maybe 30, sometimes more emails from GitHub on my various projects. I have over a hundred modules on MPM.

19:51 Not all of them are very active. Most of these are testing library. I wake up with a silly amount of notifications. Some of them can be dealt with in a second, but those seconds add up.

20:06 Then because I'm such an inbox zero person, I think it gives me a little bit of anxiety having those messages in my inbox.

20:17 Anyway, I'm curious what your strategy for dealing with that because I mentioned that Apollo probably gets a fair amount more notifications because of the size and the number of the people who are trying to use it. What are your strategies for that?

Jenn: 20:32 We do get a lot of notifications, but I think everyone on our team probably has a different way of doing it, and I need to ask them this question on Monday. No, Tuesday because of the holiday, and then we're all in the office again.

20:49 I'll, maybe, collect their answers because this is a really good question of how you manage this. I'm still working on my system. I'm by no means got something down because I'm only six months in. This is going to take some iteration.

21:03 Right now, I'm using a bit of...We use assigning on the issues that need to be looked at. I keep a tab open with my assigned tasks there. I also copy all of them into Notion, in a task queue for myself.

21:20 I look at that pretty much every day and see what was I doing last, what do I need to do, and then I reprioritize my queue, and then move things into done when they're merged, if it has to do with that, or the task is done, depending on what I'm doing. Then I take copious notes during meetings and stuff because it helps to remind me about things.

21:45 It's not because I'm going to go look back at my notes, there's just something about me writing something physically down that helps my brain. Occasionally, when I have something that I'm like, "We need to remember to do something later." But I don't think it belongs in the task queue.

22:05 I want to keep it in mind, I will write it down quickly, and somehow that, I don't know, motion for some reason locks it into my brain a little bit better. That's what I'm trying out.

Kent: 22:21 That's good. It sounds like something that I considered as you were talking about that. Another approach for me that would solve my flood of email, is to maybe go with that mentality of, "Everyday, I could have my open source block of time."

22:42 Then I go and look at all of those issues that were opened between the last time I looked and now. Then deal with them at that time rather than waking up in the morning and grabbing my phone lying in bed trying to do open source on my phone, which happens a lot.

23:00 I probably have released as...I have automated releases, and I think I've probably released as many versions of my packages from my phone as I have from my desktop, which is probably not a good thing. It's cool that I can, but I don't think I should do that. Maybe I'll [inaudible] things up a bit. It'll be a little less...

Jenn: 23:17 Yeah, you're on-the-go with these things. You're like, "OK, new version out for you." Yeah.

Kent: 23:25 Having Notion set up, it sounds like you're very organized, which I think you would need to be.

Jenn: 23:31 I have to be. I have ADD. I have a coping strategy which is list, more list, list, list, list. Write everything down, create tasks, put things in a calendar. My other big thing that I do is that I use Slackbot a lot to remind me of things.

23:53 I love my Slackbot. He's my little friend. I'm like, "Remind me to do this thing." It frees up some capacity in my brain to do something else. Then I can safely rely that on any of my devices, he's going to be able to notify me, "Remember, you need to do X." I'm like, "Cool, thank you."

Kent: 24:14 I use Todoist, a combination of Todoist and my email inbox snooze stuff to do that. I agree, and the calendar too. As much stuff as I can get into this machine and out of my brain as possible.

Jenn: 24:32 Yeah, and then when you need to take vacation, you shut off all the devices.

Kent: 24:37 It's brilliant.

Jenn: 24:38 Then you're done for a bit.

Kent: 24:41 That's great. Jenn, as we are coming down on our time, what else about open source do you want to talk about before we wrap up?

Jenn: 24:53 One of the things that has surprised me, I asked this question on Twitter, I said, "If you wanted to contribute to open source, what has stopped you from doing so?"

25:03 A lot of the answers were things that we hear pretty often, which is, "I don't know where to start. I'm not sure how the process works. I don't know which projects to choose." Then there was another one that I found surprising. That was people berating themselves for not contributing to open source yet, and saying it as if like, "I know I have to do it at some point."

25:33 It was a weird mentality, and so as much as I love open source and I want people to contribute and get involved, it's got a lot of benefits to it. You can level yourself up. You can get things to put on your resume, it's a great tool.

25:53 No one should feel like they have to do it. If you do not have time, if this isn't your style of working, it's cool. You can just do what I do and read some open source once in a while or just don't, it's totally fine.

26:11 I'm really not sure where this "I have to do it" came from, but I want people to know also, it's cool, you don't have to.

Kent: 26:21 I like that perspective. One thing that I use as a way to combat burnout for myself, is I made a rule that if it's not my problem, then I don't care.

26:33 It's not exactly how I feel about it, but that's sort of how I deal with it. I only work on stuff that is impacting me directly, or I'm interested in working on it for the fun of it. That [inaudible] feel less pressure.

Jenn: 26:52 It can also take a long time to find a project that you're that passionate about. No one needs to put that amount of pressure on themselves to do this sort of work. It, at some point, will maybe come naturally if you find a project that you're interested in, and maybe it won't, but it's all good.

Kent: 27:12 I think that's a great way to wrap up, or a good thought to wrap up on.

27:17 You already mentioned we can reach out and follow you on Twitter @gurlcode with a U. I like that. Is there any other last tips, or a challenge, you want to give to folks who are watching to help them stretch themselves a little bit?

Jenn: 27:36 I just said you don't have to do open source. I totally mean that, but if you're super interested in it, I think playing around with GitHub and understanding how you can comb through issues and pull requests is going to help you in your day-to-day job as well.

27:54 Often, you join a company where there is a lot of history, and being able to figure out how those things work and how you can search for things and find answers, especially in commit messages and such, it's going to help you a lot.

28:08 It's also a lot of fun. You find some funny things in the repos. Trying that out is a great first step to wade into the waters.

Kent: 28:18 I think that's a good tip. It's always fun to look at these big projects and see the early commit messages before they got all formalized and stuff.

Jenn: 28:29 Yeah, and some projects, they have really great explanations of what they're doing and why, and it amps up your enduring knowledge, so it's fun.

Kent: 28:40 That's great. Well, Jenn, thank you so much. This has been a pleasure. I hope that everybody gives open source a try, if that's what they want to get into. I think it's fun. It's helped me to be a better developer, that's for sure.

28:53 I wish you the best with everything that you're doing with Apollo Client. Thank you for your work, and we'll see everybody later.

Jenn: 29:01 Thanks, Kent.

Kent: 29:02 Bye, everyone.