EPISODE 1630

[EPISODE]

[0:00:00] ANNOUNCER: Netflix needs no introduction, and is renowned for its engineering talent. Shaundai Person is a senior software engineer at Netflix, blogger, and conference speaker. She joins the show today to talk about getting her position at Netflix, developing internal tools at the company, the value of TypeScript, what makes a great software engineering manager, and more.

This episode is hosted by Josh Goldberg, an independent full-time open-source developer. Josh works on projects in the TypeScript ecosystem, most notably TypeScript ESLint, the tooling that enables ESLint and Prettier to run on TypeScript code. Josh is also the author of the O'Reilly learning TypeScript book, a Microsoft MVP for developer technologies, and a live code streamer on Twitch. Find Josh on Bluesky, Mastodon, Twitter, Twitch, YouTube and dot as Joshua K. Goldberg.

[INTERVIEW]

[0:01:04] JG: Shaundai, welcome to Software Engineering Daily. How's it going?

[0:01:06] SP: Thanks. It's going great. How are you?

[0:01:10] JG: I'm good. I'm good. We've talked a few times before. We've met at the Occasional Conference, talked on Twitter, and I'm really excited to get you into the virtual podcast booth. I feel like we've both been playing with TypeScript for quite a few years now.

[0:01:18] SP: Absolutely. Yes. That's our mutual bestie, TypeScript.

[0:01:26] JG: Mutual bestie. I would love to know, just for our listeners who haven't talked too much online, who are you? And how'd you get into coding?

[0:01:34] SP: Awesome. Yes, I am Shaundai Person. I'm a senior software engineer at Netflix. I am also a conference speaker. I'm a blog writer. I am a mother as well, and that's the biggest part of my life. I have a six-year-old. How I got into coding, was I'm self-taught. I previously had a career in sales for about 11, 12 years, and I taught myself to code, when my baby was little. And yes, I worked with a mentor and I loved it. I gave myself half an hour a day, every day because I was working this really demanding sales job and I was caring for an infant at the same time. So, I gave myself half an hour a day to pick it up as a hobby. I found it so interesting. I really loved it so much that I would stay up until three, four in the morning, almost every day after I put my son to sleep, just playing with JavaScript. This is before I got into TypeScript. But playing with JavaScript and React.

[0:02:35] JG: A lot of parents described staying up late hours. You might be one of the rare ones that describe it as despite the kid, you stayed up for quite some time.

[0:02:42] SP: He was always a good sleeper, which I'm very lucky about. He's just a calm, chill, kid. But yes, even though he wasn't waking me up in the middle of the night, all the time. I was just up doing my own thing. It was perfect.

[0:02:56] JG: That sounds great. Do you find that there any lessons you learned from coding that apply to raising a young child or vice versa?

[0:03:03] SP: Oh, my goodness, yes. There are so many things. I've written blog posts and then I have this list of blog posts that I still want to write. There's one that comes to mind right now, what potty training taught me about teaching people. So, my big philosophy when I'm learning new things, I found the best way to learn new things is to teach other people. Actually, this is the same thing with TypeScript. Before I actually know something, if I have a question in my mind, I'm like, "I'm going to teach that to somebody else. I want to learn remix. Let me volunteer to do a conference talk and teach it to other people." And that's my way to learn it well enough to be able to explain it to other people.

So, how this comes into play with potty training, is potty training is a big - Josh and I were talking before the podcast started about like the woes of parenting and how crazy it is that I'm in charge of a human. So, there's stuff that I didn't think about until I became apparent. Potty training is obviously something that we as adults have known for a long time, but to teach a new human how to use the bathroom, it's a lot of work. It's different. I did notice that - I read this book. It was supposed to be like three days into your dream potty-training child or whatever. You're going to be out of diapers in three days.

Day one comes and I'm sitting my son down and I'm like, "All right, cool. We're going to do this." By the end of the day, we're going to be almost there, and like, he was not getting it. I was so frustrated by the end of the day. I called my mom and I was like, "Listen, he's just not ready. Let's just leave him in diapers. He'll be in his 30s. He'll figure it out at some point." My mom was like, "You know what, I think you're the problem because", she's like, "Think about it. You're giving him tools, a potty. You're giving him tools that he's never seen before. You're using language that he's never heard before. You're expecting him to respond to something that he's never had to think about before. He's supposed to take this action based off of something, and you're expecting him to just click with him. You need to meet him where he's at. Understand what his level of knowledge is. You, as a mother, know how to communicate with your baby. So, communicate in the way that's best. Forget the book. Just communicate with him, as you know how to communicate with another human, with your little human." That changed so much for me. 

