Matt Pocock: 0:00 What's up, wizards? I'm here with Shaundai Person, an awesome TypeScript performance, Remix speaker. I've seen you talk about loads and loads of different things on the Internet.

0:12 I'm especially interested in picking your TypeScript brains and working out how TypeScript works at Netflix, which is where you work right now and where you've been for the last year or so, maybe more, I guess. Shaundai, why don't you introduce yourself to people at home?

Shaundai Person: 0:26 Thanks, Matt. My name is Shaundai Person. I'm a senior software engineer at Netflix. As you mentioned, I am also a conference speaker, a teacher. I work in the React, TypeScript space, all front end, also a bit of GraphQL.

0:43 In addition to that, I am an egghead instructor and a community organizer for a group called React Robins, which here in the United States is a group that is dedicated to the professional and personal development of women and folks who identify as non-binary in the React space, so yes, very [inaudible] .

Matt: 1:09 I'm super excited to talk to you today, especially about your experience working at Netflix, experience of how TypeScript works in a big organization, and also, I reckon you're probably one of the best people in the world to sell TypeScript, right? Because you come from a sales background. You're a second career dev like me as well.

Shaundai: 1:29 That's right. Yes, I am. My career, for the first 12 years or so, was strictly business entrepreneurship and sales. I use those sales skills to get into this engineering world. I'm using them to advocate for TypeScript across the nation. Across the world.

1:51 [laughter]

Matt: 1:52 Nice. A one-woman army advocating...

Shaundai: 1:55 That's right.

1:56 [crosstalk]

Matt: 1:56 Nice. Rock and roll. What's your history of TypeScript, then? How did you get into it, and what were your initial impressions of it?

Shaundai: 2:03 I'm a self-taught engineer. JavaScript was the first language that I learned. I wanted to learn to do web development. It was an extension of what I was doing in business.

2:19 I had a side business that I was using my sales skills to sell natural and organic products, and I wanted to build an app for myself and I wanted to build a website or customize my Shopify site.

2:35 I learned JavaScript and loved it so much that I decided to turn it into a career. When I got my first engineering job, my team, shortly after I started, decided to start a migration of our codebase from Angular 1.6 to TypeScript and React. This was a big initiative, and it was scary to me and I was not excited about it.

3:11 I really love JavaScript. I call it the YOLO language, the you-only-live-once language, because you can just do whatever you want. It's very free and dynamically typed, and you don't have to worry about what happens with functions after you write them. It's just the code will either work or not work, and I love that.

3:33 TypeScript seemed very strict. Now there's rules, and I'm not that great with rules all the time. I wasn't excited about it, but if I was going to have a future at this company and in the engineering world, I knew that everybody was moving toward TypeScript, so I had to learn it. That was my initial introduction to TypeScript...

3:59 [crosstalk]

Matt: 4:01 That was part of a migration from Angular to React and JavaScript to TypeScript. Which of those freaked you out more? Which was the scarier one?

Shaundai: 4:10 That's a great question. I would say the move from Angular to React, because I didn't know any Angular. TypeScript sounded scary. The migration sounded scary, but, as you know, TypeScript is JavaScript, so a lot of it looked very familiar. With Angular, I had to learn about MVC, model view...I may be even getting that wrong now.

4:36 I had to learn about that stuff. TypeScript was, pleasantly surprisingly, an extension of the stuff that I already knew and was already familiar with. It made it a much smoother transition.

Matt: 4:49 Why don't we talk about your role at Netflix at the moment? You've got a really interesting role, I think. You're not necessarily building outward-facing stuff for Netflix. You're mostly building stuff for other developers. Is that right?

Shaundai: 5:01 That's right. The other engineers at Netflix are my customers. The team that I'm part of is called the Productivity UI team. It was described to me...Am I allowed to swear in this?

Matt: 5:14 Yeah, you're allowed. Go for it.

Shaundai: 5:18 It was described to me as the colonoscopy org in my interview because what we do is the stuff that you have to get done, but you don't really want to do, and it's gross. We'll diagnose you, we'll get all the shit out, and then we'll send you on your way. We're just very stealthily getting in there, getting all the shit, and then just [laughs] moving on.