So, I thought about how I teach, and tech is the thing that I teach the most of, but I thought about my style of teaching. It's like, so often, we kind of forget what it's like to be a newbie. I still am a newbie. I'm going to be a newbie for the rest of my life. I'm never going to call myself an expert at anything. I don't think. But you give people these tools, you give them VS code, or you give them like these frameworks that they've never seen before. You start using language that they've never heard before, talking about literals, and all these types of things. Then, you're expecting them to be able to architect things in a way and think in a way that they've never thought before. And you're coming in with all these assumptions that people already know this, they already know that, and just expecting it to click for them and expecting it to go together. And then getting frustrated when people don't understand it or pick up the things that you're teaching.

Potty training itself, flipped the way that I teach. That was a big thing that I learned from parenting, and also just like the patients, and I try to keep my son as involved in the code as I can. So, I find myself building a lot of tools for him. I built a letter-learning program for him before he turned two for his birthday, which was last week, actually, a week ago today. He got like this little coding - not baby coding, but like a six-year-old coding stem thing that I'm really excited to use with him. So, I try to get him involved in different things and I'm learning as I'm teaching him, and he gets to see a glimpse into, mommy's an engineer. So, it's cool. It's cool.

[0:07:05] JG: I'm a little jealous of your son for having a parent that's so involved with him with the code. I didn't get involved with that stuff till my mid to late teens. That's wild.

[0:07:13] SP: Same.

[0:07:15] JG: Yes, I'm curious, though. So, you got into coding, and you really dove into it. But what was that change for you that, "Oh, this is what I want to do", that even before you started, kind of got you into it?

[0:07:26] SP: Yes, that's a great question. I was avoiding it for so long, because I had this stereotype in my head of what a software engineer does, and it's the same stereotype that you could probably imagine is just like, these little dorky people, they have glasses, and just sit in dark rooms, and you drink Diet Coke, and you're no fun. You don't know how to talk to people. You're super socially awkward. And what's crazy is that I am all of those things. I got LASIK. I have bad eyesight. I'm a dork. I'm awkward.

But I was never ready to embrace that. I can think back to different points in my life, where I was like, "Man, code has been calling me for the longest time." This is always something that I've been super interested in. I got my first tech job. I was selling tech. So, I consider myself like, I've been in tech forever. I just haven't been on the engineering side. But in 2011, I got my first job in tech and I was selling software to literal rocket scientists. NASA was my customer. And I was selling the software for mathematical computation called MATLAB. If you have a CS degree, you probably used it. But I was so fascinated with what my customers were doing with the tool. What you could do with a programming language.

There were some people who were getting us to Mars, and then there were other people who were using the same software to measure the combination of chemicals that needed to go into the soil to grow the largest oranges on a farm, for example. So, I'm like, "Wow, this is really cool stuff." But still, everybody had advanced degrees in like astrophysics and mathematics and applied physics, all different things that I was just not interested in. So, my undergrad degree was in entrepreneurship, which is like a field in business at the university that I went to, and I decided to pursue my passions for entrepreneurship in 2015, 2016. I just quit my job, and I was like, "I'm going to start a business." It started out as an online business powered by Shopify. I was selling organic and natural, everything. Anything you would see in like a Whole Foods like Pet Care, Baby Care, snacks, all those kinds of things.

I was using my sales skills to get customers and to get these really big deals. I got like a really big customer, and I was really excited about that. But I found that what I would spend the most time on what I was the most interested in doing was learning Liquid, which is Shopify's Ruby-based language to customize my site, and to make little widgets that had marketing automation, and send my customers automatic emails, or put banners about the sales that we were having and things like that. It got to the point where somebody was like, "Oh, could I pay you to customize my site? How did you get your site to look like that?" I was like, "What? Like, I could get paid to do this kind of - like, I would do this for free, honestly." But people were asking me if they could pay me to customize their site. I was like, "Sure."

So, that was where the spark started, and I was like, "Wow, maybe like robotics programming isn't the one for me." Maybe like chemical, whatever you call it, the chemical stuff to figure out the chemicals go in oranges. That's not the type of coding that I want to do. Maybe it's a web development. So, once I found that, and I found front-end, that's when I was like, staying up until three in the morning. I'm like, "Oh, my God, I could make this button turn blue. And if you press something, things will happen." That was really exciting for me, and I still haven't lost that excitement. I love it here. This is great.

[0:11:08] JG: Even though you're now turning buttons red at Netflix instead of blue.

[0:11:11] SP: Absolutely.

[0:11:14] JG: I love it. So, you started off on [inaudible 0:11:17] on the independent store. You learned about Liquid from Shopify. How did you eventually make your way to Netflix?

[0:11:23] SP: Oh, so I was working at a company called Salesloft. That was my first engineering job. Okay, so my manager, Ryan Burgess, he is also a speaker, and a content creator. He has his own podcast. While I was learning to code, I was immersing myself, and this is the way that I do everything. I don't have to do anything. I'm all in no matter what it is, right? So, I immersed myself in the coding. When I was commuting for my sales job, I was listening to podcast, I had an app on my phone from Code Academy, and I was just like doing little code tricks in my meetings, not paying attention all the time.

So, I was listening to Ryan's podcast on the way to work and I loved it so much. It's called Front End Happy Hour. And they have like a keyword and alcohol is involved. So, I was like, "Oh, two things that I love, whiskey and coding." I was like, "Oh, this is great." So, I binge-listened to like seven years' worth of episodes in like two weeks. I tweeted about it. And I was like, "Hey, does anybody have any other recommendations for podcasts?" And Ryan tweeted me back from that handle, and that's how we became like Twitter mutual, stayed kind of in touch through Twitter. Then, one day, he posted this position on his team.

Through listening to his podcast, I was like, Netflix wasn't on my radar. And Netflix is not like - I mean, it's a big company. Of course, for engineers, engineers know Netflix is a great place to go to as an engineer. But in sales, like I didn't have any concept of, "Oh, Netflix is like a thing, or whatever." Maybe I'm just living under a rock or whatever. But the reason I wanted to go to Netflix was mainly because of Ryan, and other people on the podcast, Jim Young.

Anyway, when Ryan posted about this position, I was like, "Man, I would love to work for this guy, because he just sounds so awesome, knowledgeable." I've seen his talks, and I just didn't think that I was ready. So, I reached out to him. And I was like, "Hey, I'm not really ready for this. But will you have roles coming like maybe six months down the road or something like that? Can we talk about what skills I would need to prepare to interview?" He was like, "Sure, let's have a conversation." Through that conversation, he was like, "Hey, I think you should just go ahead and apply. The worst that they can do is tell you no, and then they'll give you feedback about things that you can do to improve for the next one." I applied, and I ended up getting that position. So yes, the rest is history. I'm still on Ryan's team. He's awesome. Team's awesome. Netflix is awesome. Everything's great.

[0:13:58] JG: People say that the most important part of a team is the team that when you're on a consistent job for years, that it's the people around you who really make or break it. So, when you say things like, "The team is awesome. Netflix is awesome." Could you be more specific? What about them is awesome that's kept you there?

[0:14:13] SP: Yes. That's a fair question. So, Ryan himself is probably the best manager that I've had. He's definitely top, top, top. So, reasons why is he is just super supportive of everything that's like - so he leans into conversations about growth, about diversity. And it's like, he really cares about the success of his people. He has his tribe and then he does whatever he can to make sure that you're successful. But he doesn't micromanage. He's just like, kind of hands-off, and lets you guide the relationship. That's the way that I work the best is when I know that I have a resource that's available for me to go to. He's great at being able to navigate the org and help me to understand like, this is where politics might come into play, or this is where you would want to do this differently so that you come off in the way that you intended to. Or if I have a piece of feedback that I need to give to somebody, this is how I would do it, or you could practice with me.

So, he is there as a resource for me to be able to go to if I need, but he doesn't put these boundaries on me. And what's funny, I was thinking about this, you're just sitting in the bed, like this is before my alarm clock went off this morning, and I couldn't go back to sleep. And I was just thinking about how - one thing that I love about Netflix is the analogy that I use, is when I started, it felt like a village. Okay, so that sounds weird, but I'll explain. So, at Netflix, it's like you come in and people assume that you are smart. They assume that you have a set of skills that are valuable and can contribute well to the org. So, it's like a village. You have your cobblers. You have your farmers. You have your bakers. So, people just come together, they have shops and things like that. And they're like, "Oh, shoot, you make shoes? Come on over. We need a shoemaker. Come make shoes and we'll pay you for that."