5:44 Mainly what we do, my analogy is more of like if you think about Dependabot for GitHub, it alerts you of different dependency issues that you have, things that might be outdated, libraries that you're using, or vulnerabilities that you have in your code. We build tools that allow you to scan the repos at Netflix, and we have thousands, probably tens of thousands of repos at Netflix.

6:12 We'll do these covert operations. We'll build these tools that allow people to migrate away from something, migrate towards something, or identify vulnerabilities in their code and exactly where they are and help them to find the steps necessary to resolve whatever those issues are.

Matt: 6:30 Wow. You're constantly then driving a cycle of migration at Netflix. You're working with legacy code all the time then?

Shaundai: 6:41 Yeah. In a lot of cases, it is. Netflix was founded in the '90s, 1990s. [laughs] I don't know why I had to...

Matt: 6:52 1890s, damn.

Shaundai: 6:53 Yeah, people were streaming back [inaudible] .

6:55 [laughter]

Shaundai: 7:02 In the 1990s, that's when Netflix was founded. We have a lot of older code bases and then we also have newer projects. The stuff that I'm working on is new. We've opened up new repos.

7:18 We could be working with very old code bases from 20 years ago, 30 years ago, to very recent stuff. We have to build tools that can operate across different languages, different styles of coding, and those types of things.

Matt: 7:41 Wow. That's amazing.

Shaundai: 7:42 TypeScript has helped us a lot with that.

Matt: 7:44 Tell me more about that then? What does TypeScript adoption look like at Netflix?

Shaundai: 7:51 It probably depends on who you ask. Again, we have thousands and thousands of repos at Netflix. Not every front end is using TypeScript. There are still some teams that are in the process of migrating to TypeScript, and there are some teams that have already very heavily adopted TypeScript, like my team.

8:13 When you're on a team that is working with tools that need to be able to integrate with a number of other repos or connect to different things or our component library, for example.

8:29 For those who don't know, a component library is a library of components, like buttons, dropdowns, inputs, things that already have the Netflix styling that you can just pull into your front end and add in this is the variant that I want to use, and then have that already be operational and beautiful and go with the existing approved styling that Netflix has.

8:57 If you have things like that that are working alongside other repos or being imported into other repos, you really want that Type safety. It will help you to, one, understand the code a lot better, which is great for somebody who's onboarding as a new employee or a new team member or somebody who is just like, "I'm just going to fix this quick bug" because we have the flexibility to do that.

"9:25 I'm just going to fix a quick bug in another repo and then come back to the stuff that I was doing." That helps you to get a quicker understanding of what's going on.

9:34 Then it also helps you to introduce fewer errors because you get that real-time feedback from TypeScript that, as TypeScript, "This is what I'm expecting you to bring in, or you think that you can do this or I know that this is what you want to do, but this is not allowed." It helps you to eliminate those issues before that goes into production.

10:01 At a huge enterprise company, having that additional check before you've merged your code is critical. It's critical for being able to scale your codebase as you not only hire more engineers, but also as you continue to grow, add features.

10:25 It's critical for that. Then also, as you want to maintain it and make sure that code is error-free, refactoring is a big thing. Like I said, we have code from the '90s. There's a lot of stuff that we have to deprecate away from.

10:44 In order to maintain that and have it still work the same way or even better, TypeScript gives us the ability to understand this is what the code is supposed to do, and if you do it this way, you'll be pretty error-free.

Matt: 11:01 Pretty error-free, yeah. It will help you a little. That's so interesting. The structure is...It sounds like you have lots and lots of different teams, and those teams all have a degree of autonomy. They can choose their own tools, but then you've also got these shared packages.

11:19 One team might make a package that another team depends on, and then it sounds like TypeScript is the glue that holds them together.

Shaundai: 11:28 You got it, pretty much. Yes, at Netflix, there is this concept of freedom and responsibility. We have this culture memo. If anybody is interested in learning more about working at Netflix or anything like that, just look up Netflix culture memo. It talks about Netflix's culture.

11:49 Pretty much the pillar of Netflix's culture is this concept of freedom and responsibility. Mainly, it's if you see trash on the floor, pick it up, metaphorically speaking. Also, you have the freedom to decide what you want to do, but you have the responsibility to act in the best interest of the company.