At Netflix is just like, "Hey, what can you do? Oh, you're great at front-end. Okay, well, we need you on this project. Or you can spin up your own project. You identify a problem, and you have the freedom and flexibility. You can contribute in whatever way that you want to." So, the types of personalities that I find thrive at Netflix are the people who operate well with ambiguity. If there's a whole universe of possibilities of things that you could do, you have all the resources that you could need, access to support, it's just up to you to figure out how you're going to do that, and do it in the best interest of Netflix. You just do, I say, whatever. But like you just do what's in the best interest of Netflix. You find the problems, and then you fix them, and those types of personalities operate really well.

I found that the types that don't operate as well are the types that need that exact structure. I need like a list of tasks, and I need to be handheld, and I need to be told, "Okay, this is the right thing. This is what is going to get me to grow at the company. This was what will get me promoted and all that kind of thing." If it's harder for you to operate without strict exact rules, then it's probably not the best fit. But I find that works for me, and that's one of the reasons I love being here so much.

[0:17:37] JG: Sure. So, you work well in not that there is no structure, but that the structure allows you to flex and grow and find the challenges that you want to work on that are beneficial. What are the challenges you want to work on that are beneficial for the company?

[0:17:49] SP: Well, my org is the productivity engineering org. Basically, it's exactly what it sounds like, is our job is to make engineers as productive as possible. Our customers are other Netflix engineers, and we build the tools that it takes to create as little friction as possible for them to be able to do their job successfully. One of the big initiatives that I'm working on now is a tool that is built to manage the lifecycle of a repo or a piece of software in Netflix. So, there are a lot of tools that we have built in-house that help you to manage this lifecycle. It can be like pull requests, or builds, or what we call alerts are recommended. Just like regular code, hygiene type of things, and all of that information lives in all of these disparate tools with very creative names, and the documentation lives in a whole other place where it's hard as somebody who's onboarding. But even as somebody who's been at Netflix, it's hard to know where to go to for what.

So, this tool that we're building gives a common interface, and just a single pane of glass for all of that stuff to either live, or to be able to navigate to, from. Yes, that's the bigger challenge that we're doing right now. A lot of this stuff, I've seen other productivity orgs spinning up at other companies, and I think I'm really excited to see that a lot of companies are putting this effort into making their engineers more productive because it is needed. It's necessary at companies. But a lot of the stuff is new. Things that other companies haven't seen or done before. So, it's exciting and challenging at the same time, because you're building something that there isn't really a blueprint for sometimes. That's challenging, but it's also exciting, because you get to kind of be a pioneer in a sense, and do things that navigate waters that have never been navigated, or uncharted, uncharted waters.

[0:19:59] JG: It's funny you mentioned all these things together at Code Academy where I worked previously. We had a similar sounding org, where we set up the tooling and processes for products, especially the web platform side. and there's a sweet irony that you want people to be able to go without being fed the spoon of this is exactly what you need to do. But then you also want to tell people, these are the ways to do things. These are the tools you're going to use. These are the TypeScript, the React, the et cetera, best practices. How do you manage that balance between giving people the tools and telling them to choose the tools that they want?

[0:20:30] SP: Wow, you're asking great questions. So yes, it's the stuff that we have to think about as the productivity org, so we have the concept of pave path. If you're not familiar with it, it wasn't something that I was familiar with before Netflix, but I don't think it's a Netflix-specific term. We have our recommendations for the tools that you'll use, and let's just use one simple example. Let's say, that's all there is to Netflix, which isn't the case. But we're just using this as an example. Let's say that for front-end engineers, the paved path is to use VS code, react, TypeScript, and our component library that our component library team has built. If you want to use tools outside of that, for your front-end, you're more than welcome to because we give you the freedom as Netflix, as an org, we give you the freedom to make the decisions that you think are best for the org. We trust you to have vetted the tool, understand the tradeoffs, explain those tradeoffs, farm for dissent from your colleagues, asked people to weigh in, play devil's advocate, tell you the pros and the cons. And then you, as the decision maker, we call it the informed captain, you as a decision maker, are making this decision with all of that in mind.

But because it's not on the paved path, we aren't going to invest in supporting you. We're not telling you no, but we have to be strategic about our time, and we have to prioritize the things that are on the paved path. So, if you decide that you're going to go off the beaten path, then we can't support you with our tooling. And this is probably something that you're taking into consideration as you're deciding whether or not you're going to adopt that tool that's off the paved path. But that's it.