12:09 You can decide what languages you want to use, but you're going to make the decision that's best for the company. Again, just reiterating, the benefits of TypeScript is that maintainability, that scalability, keeping your code less error-prone and making it a lot easier for people to onboard and understand what the code does. That's why people choose to use TypeScript.

12:35 [crosstalk]

Shaundai: 12:37 Making it easy to work with other people. TypeScript has helped a lot with that.

Matt: 12:41 I bet. That's fascinating. There's a huge amount of autonomy, but it sounds like the culture has changed a bit so that people are choosing to use TypeScript. You're not mandating it from the top down. It's just some of the teams are more likely to pick it up than others. Are there still teams that are resisting a little bit, or has the culture mostly shifted?

Shaundai: 13:02 In general, and I can't speak for everybody, but I could say that all of the front-end engineers that I've interacted with in my time there have been very pro-TypeScript. I did speak last year with a woman who was responsible for migrating a team away from JavaScript to TypeScript at the org.

13:34 With engineers, with anybody, when you're used to doing things a certain way, just like I was with JavaScript, it's hard to get change to happen. That's where the sales skills come in, and all that good stuff. She decided that it was a good thing for the org, and she needed to get the other engineers to see it.

13:59 A lot of them had concerns, which were valid concerns. You want this to happen, but technically at this point it's tech debt, when you have to migrate from one thing to another thing. I have all these deadlines. I have all these priorities and, at Netflix, we have to stay ahead of the curve. Like, "Let's just keep going and going and going."

14:22 This is going to slow me down, and then not only is it going to slow me down while I do this migration, but I don't know how to use TypeScript. It's going to slow me down as I'm trying to add in additional features, so why should I do it? That's when you need to really push on those benefits.

14:40 If you're at an enterprise organization, I would say an organization of any size, but especially at an organization at this size, with so many different repos, so many different people working together, and all the constant changes of engineers switching teams or new engineers being onboarded...

15:00 You need to have some system of making sure that your code is readable and maintainable and scalable and it stays sturdy for the long run. I think overall, here, we, in general, have accepted that this is the best way to do all those things.

Matt: 15:25 Let's say it sounds like a cultural thing most of all. You're trying to change the culture of a company from...How would you describe the two separate cultures that exist?

15:41 There's the JavaScript YOLO culture and the TypeScript "I like things yelling at me" culture, I don't know. How would you describe that difference and the mindset shift there?

Shaundai: 15:54 I don't want to say anything insulting, but this was me back in the day, before TypeScript world. It's more...I'm not going to say the word. I'll say it, childish. Not childish, that's not what I mean.

Matt: 16:17 I'd say the word that comes to mind is "move fast and break things," right?

Shaundai: 16:21 Yes. That's great.

Matt: 16:22 It's the boof.

Shaundai: 16:23 Like the YOLO. It's fun. Like, "Let's do it. Let's code and let's see what happens. We're innovating, we're moving fast." It's great. I love JavaScript for that. I love the flexibility. I love the freedom to be able to just dynamically type and do whatever you want, but the shift, once you start using TypeScript, there's no going back.

16:52 Once you start it, it's like, "Oh, I've seen the light." I can still have this YOLO "move fast and break things." As I'm learning, it's going to slow me down, of course, as you're learning something new, but again, TypeScript is JavaScript.

17:08 You'll recognize a lot of the stuff. All of the patterns, the functions, all the same logic that you're used to creating, that's all there. Now, you're just adding another layer of safety to it.

17:24 Then once you start to pick things up, it moves so much faster, and it starts to get fun. You get that same fun "move fast, break things" aspect that you get with regular JavaScript with TypeScript as well, but then you also get the safety of it too.

Matt: 17:42 It feels like you got some guardrails next to you. At least you got something to hold on to while you're moving fast and breaking things. One arm's breaking things, one arm's holding the...I don't know, doesn't quite work as a metaphor.

Shaundai: 17:53 Like you're doing an extreme sport, but you have health insurance at the same time.

17:57 [laughter]

Shaundai: 17:57 It's like roam free. [laughs]

Matt: 17:58 Exactly. Then how do you get people to...Because you're right. When people get it, then they don't go back, right?