So, it's kind of gentle-ish encouragement by making it so much easier for people to operate using the tools that are already approved on the paved path. And people will generally, naturally go on that way, because it's a lot easier.

[0:22:33] JG: What an appropriate analogy to be like saying, that's equivalent to using an any in TypeScript. You can do it, but it's not the paved path.

[0:22:42] SP: Yes. And this is like, okay, you have to show, not have to show but like, it's best practice to show that we've tried other things, but this is why we're using any in this case. We're going off of what's recommended, but there's really good reason to do that.

[0:22:57] JG: Sure. For our listeners, who aren't TypeScript aficionados, like you and me, what is an any in TypeScript? Could you explain what I just said?

[0:23:06] SP: Oh, yes. An any is - see, I feel like you'd be better at this. But an any is just basically a catch-all type. Let me know if I'm wrong, too. I'm just going to take us why I got it. But an any is like a catch all type. So, in TypeScript, you can define your types, you can have them be implicit or explicit. Explicit means that I have told you explicitly what the type is going to be, and I've resolved errors by just declaring a certain type as any. And any is like - I'm trying to even use an analogy for any. Any is like the master key. It could open all the locks for TypeScript. It would just help you get around those errors and that fits in as any type. It's the play-the-fields version of a type.

[0:23:55] JG: The play the field. I previously referred to as the YOLO type, and I think your analogies are a little more appropriate and professional.

[0:24:02] SP: I was going to say the YOLO type. I was going to say the YOLO type. I should have did it. I always use -I say JavaScript is the yellow language. But yes, it is the yellow type. That was the definition.

[0:24:14] JG: It really is the YOLO language. Because a lot of the time in JavaScript, it's written well for the time that it's written, but one of the advantages of Typescript and please correct me if I'm wrong here is that it allows you to evolve at scale, that TypeScript provides those safety nets, those developer tools, et cetera, that allow you to keep a codebase log lived without exponentially introducing more bugs. Is that what you found at Netflix? Are there any other reasons you've introduced that as part of your paved path?

[0:24:41] SP: Yes. That's exactly it. So, I did a talk about TypeScript in a blog post about it. What's the point? That was my big piece of friction when I was starting with TypeScript because I was like, "Okay, listen, my code works. So, why would I introduce these types and just have to deal with these red squigglies?" It feels like I'm moving backwards, like, why am I - I'm basically decorating it with red squiggles, and it's just a hassle, like, I could just code something else with my time. So, I ended up seeing the light. One of my friends introduced me to TypeScript in a very Shaundai-friendly way, and I learned enough about it to see the benefits.

So, I was like, "I know I'm not the only person who doesn't want to adopt TypeScript because of this." So, I wrote a blog post, and then I turned it into a talk. The reason why Netflix, my last company, Salesloft, so many large companies, small companies, medium companies are adopting TypeScript is because it keeps your code maintainable, and scalable. And it also helps when folks are onboarding to your code base, helps them to understand what you intended to do. What that code is intended to do? What are the inputs? What are the outputs? I did use an analogy of a toaster, right? If you're onboarding into a code base, think of it like a toaster. You really just need to know what is - when you're making a piece of toast, you just need to know that the bread goes in, and then a piece of delicious toast will come out, right? You don't need to know how all of the different ins and outs work, what is setting the radiator off, and where the wires are plugged in, and all that kind of thing. Just what's in and out. Right?

Same thing, when you're onboarding into a new codebase, you want to know what params are going in, what you're going to output as the end of the function, and when you're refactoring, that's really the most important part, and then that's the place that you start with, for me, I guess to where you start with onboarding into a new codebase. And TypeScript can help with that onboarding. It can help with making sure that the code as it's growing, as you're adding more engineers, or as you're switching engineers, between projects, make sure that that code is still doing what it intended to do, and it helps you to just plug things in a lot more quickly.

If I'm coming into a code base, I'm trying to refactor something or I'm trying to add in some functionality, I have to have some sense of what the code is doing. And TypeScript can very easily help you to get to that point. And then it also helps your code to stay less error prone, because it can tell you before you've even done your build, it can tell you what issues are there in your code. Or it can help you identify different edge cases that you might not have thought about.

So yes, it's a pain in the butt sometimes, because of how many errors, and the errors can seem overwhelming. I know. But definitely when you're growing a codebase, when you're growing an engineering team, you need some guardrails. JavaScript, to me is still YOLO, even with the TypeScript chains on it. But it's a lot more secure for the long run.