Shaundai: 18:10 Yeah.

Matt: 18:11 I imagine at Netflix, you haven't seen teams going back from TypeScript to JavaScript.

Shaundai: 18:15 Never.

Matt: 18:16 Never?

Shaundai: 18:18 No. It's a hard sell. You have to acknowledge that there are real truths. All of the concerns about, "Yes, it's going to slow me down" or, "No. I have these other deadlines. How can I fit this in? How could I possibly prioritize this?" those are totally valid and totally true.

18:38 When you're selling TypeScript internally to an organization, you have to, one, acknowledge that, yes, your concerns are valid, but in order for us to move forward, we might need to take a step back or slow things down a little bit so that we can move so much faster after that.

19:03 A lot of these conversations too, will have to involve leadership or somebody that takes a leadership role because when you're talking about tech debt, it's like, "How do I balance this amongst my other priorities?"

19:20 If you have your manager telling you, "This is what's important to our organization," it has nothing to do with migrating TypeScript. Then it's like, "All right, what can we do? This is my job. This is what I'm getting paid to do."

19:34 Selling leadership on the vision, like, "As you want to hire more people, as you want to onboard people, as you have people who move up into leadership positions on a team, you need to put these checks in place because it's going to..."

19:52 It's not just like "unfund the police" type of thing. This is what's going to keep the code sturdy as you have all of these different moving parts within the organization. Or the organization is going like this, and we don't want the customers to see all kinds of shaky, unstable code.

20:12 This is one way that we're going to keep our code very steady and grounded so we can grow quickly, we can scale quickly, but this is something that we're going to have to do first. This is what we're going to have to set up as a foundation in order to get to that next level.

20:29 I would talk to leadership, get them on board with the benefits. If you have an issue with leadership, see if you can rally an ally, as a peer at your same level, and just start to talk about...Read case studies. Airbnb has a really good case study about migrating to TypeScript.

20:49 A ton of organizations have done it. It's been successful. It's proven everywhere that this is the way that companies are going to go for the long term. Bring in the facts. Bring in voices from other people who have done it. Check out Matt's Total TypeScript course. [inaudible] .

Matt Pocock: 21:14 We're in Total TypeScript. This is Total TypeScript right now. We're here.

Shaundai: 21:17 We're there. We're here.

Matt: 21:18 It's fascinating. I think one of the ways that you might use Total TypeScript is to get yourself really good at TypeScript so that you can convince your team and be that one to solve problems as they come up. It sounds like you've been through a couple of painful JavaScript-to-TypeScript migrations yourself.

21:45 When you were on those migrations, what role did the team dynamic play in the migrations? Was there someone who was really, really good at TypeScript who was helping you out, or were you all learning together? How did that work?

Shaundai: 21:57 Yeah, that was actually how it was. When I got my first introduction to TypeScript at my last company, called SalesLoft, there was one person, who's like a mentor to me now, one person who had seen TypeScript and played with it and was like, "Oh my goodness, we need this." He was a really strong advocate for it.

22:22 He talked with the leadership about it and talked about the benefits. Then he actually led trainings within the organization where he had just all the engineers in a room. Then they recorded it as well. He just went through. It was two or three lessons of just the basics.

22:40 What I loved about that was I could see how...First, he started with the benefits, which I would say is one big thing. If you're trying to sell anything to anybody, understand first what their objections are, where they're coming from, whatever their concerns are.

22:58 Then relate to those, address those, in a very sincere way, but then talk about the benefits that it's going to bring and the picture-perfect world that it will be in the long term.

23:12 Then he talked about Typescript. It was just maybe a half an hour, 45 minutes, each session, and it was so simple. It was like all you need to know right now is primitive types like you recognize this is a number. This is a string. This is all the stuff you already know. You're just calling it out, or Typescript might infer things for you.

23:35 This is where we were going to prefer type inference in this case. Just seeing that it's not a whole thing that I have to learn. I'm not learning PHP. I'm not learning Java. I'm learning an additional level of JavaScript and it's really not that far off from the stuff that I'm already doing every day.