[0:27:59] JG: You've mentioned that there can be paying with TypeScript, such as the editor complaints, the red squigglies. There are people who are reluctant to use it because of the added complexity or difficulties and error messages it brings. How do you set up an effective organization, either on your own team, or for other teams, where people who may not agree with the tech choices, such as using TypeScript can still feel productive and welcome?

[0:28:21] SP: Okay. So, I'm going to take it from two angles, right? So, when you're on a high-performing team, and the team already has an established repo using certain tools, it's my opinion, and I think, the opinion of many others is that you try to stay on that paved path for that repo. So, Netflix in general, we operate using micro services, and you have the ability to use whatever tools. Like, if you're starting a new project, for example, you have the ability to decide what tools you're going to - like if you're going to use libraries for data visualization, or something like that. You have the ability to introduce new tools.

But for just decisions about what language you're going to use, I think it needs to be more of a team decision, especially if you're working with a large team. I think the team needs to agree that this is the language that you're going to use, or if we're going to use TypeScript, everybody needs to be on board with that. If everybody's not, it has to be a deeper conversation, because I feel like that's a signal that your team isn't aligned on the engineering vision.

So, it made me think of an anecdote, but this is a story from another team that migrated to TypeScript, and they weren't using - this at Netflix. They weren't using TypeScript previously before that. The woman was walking me through her process for introducing this new tool, and the first thing that she did was listen to the objections. And all those objections are the same things that we talked about the red squigglies. This is going to take me back. To most engineers, adding in TypeScript sounds like tech debt. It sounds like you're taking a step backwards, you're going to have to take other things off of your plate, like adding new features, testing and things like that. You're going to have to take all that off your plate in order to make this effort to make this happen. So, what else are we going to take off our plate? 

She first heard those objections, and then built out this plan for a phased approach and how we're going to get everybody on board to - not get everybody on board, but how we're going to make this happen. I guess, part of that is selling the fact that TypeScript is the best tool to all of the engineers. But the way decisions happen at Netflix, and I recognize that this might be unique. It isn't unique to Netflix, but I think it happens in a similar way, just with different parties. But the way that it happens at Netflix, is that we have for big decisions, we have an informed captain. That's like the title of whoever's leading a project. We don't have - we're pretty flat as an org. But the informed captain will make this decision and then work to get everybody on board.

We'll farm for dissent, which is another term that we use a lot at Netflix. We'll ask people for their objections. We want to hear them. But if we're stuck at a stalemate, and one person strongly believes we should use one tool, and the informed captain strongly believes that we should use another tool, the informed captain's decision is the one that we choose. So, we get everybody on the paved path by following what the informed captain does. It's like we'll disagree, but commit to whatever the solution was. Did that answer your question in the right way? I

[0:31:41] JG: I think it does, yes. There was a popular decision-making framework, actually quite a few of them. But DACI, driver, approver, contributor, informed that other companies use. Is this in any way similar or reminiscent to that one?

[0:31:55] SP: Okay. Yes. So, in general, we'll just have the informed captain as the driver, and then everybody else is probably contributors. So, that's pretty much it. Informed captains are also approvers. Everybody is an approver.

[0:32:10] JG: Sure. I want to change subject just a little bit. We've talked about TypeScript, love TypeScript, but there are other continuing the analogy, stones being paved into the road. You've mentioned React. You, I think, maybe previously mentioned testing. Are there any particular favorites of yours that you like to see on that path?

[0:32:28] SP: Oh, yes. React. In general, I'm not opinionated about tech. So, you'll never - I say this, and it could change. It'll be years and years and years before I get to the old crufty engineer that's like, posting flaming like, "I hate this." Or, "This is better than that." I'm just go with the flow, because I'm so enamored with code in general. But my favorite is React. React, that's my love. We go together real bad. Me and React are like this. I love my React. TypeScript, I love TypeScript with React. I go through these waves of testing where like, I'm really excited about it, and then I'm not excited about it. The times that I'm really excited about it are the times when I'm not doing it. So, I guess I'm not really that excited about it. I don't really like testing.

[0:33:20] JG: Interesting correlation there.