23:56 Seeing that, and then just hearing the excitement in his voice, and all the future and how beautiful life is going to be after we adopt it, was what started to sell me on it. Then, after we started to implement it, he was available to answer questions. I could just slack him and be like, "Why am I getting this error?" Because that's the hard part.

24:21 Once you start, then it's error after error after error, and you're like, "Oh my God. What is it even saying?" The error messages are not great. A big part of it is understanding what the errors mean. Just getting over that initial learning curve was tough, but it was helpful to have somebody who was really experienced in it helping us go through it.

24:51 Everybody else was learning it all at the same time. We could ping each other and just be like, "Oh, I came across this error. Have you ever seen this before?" Then we could swap ideas.

Matt: 25:04 This was Angular app going to the React app, right?

Shaundai: 25:07 This was, yeah.

Matt: 25:08 Do you remember anything that was particularly challenging about that migration? Was there anything in particular, like how long did it take as well? What was the flow of the whole thing and what was tough about it?

Shaundai: 25:20 Actually, it's funny because I was just talking about this the other day with the person that I was saying was scared in the migration. I was like, "If you could go back and change anything, would you change anything?" He was like, "No because there was lessons learned."

25:37 Now, if we had to do a similar migration today, there would be things that we did differently, but we had to go through all of the stuff that we went through in order to really learn our lesson. Some things I can call out for anybody who is going to do a migration is put a plan in place before you do it.

26:00 The first aspect is convincing the team that this is worth it to switch, but then put a plan in place for how the migration is going to happen. When you have code that's already in production, one, you still need to continue to deliver on features and then you need to figure out how to address this tech debt at the same time.

26:21 How are you going to prioritize new features compared to tech debt? Then just logistically, how is this migration going to happen? Are you going to just migrate everything, or just change everything from JSX to TSX files? Which is what I did. When I started out, I was like, "I'm just going to blow this thing up and change all the Js to Ts." [laughs] It was just errors after errors.

26:49 I wouldn't recommend it unless [laughs] you already know Typescript. There was two opposing things that I was balancing is, one, I'm learning Typescript for the first time, and then two, I'm learning how to do a migration. Those are two big skills that it's hard to do at the same time.

27:09 I started out by migrating from the root and just switching everything from JavaScript files to Typescript files. Just changing the name, JSX to TSX, and then I was overwhelmed with all the errors.

27:25 It was all kinds of flavors and combinations of errors from this library, you have to import the types from Lodash, or Lodash doesn't even have a type library that they export to this is just like an error that nobody has ever caught out of the 10 years that this company has existed.

27:50 This is a valid error that isn't caught, which is beautiful that Typescript does that, but it's very overwhelming when you have so much stuff going on. I went back, changed everything back to JavaScript, [laughs] and I went around and then I changed all of the leaves of the tree, so all the files that have the least dependencies, started changing that little by little. That works for me because I was...

Matt: 28:15 By the way, by leaves, you mean like if you think of a dependency graph of all of the things in your project, then it's the things which have the least dependencies. That is what you mean.

Shaundai: 28:23 Exactly, yes. If you think the app as the root or the whatever file you're exporting the uppermost parent, it might be index or app.js, that's the root. Then your files will branch out, branch out, branch out as they get exported.

28:39 The ones that have the least amount of exports is what I started with because, for me, it was a safer, more friendly way to learn Typescript while also participating in the migration.

28:55 I would say make that part of your plan. Understand everyone's level of understanding with Typescript, where they're at, and then divide the work out appropriately. If you are a person that's going to be a participant in that migration, break your work into digestible chunks.

29:17 That will vary based on your level of experience. If you are brand-new like I was at Typescript, I would suggest doing as leafy as possible, as the outermost as you can. If you have some familiarity with Typescript and you know your way around error messages, you might want to start from a different place.

29:37 Those are some things that you need to make sure that you take into consideration if you are doing a migration.

Matt: 29:43 I've definitely been down that path. I was working on React Native app solo. I was being paid. I was at a company and stuff, but I was the only one on this thing. I just transferred all the files over from JavaScript to Typescript and had 6,000 errors or something because I was on my own.

30:02 I worked through the errors, worked through the errors, worked through the errors. My CI was red for four weeks or something. Finally, got green at the end. While I was doing that, I was still trying to ship features as well. You touched on that before. It's important to stay shipping while you're doing this, but how do I do that when I've also have all of this tech debt I need to get rid of.

Shaundai: 30:31 Right. You just made me think of a whole other point is when we talk about breaking things up, if you're at an organization where you're working with other people, like your app, it sounds like you were working on by yourself.

30:46 Say, you're working with one other person, two other people, or 50 other people, remember that they might be delivering on features as well from a related file or the same files that you're working on. You want to make sure that you're communicating with other people about how you're breaking this up because let's say I have like my chunk A that I'm responsible for.

31:11 I introduce that into prod, but maybe I missed a type or I got something wrong. By me, adding in this file or adding in a file that creates Typescript errors in another file, or merging something that creates errors in another file, I'm messing somebody else up or I'm causing merge conflicts and stuff like that.

31:32 You need to make sure that you're in constant communication. I do remember that being an area of caution for you if you are migrating. That was one of the challenges that we had was how to break things up so that they don't interfere with anyone.

Matt: 31:52 For sure. I've talked to Mark Erickson for this as well, who described his strategy for migrations was the opposite to yours. I'm also talking to Priscilla from Century. She's my calling about 20 minutes or so, who went through it. They migrated Century to Typescript and which is enormous challenge.

32:14 They recommended I guess if you have the skills to do it going from the root outwards or at least going from the utilities folder outwards, like the things that are pulled into and have lots and lots of different dependencies.

32:29 I guess then what you're saying is if you don't feel confident or there's room for people doing the work on the leaves and there's room for people doing the work on the root. Does that sound right as an idea?

Shaundai: 32:41 Yeah. It really depends on your level of skills. If you're working with a massive repo, just break it up into ways that make sense. That might be the way that makes sense for them. It's going to be unique to every organization.

33:00 I could see the benefits of doing something like that. As long as it's not causing issues for other parts of the repo or the other teams that are working on it, it's great. There are multiple ways to eat the same elephant.

Matt: 33:18 I haven't heard that one. We would say skin the same cat. That was brutal. A lot of animal cruelty in that metaphor.

33:28 [laughter]

Matt: 33:32 Interesting. There are a couple of other ways you could potentially do migrations as well. It sounds like we're both in the same camp of you shouldn't just whack everything over to .tsx. You should change it file by file because Typescript lets you do that as well. You can import JavaScript files and Typescript files and it works fine.

33:54 Another potential way to do it would be to let say, change everything over to Typescript and then just stick NEs everywhere. You can automate this somewhat with a TS-migrate, which Airbnb made, or change everything over to Typescript files and then ramp down the strictness as well, so you get strict. What's your feeling about that as opposed to doing it file by file?

Shaundai: 34:24 This is just a personal opinion because those are also valid ways to do it. I'm just a very detail-oriented person. Having the NEs first would stress me out because I'd be like, "What if I miss one," or I feel like I'd be doing duplicate work.

34:50 I would have to change everything, add in all these NEs, and then still go back and do all the work of dividing up everything and then changing the types to valid types.

35:03 Also, using NE introduces a level of temptation because [laughs] I could have the whole thing NE, then I could change 95 percent of it to valid types, and then I try to change one last NE to this is should be a Boolean or an imported type. All of a sudden, I get errors everywhere and I'm like, "You know what. This is going to stay an NE," and just walk away from it.

35:33 [laughter]

Shaundai: 35:36 This is just me. I don't even want to introduce that level of temptation for myself.

Matt: 35:42 That is a potential step in a migration. You come across a file. You kind of need to get the types done because someone else is depending on that file being done, or there's some feature work that needs that utility folder done. You must be tempted to stick an any on there. You don't want to have to figure out the generic signature and all that kind of crazy shit.

Shaundai: 36:03 I've been guilty. Very recently, I was just sitting there looking at something. I took some code from another part of a repo. I duplicated it and just made a couple of changes. Then, all of a sudden, it was red everywhere. I changed one thing to any, and I was like, "Oh."

36:21 [laughter]

Shaundai: 36:21 I'm like, "Should I leave it?" [laughs]

Matt: 36:31 [inaudible] .