[0:33:25] SP: If somebody else writes tests for me, and then they pass, I'm like, "Yay, go test." But I don't want to do it. I really don't want to do it myself. I've heard that ChatGTP is going to be able to do a lot more of this for me. So, I'm really excited to use that probably this week, I'll get started using that. Yes, and I'm big on - so, at Netflix, we have - I love companies that have component libraries. I've never worked for a company that didn't have a component library, like their own in-house one. But at my last company, I worked on the team that built the component library. So, it helped me to think of things in a very different way, like coding. I had to think of things as everything had to be componentized and extensible, and I had to think about people's problems beyond the way that I was applying them. It was really cool.

But I love our component library. It's called Hawkins. So, if you've ever watched Stranger Things, the town that they're in, is called Hawkins. That's our component library. I don't know what it is about component libraries, like material UI. I just get so excited about the fact that components can do so many different things. Like there's so many different applications of the same thing. Like you can take one thing and just use it in multiple ways. I think that's what fascinated me about programming in MATLAB in the first place is just like, wow, you can use the same language to get us to the moon. And you can also use it to - kids are using it in these competitions to build little toy boats or we're making all kinds of things. It's so fascinating to me. All the levels of things that you can do with code.

[0:35:09] JG: A lot of people make the analogy that there's a shared joy in using stuff like LEGOs or other building blocks toys, as there in coding. And then component libraries, collections of buttons, form inputs, headings, texts, whatever. It is much more directly, almost literally the same thing. You're taking these building blocks and finding the cement to content behind them. That must bring you some joy. 

[0:35:28] SP: Yes, that is such a good analogy. Yes. The other LEGO analogy that I've heard. I mean, I can't remember his name. But it's a talk called Simple, Made Easy. Gosh, I can't remember his name. But it's an amazing talk. Well, he uses the analogy of LEGO Castle. This is making code composable. So, if you're not familiar with the term composable, you make your code like a LEGO block. So, it can operate on its own, as its own individual LEGO. It stays as a little block, or you can put it together with something and it can easily get clicked into other LEGOs. It has the inputs and the outputs. So, he used the LEGO Castle versus like making a castle out of yarn.

If you're going to refactor, much easier to refactor a Lego Castle, you just take things apart and put them back together, versus yarn where you'd have to cut spaghetti code. But that's exactly what you said, just making those little blocks, and plugging them in, and you can reuse them. I love hooks, like using hooks, making hooks, I'm like -

[0:36:38] JG: React hooks?

[0:36:40] SP: Yes, React hooks. I'm like, "Man, who am I? Who am I?"

[0:36:45] JG: Let's continue the analogies. Some people talk about spaghetti code. But I think in real-world applications, it's either spaghetti code or something more akin to lasagna, where you have these different layers building on top of each other. Do you have an opinion?

[0:36:59] SP: I'm not sure if I'm 100% with the lasagna analogy. I'm not buying it. Because if you want to take it apart and turn it into something else. Okay, so LEGOs, right? You can take them apart and they can operate on their own. You can't on lasagna. You can't like undo the layer. There's still some residue of like the meat sauce and stuff. So, no, there's got to be a better pasta, but lasagna is not it. It's not it. Maybe like a burger with no condiments on it. I don't know. I have to think about this one. I need to spend some time -

[0:37:39] JG: That's a very dry burger.

[0:37:46] SP: Did you guys get that?

[0:37:47] JG: Yes. We could talk about food puns and analogies all day. But I want to take back one last technical topic before we start wrapping up, which is micro front-ends. These were all the rage about a year or two ago, and they've kind of dipped off in popular nomenclature a little bit. What do you interpret as the current state of what a micro front-end is, or the collection of what it could be?

[0:38:08] SP: Yes. We use micro front-ends a good bit here at work. So, the way that I would describe it is just front-ends that kind of operate on their own. You could think of them similarly. This is a bigger LEGO piece. So, you have Lego pieces that make up this front-end, but these front-ends can operate on their own. Then, the way that we use them on our team is we'll use them kind of like plugins. We have this common UI, and then we have different plugins. Maybe you could think of them as routes. And we have microservices that operate as these different routes for parts of the front-end.

So, there are a lot of considerations that you have to think of when you are the host of all of these different providers to your front-end, or these different partners that you have. I was actually having a meeting a couple of weeks ago with one of our providers, and they were talking about some of the issues that they have, and it just started me to think, because I'm kind of newish to this space, or the way that I'm thinking about it, I guess, is different from the way that I've ever had to think about things. 