Shaundai: 36:31 Yes. Going back to the Netflix freedom and responsibility philosophy, I was like, "You know what, Shaundai? You're better than this. You're better than these," and so I did the noble thing, [laughs] be responsible.

Matt: 36:45 Let's go back to, I think, a couple more questions before we finish. When you're thinking about trying to convince your company to take on TypeScript, how important do you think knowing the advanced stuff of TypeScript is?

37:01 How important do you feel that understanding generics are, understanding the really complex end of things? Also, what things do you feel like you would need to know in order to be the wizard on your team leading that migration?

Shaundai: 37:15 That's a great question. We use generics a lot at Netflix. I will say that. Generics, in my mind, were one of the toughest things to learn in TypeScript.

37:34 In order to be dangerous, I don't think you need to know much. I think you need to know how to type parameters of a function, the output of a function, variables, make interfaces, make types. Then the rest of the stuff, you can start to pick up.

37:55 That's actually how I did it, was I learned the very basics of it, got a bunch of errors, and then asked questions as I went. Then, when it came to the generics, it was very much learning on the job and continuing to practice, get errors, use Stack Overflow, and get better at it.

38:20 If you don't know everything...This is with any language, any aspect of engineering, pretty much anything in life. You don't have to know everything to start. Just go ahead. Start with the smallest, little, micro piece of knowledge.

38:37 Just start with the knowledge that TypeScript is going to benefit you, benefit your organization. Go from there. Learn little by little by little. Just continue to learn. I'm still, to this day, coming across errors that I'm like, "Shaundai, you should know this," but I don't. Or the same things will trip me up. Keyof typeof, that trips me up every single time.

Matt: 39:01 Typeof keyof. Keyof typeof. Yeah.

Shaundai: 39:07 Every time. I would say you don't have to know everything. Don't feel overwhelmed by it. You can absolutely just start small. That's a totally valid thing, at an enterprise organization as well.

Matt: 39:22 You said something that just really tripped my curiosity, which is Netflix is using generics and uses that stuff, uses the more advanced end. What kind of stuff are they using it for? I've never worked at a FAANG. You know what I mean? I want to know if this cool stuff is happening in FAANG, that I'm not involved in. I've got a bit of FAANG FOMO.

Shaundai: 39:44 We use a ton of generics. I see it the most in state, like useState. We use React with the hooks. We use useState. We have a program that automatically will build types. It's this whole advanced system.

40:07 We have this enterprise graph of data. We use GraphQL. We have data from all different parts of the org. At least in the repo that I work in, we have this tool that will automatically create types from this big enterprise graph.

40:31 If I make a query in GraphQL, I just run a script to start up my local environment. Then it will generate types from that query. Then I can go over to this...I forget what the file is called, like model.graphql or something like that. I can go over there and get my types for different things.

40:54 As I'm doing useState or I'm writing out queries -- we use Apollo for running queries and things like that -- we'll use generics for what we're expecting back from that query, or from the state that we're going to set when the query is run, or lists of things.

41:19 We'll use generics to say we're going to have a big table, and these are the types of data that would fit into this column, and then this column, and this column. Generics are used all over the place. There's types that come from Apollo itself. There's types that we import from other libraries that we use.

41:51 It's very generic heavy. This was my first big experience using generics at such a large scale. [laughs] You'll see a lot of that.

Matt: 42:01 Sure. That's so cool. I wish we had more time so we'd get into that. That sounds like you're generating types from GraphQL and then manipulating those, sticking them around in all sorts of places. TypeScript eats that stuff for breakfast. That's the stuff.

42:21 Let's finish there. Thank you so much for coming along. This was so much fun to talk to you and hear all about how TypeScript works at a big organization and how to sell your company on TypeScript. Where can people find you online?

Shaundai: 42:35 I have a unique name. If you're looking for me anywhere, you can find me just @shaundai. On Twitter pretty much -- I'll spell it out, S-H-A-U-N-D-A-I -- @shaundai, Instagram @shaundai, Polywork @shaundai. LinkedIn, just look up Shaundai. [laughs] You'll find me anywhere.

Matt: 42:54 Nice. We'll put some links below as well. Thanks so much for joining along and see you soon. Bye.

Shaundai: 43:01 Bye.