But for example, one of our providers is like they can't have any downtime, because they are in the security space. So, if something goes wrong, the customers of their product need to go to their tool and see what's wrong. They need to be able to troubleshoot. Now, if that security team's tool is being plugged into our tool, and our tool is down, because of whatever it's caused everything to go down, the users have no access to that security tool. We, like our minimum requirements are also the sum of the minimum requirements of our partners, so we can have zero downtime now, because our partner can have zero downtime. We have to think about our testing strategy. We have to think about integration testing. How our tools working together. If we make one change to our tools, how does that impact our partners as well?

There are just a lot of considerations I didn't really think of, and it gets me back into that space where I was working on a component library and thinking about problems that I wasn't seeing individually like, okay, if you're building a button, that everybody at the company is going to use, you might have errors in your console as you're building it. You might have like these weird TypeScript errors, or you might have like, "Oh, this button, we didn't account for an on-click", like a race condition between two split buttons or whatever.

But when you're implementing that, teams and teams beyond, somebody's taking that button and they're implementing it on something else. They might encounter another issue, or you made a change to some padding thing that causes an error with whatever they're doing. Whatever it is, you have to think of problems that go beyond the scope of what you're building locally. So, you have to get in the mindset. You have to talk. Communication is a big aspect of it, when you're working with partners, anybody really. But you have to think of problems that expand beyond the scope of your own implementation.

[0:41:26] JG: And that can be a real downside, if you have a microservice that's dependent upon by let's say, many teams that say needs security level uptime, but also end-user facing level of reliability and performance and so on?

[0:41:38] SP: I wouldn't say it's a downside. It's more of just like a different kind of problem and it's part of the work. It's a way that you have to structure your work, your requirements, in the way that you architect your tool, so that you're benefiting your customers. Everybody has a customer, and so, these are one of our customers is like our providers, so you just have to think about things in a different way. But yes, I think it's an exciting challenge, trying to be optimistic. But yes, to me, it's exciting to get to think of things in a different way.

[0:42:15] JG: Well, that's a great note to wrap up the technical portion of this interview on. In our last couple of minutes together, I just want to free throw some rando personal questions at you. Is this something you're ready for?

[0:42:26] SP: Yes. Always ready for this. I'm living for this.

[0:42:30] JG: Shaundai, what is React Robbins?

[0:42:32] SP: Yes, React Robbins. So, React Robbins is a group dedicated to the personal and professional development of women and folks who identify as non-binary in the React and JavaScript space. So, it started out as a meetup out in New York. This was pre-COVID, and pre, me being involved in it. But it turned into an online meetup. We haven't met in a while. But we still, like the organizers and I still keep in touch and met a lot of amazing, amazing folks who have done demos, who have done presentations, and who have found mentors, and who I've had the opportunity to mentor within the group. So yes, if you want more information, you can find us on Twitter, React Robins, the logo is like a beautiful bluish-purple. But yes, I'll contact them. Get it restarted. But amazing group of people.

[0:43:29] JG: I love it. One last question for you. We actually went on a run together at a previous conference, and you mentioned you're doing some kind of interval training. Is that still going on? Or how's that going?

[0:43:39] SP: So, yes, I'm doing interval training, and I just run around my neighborhood for right now. But I will run for 5 minutes, and then take like 10 seconds. I just love to run. So, that's been it. I'm trying to incorporate a lot more strength training. Sad for my son, but I'm taking his playroom and I'm turning it into a gym because he doesn't use it. He uses his own bedroom. So, I'm taking it and turning it into a gym. I'm getting a treadmill, and I've got a bunch of weights, so that's going to be my space very soon. But yes, that's still a big part of my life.

[0:44:17] JG: I love the idea that in some number of years' time, your son will grow up to be a professional software developer and we'll listen to your old podcast episodes, and hear about you slowly taking his space and his toys away from him.

[0:44:27] SP: He's like, "I used to have a playroom. What happened?"

[0:44:31] JG: Well, this has been a blast and absolute pleasure. Is there anything else you'd like to tell us, tell the crowd, while we have you Shaundai?

[0:44:41] SP: Yes. So, if you're looking for me, you can find me on Twitter. That's the best place. I am lucky enough to have a very unique name that I can get - my first name is the handle for everything. So, just @shaundai. If you're ever looking for me, that's where, or just find me on Google or anything, Instagram, wherever. 

[0:45:03] JG: Awesome. Well, thanks so much for coming on. This has been a blast. Have a good one. 

[0:45:07] SP: Thank you.

[END]