00:00:01 Speaker 0: Hello, everybody. I'm super excited to be joined by Nevi. And actually, I didn't ask how to pronounce your last name. Is it Shaw?

00:00:07 Speaker 1: It's Shaw.

00:00:08 Speaker 0: Okay, great. Nevi Shaw. Nevi and I met at RemixConf this last year. She proposed to speak alongside Igor Minar of the AngularJS team fame. He's now over with Nevi at CloudFlare. And yeah, so they spoke together at RemixConf this year. It was awesome

00:00:28 to have them speak. Cloudflare is among the companies that is pushing the edge like further than anybody else that I know. Cloudflare is just awesome. So, and it was just so wonderful to get to know Nevi at that conference and I'd like you all to get to know Nevi. So could you give us a little intro to yourself?

00:00:46 Speaker 1: Sure. Hey everybody, I'm Nevi. I am, like Ken said, a product manager at Cloudflare. I joined about 2 years ago and totally fell in love with the web development space as much as I hope you are all doing as you're learning and going through this course. But yeah, super excited to talk a little bit about product management and web development.

00:01:06 So yeah, excited to get into

00:01:07 Speaker 0: it. Awesome, yeah, that is great. So to get us going, I wanted to get to know your history and how you got into web development. I actually don't think that I know. So I'm very curious. How did you get into web?

00:01:25 Speaker 1: Yeah, so I had a really interesting path here. I started off, I studied computer science business, had this like really integrated degree in college, knew I really loved tech, but also wanted the business side of it, which I feel like is a cliche. I feel like everyone says that. I truly like wanted kind of this mix. Like I loved

00:01:45 kind of getting my hands dirty. I loved hands on keyboard work. But also really like people. I love speaking. I love making new friends. I love building relationships. And so I started interning a lot in the product management space. Didn't know what industry I wanted to go into. I started when I graduated in consulting, thinking like, hey, that's going to give

00:02:05 me a nice kind of understanding of different industries that I could go into. But then I was like, no, you know what? I really want to pick an industry. And this role at CloudFlare kind of fell in my lap. I had a friend that reached out and said, Hey, we're hiring. Do you want to give it a try? And when I've heard about CloudFlare, I think everyone kind of thinks

00:02:25 of security and performance. And no 1 really thinks about the developer platform. So when I saw the product, I was like, okay, this is interesting, except I've never had a product where I build for users that are developers. I always work with developers like next to me. So it was a super interesting concept. But yeah, I interviewed

00:02:45 for this job and they, I was like, Hey, I don't really have a lot of experience in web development, but I really love the company and I love the mission and I want to join. So in April, like 2 years after I did consulting for 2 years and then I joined Cloudflare and they have basically been really growing their developer platform. So

00:03:05 I started off PMing for a product called Pages, which I'm actually still the PM for. Cloudflare Pages is our build and deployment platform for full-stack applications. It's so funny, I look back to some of the days where I was first starting off and I had no idea what I was doing, like seriously had no idea what I was doing. I would get

00:03:25 like feature requests and customer escalations and things that would just come across my plate. And I would be like, I don't even know what this means. Luckily, I had really great friends on my team. I had a lot of really great work resources. I had a really great mentor, a really great boss, Rita Krasov, and she held my hand through it all and was basically like, this is the world of web development.

00:03:47 And that's kind of how I got here. And now I feel like I can hold really great conversations. Speaking at RemixConf was like a super huge career milestone for me. And I remember sitting in the conference and I was like, wow, like 2 years ago, I would have no idea what everyone was saying. And it was like such a point of pride for me

00:04:07 to be able to sit there and listen to these conversations happening. But yeah, I totally fell in love, so much so that I love to listen to what they've podcast. I love to hack on my own. I love to go to meetups. I just feel like it is such a community full of character. You can

00:04:27 meet so many different types of people. They're building so many cool things. And it's a space I'm just super excited about.

00:04:34 Speaker 0: Very cool. So you graduated with a CS degree. So obviously you're coding before you got into product management. And now you're still coding as a product manager. That actually seems pretty unique from my perspective for product managers. Like in the product manager circle, are you pretty unique that you're actually still coding?

00:04:55 Speaker 1: No. In fact, like I would not even call myself that great of a like developer. I think there are definitely PMs on my team that are phenomenal. And I'm always in awe of them. When I studied in school, I was more on the data science route. So like I had classes in JavaScript and

00:05:15 Java and like did a couple of web development courses, but it was not my bread and butter. You can give me a Python assignment, you can have me do a bunch of data querying, that's all my stuff. I actually also got a master's in data science. But web development is totally new for me. So it's actually, I feel like I'm

00:05:35 like learning it all over again. So I definitely feel like it helps me understand things a little bit better, but I think it's actually an advantage to not be who I'm building for. I think that is actually unique for me to come into a project and say,

00:05:55 okay, I know nothing about the user. And that actually forces me to do my job better and to actually like go to users and not have a bias or not have an opinion on what this feature should be or what the product should be. In fact, my user doesn't inform me. So it definitely helps me to process information, but it's good that I'm not immediately jumping to solutioning

00:06:15 and instead forcing myself to go to customers and go to the user so I build the right thing.

00:06:22 Speaker 0: Yeah, that is probably 1 of the most important aspects of the PM, right, is being able to translate the user's needs into what the developers are building, I guess.

00:06:33 Speaker 1: Yeah, exactly.

00:06:36 Speaker 0: So in the workshops, we have this, we have these little emojis that signify what the user or the developer who's going through the exercises supposed to do. 1 of them is Cody the koala that's I've got here. Koala is all over my stuff. Cody is the primary 1 telling people

00:06:56 what to do in the exercises. And then we have Kelly the coworker, that's the elf emoji. And we've got, and she does like a ton of work for them as they're going through the workshops. And we've got Hannah the hundred and Chuck the muscle. I can't remember, like there are a bunch of others, but 1 of them is, is Peter, the product manager.

00:07:16 And yeah, so you are represented as a product manager in the workshops. And Peter's job is to let people know the use cases that they're trying to solve as they're going through the exercises. So it's like use case driven rather than just like write this code for who knows why. So

00:07:36 what are the types of things in, I guess I tried to do my best to represent a product manager as I was, you know, cause I am the 1 who's writing what the PM is saying, but what would you say are the types of conversations that you typically have with developers as part of your job as a PM?

00:07:56 Speaker 1: Yeah, I mean, I think it really depends, right? As a PM of a product that is used by so many different types of developers, I think my conversation is definitely different based on whom I'm speaking to. I'll give you an example. I think like our users are kind of segmented in different classifications. So you have kind of like independent

00:08:16 developers who are sort of dipping their toes into development or are working on personal projects. We also have framework authors, which we work a lot with. We also have, Enterprise developers who are working for like large scale companies. And so every time I talk to a user, my first question will always be like, tell me a little bit about yourself. I like to understand

00:08:36 their experience level. I like to understand their familiarity with products or their familiarity with, yeah, different features on the product. And then my next question is always, what are you trying to build? I think the most important thing to understand is where does this developer want to go? And sometimes they don't even know where they want to

00:08:56 go, or they tell you a very like short-sighted vision. And I already can think like, they're going to need this later. And this is where the application is going to go. So a lot of my conversations, I like to have like very personal relationships with my users. I do like to kind of get to know them and characterize them. I write a lot of personas in the product requirements documents that I write. So I do like to get to know

00:09:16 them. And then it's really kind of like, yeah, use case driven. So like, what are you building? How big is your team? How many hours are you developing in a day? Or what does your stack look like? What does your setup look like? What does communication and collaboration look like on your team? So I guess those are really specific to the product that I'm building right now. But

00:09:37 it almost feels like an interview, kind of like what you're asking me. Every time I talk to you about a news case, it's almost like I want to get inside your head. I want to know exactly what you're thinking so I can think 10 steps ahead of you. So it almost feels like, yeah, it feels like an interview almost, but almost like you're at a coffee shop and you're just trying to like chat with a friend and figure out and

00:09:57 like help them achieve their goals.

00:09:59 Speaker 0: It sounds like you have to be very, what's the opposite of self-centered, other-centered, I guess?

00:10:05 Speaker 1: Like you

00:10:05 Speaker 0: just, when you have these conversations, you're just very interested in them and their goals and their desires and getting to know them.

00:10:13 Speaker 1: Exactly. It's also almost like a therapy session sometimes because you actually can't impart any, like especially if I'm doing user research or if I'm just having an intro call. I never want to impart my own opinions yet. I'm always trying to, especially if I'm putting designs in front of them, or if I want to get feedback

00:10:33 on a certain feature, I'm trying to get the requirements. I can't egg them in a certain way. I just want to understand in the state that this user is in right now, how can I help them or how can I build this feature to get them to where they want to go? So yeah, it kind of feels like therapy sometimes.

00:10:48 Speaker 0: Yeah, yeah. I guess you have to be very careful to not poison the conversation, right? So that they really think about all the things and problems that they're having and everything. That's interesting. If anybody watching this conversation was previously a therapist, you might consider going into product management.

00:11:06 Speaker 1: It's honestly the same. You think about, it's funny also working in different areas of product. Like when I was in consulting and I worked in product, when I was an intern, I was working in product. The backgrounds that come into this role are so vastly unique. Like you do see people, you see a lot of folks now actually coming from computer science and going into product,

00:11:27 but you also see people who are psychology majors and you see people who are graphic design majors because product wears so many different hats from like, yeah, the mock-ups and the designs, but also it is very psychological. Like you really have to kind of interpret and understand your user. So you do see a lot of psychology majors, you see a lot of fine

00:11:47 arts, you see a lot of math, like anything I feel like can go into product management. You just have to have kind of that empathy for your user. So if you're an empathetic person, even if you're not a therapist, but you're an empathetic person, product might be for you.

00:12:01 Speaker 0: Yeah, very cool. So that's how you gather requirements, talking to your users, getting very empathetic with them. And then you got to translate that into some requirements for developers. And I think some of the people who are going through the workshop may work at like a large enterprise, they have a product manager that does this for them, or they work at

00:12:21 a really small company, and maybe they're a startup, and so they don't have a product manager, they are the product manager. And so I think that this could be really helpful for both of these people to think about, okay, so how should I be talking with my product manager as I'm hearing their conversion process from requirements to like actual, like what am I supposed

00:12:42 to do? And then also for the solo developer who's trying to convert user requirements into like actual code. So what are the conversations like, or what is your process for turning user feedback into actionable code changes?

00:12:58 Speaker 1: Totally. I think I'm gonna take, so I think there's 2 kinds of conversations I would have with the user to then turn into a code change. So 1 is more like vision. So like if I don't know what my roadmap is going to be, or if I don't know what I'm developing next, I might have a more like broad conversation with the user, but I'm going to focus on, I know what I'm trying to build. I just need to figure out requirements around it.

00:13:19 So essentially what I do is I have all these, this massive list of interviews. So let's say, and actually I like to do this thing where I like post my calendar, kind of like what you did and kind of see who bites. Like I'll post it on Twitter, I'll post it on Discord and kind of say like, hey, I'm looking for user feedback, like come sign up with me. I'll gather all of them.

00:13:38 Speaker 0: So just wherever you're, for you, you post it to Discord and Twitter cause that's where your users are.

00:13:43 Speaker 1: Sorry, yeah, that's where my users are.

00:13:44 Speaker 0: But yeah, just go find your users and-

00:13:46 Speaker 1: Go find your users. So you can

00:13:47 Speaker 0: see- Open your calendar.

00:13:48 Speaker 1: Exactly, and if you work at like an enterprise company, you might have a sales team or an account team or customer-facing teams that might be able to give you feedback as well. But I got this whole laundry list of feedback, and I kind of pick out themes. And I'm like, I think this seems like a requirement. It feels like role-based access

00:14:08 control is a really big requirement. I really need to consider this. And I kind of start, it's almost like, Yeah, you're kind of like pinning together a story. So I kind of do a little bit of like post-it noting a little bit. I'll pick up high-level themes. And then I kind of start writing. There's kind of like a common format for writing a product requirement

00:14:29 document, which is You have to talk about an overview, an introduction, talk about the problem, talk about the goals, the non-goals, what's in scope, what's out of scope. You have to describe the solution a little bit or describe some of the solutions that you thought about. Then you have to break it down into requirements that engineering

00:14:49 can then take from your document. So I like to put this in like a table form of like, this is a high level requirement and these are like the interactions that the user could have with this feature. So after I do this, I then share it with my engineering team. I like to actually get preliminary feedback from engineers. My engineering team is so near

00:15:09 and dear to my heart. I trust their opinions so much Because a lot of the people on my team actually were previous users of the product. And that's how I found them. They were like Cloudflare geniuses and suddenly decided they really want to work at Cloudflare. And so I think I hold a lot of their opinions really, really

00:15:29 dear to me. But I like to circulate my PRDs ahead of time to say like, hey, if you had to write a spec about this, what am I missing here? Or like, what else could I add to kind of make the story more clear? And so I always make sure I have that kind of like technical requirement section. But I also think as a PM, building a requirements

00:15:49 document for developers, it's so important for you to tell the story. Everything I just told you about how I like to interview users and really understand the user, I want my developers and my engineers to feel the same way. I want them to totally understand the use cases. I want them to feel what I feel when I talk to developers. I want them to feel the pain points. I think

00:16:10 once engineers that are building the feature have that understanding of the pain points, They can think even better as an engineer, as they're building out the feature. So then we have kind of like this review process where we kind of go through the requirements document together and we'll have the whole team kind of ask questions of, well,

00:16:30 how come you can do it like this? And that might cause some reliability issues and that might be hard from a performance standpoint. And they kind of start picking at, like all of the requirements that I put together. I think it's funny as a PM, you kind of can dream up any sort of world that you want and then you kind of like face reality when the engine, yeah, that's not going to be possible.

00:16:50 And then of course, like as a PM, you're also kind of facing time constraints too, right? At CloudFlare, we have a really big ship culture. We're very adamant about getting things out into the world, testing them, iterating on it, getting feedback. And so sometimes we have to think about, okay, this is like the grand world that I'm thinking about, but what's my first

00:17:10 milestone? What's my MVP? What's like the least amount of work, not least amount of work. What's the smallest deliverable that I can get out the door so that I can start getting a little bit of feedback. And so I think it's important as a PM also to understand if engineers are telling you there are all these complications, it's important for me to understand, OK, Let me cut scope

00:17:30 here and let's kind of like shave this down a little bit into like a really nice MVP, which is a minimum viable product. So yeah, and then from there we kind of kick off like a spec process. And I am a very engineering involved PM. I think, I think I really like to shepherd this product

00:17:51 or feature through its cycle. You will find that a lot of PMs kind of just like write the requirements, pass them off and move on. I think it's because I like working with my engineering team and I like to learn more, that I like to be really involved. But every PM has a different style. And like, I guess depending on who you work

00:18:11 with, they might say something different, but I definitely like to see and I like to test as often as I can. So I involve myself a lot in like, okay, we have this like prototype working, like let me test it, let me try it again. So I do definitely like have a lot of these conversations with my team as the future is being developed.

00:18:32 Did that answer your question?

00:18:33 Speaker 0: Yeah, no, that was awesome. There's so much in there that I just think is really helpful for engineers to understand what their PM is trying to do and maybe what hopefully their PM, maybe they can encourage their PM to be a little more proactive after the requirements.

00:18:50 Speaker 1: That's a good call out. I think product changes so much and product means so many things to so many different people. But I think if you're an engineer that's struggling to understand the why of what you're building, that's feedback you should definitely give to your PM. I love to bring customer use cases to

00:19:11 my team, and I even love to bring my team on to customer calls sometimes if they want, if I know that they're developing a feature, we just launched like a build caching feature and I had a customer who was so excited about it and I was like, Hey, you have to join this call. Like, let me, let me, let me bring you on. And I think that kind of just, yeah, it kind of like gives engineers like a purpose to build

00:19:31 to, and not just build for the sake of building. But I think the why is really important. So I would really encourage engineers that feel like they're not getting that, give your PM feedback because that's something they can totally improve on.

00:19:43 Speaker 0: No, yeah, that's awesome. I think even just the idea that like you can give your PM feedback is a good thing. 1 other thing that, yeah, go ahead.

00:19:55 Speaker 1: No, I just think that the product engineering relationship is so, so important And I would, I think in any place, anywhere that I would work, I think that would always just be the, the health of that relationship is always just really important to me. So I think if you don't feel like you have that, it's definitely something that makes a product better in general.

00:20:15 Speaker 0: Yeah, yeah. So another thing that you mentioned was how you would like seek early feedback from your engineers and like, how can I improve this before you just drop the requirements in their lab? And that reminded me of the way that I typically convince my team of

00:20:35 something that I want to do, or at least like get a discussion going. So I actually wrote a blog post about this titled, How to get whatever you want, which is basically the trick is you have to make sure that what you want is what you can get.

00:20:55 But 1 of the things that I talk about in there is when you have decided, okay, I want to convince my team that we need to adopt TypeScript or something, for example. 1 of the best things you can do is put together the, like, first convince yourself that it's a good idea. So that means you gotta

00:21:15 like, look at all the pros and cons. And then you go to all the stakeholders individually and you say, hey, here are like, you plan the meeting, they all know it's gonna happen. And you say, we're gonna have this meeting, I just wanna make sure we make the most of the time. So like, what concerns do you have about this? And you just listen and like

00:21:35 let them say all their concerns and in the back of your mind you're like yep, I've addressed that. Oh no, that's a new 1, like let me think about that. And then you can like kind of talk with them a little bit about it as well just to see kind of where they're at. So that way, when you go into the meeting, you know all of the concerns of everybody and you address them all up front. And then

00:21:55 when you're all done, they can't even say that their concerns anymore cause you already talked about it. And then Vee is just like, well, I already answered that question. So,

00:22:02 Speaker 1: It's such a good idea to like pre-float things before you have this like massive meeting and I also think, I like to look at, I have certain people at work that, give me different opinions, right? Like I know that this person is going to be very focused on the customer and this person is going to be really focused on like end user experience or like

00:22:23 performance or something, everyone's like in charge of something else. And they're kind of like my board. Like I think of them as my board of directors who is going to give me like insight in many different ways. So I think pre-floating the idea, kind of like you said, just kind of makes that final review a lot smoother. And then the issues that are

00:22:43 brought up in that meeting would just be a little bit more like minor or like nitpicks.

00:22:49 Speaker 0: Yeah, yeah. Well, that's very helpful, I think, for folks. If you don't mind, I'd like to transition the conversation a little bit over to more specifically what you work on, the product that you offer. But speaking more generally around edge computing and why

00:23:09 I'd like to get your take on why so much of the web is pushing us toward the edge multi-instance or being able to have distributed applications and data and all of that stuff, so Navi why are you excited about that? And why does it matter to you and your users?

00:23:29 Speaker 1: Sure so This idea of serverless I think is a little bit misleading sometimes because it doesn't mean that there's no server, but for the user, it just means that you are not managing the server. You are paying someone else to manage the server for you. And in fact, it's not just 1 server. It could be many servers. I think there's a lot of providers out there

00:23:49 at CloudFlare that give you maybe just a few servers, but CloudFlare is 1 of the providers that's like, we want you to be able to run your application anywhere and everywhere, which I think is super cool. The part that I really like about serverless is the, like, you don't have to manage it part. I think again, being not a

00:24:09 web developer, but being able to get my personal site up, up and running super easily and not have to worry about like the heavy lifting of managing infrastructure or paying egregious prices is super cool to me. And I feel like it actually unlocks and enables web development to anyone.

00:24:29 The best part about my job. So I can talk a little bit about what my product is. I feel like maybe I didn't explain that properly. Sure. So Cloudflare Pages is, like I said, a build and deployment platform. So when you're building your application, you would basically use Pages to deploy that to the CloudFlare network. Pages is super unique and is

00:24:49 really cool because we like to integrate with the developer experience that you already have, or your developer workflow that you already have. A lot of users we noticed are using GitHub or GitLab or other source control management tools. We thought, what if we integrated with 1 of those platforms? That all you have to do is just commit to your repo and we can

00:25:09 build and deploy and handle all the CI and CD stuff on our end. Like I said, I think the super cool thing about Pages is that you don't have to worry about setting up all of the infrastructure to get to a successfully deployed application. Like I said, 1 of the really cool things about my job is,

00:25:30 I'm not just interacting with enterprise customers. It's not just like a B2B situation. It's actually a very B2C situation because there's developers who I've spoken to in Egypt, in Guatemala, like really far places in the world that are all trying to achieve the

00:25:50 same thing. And also in different socioeconomic statuses, like I feel like products like this are making web development actually super accessible to all different types of populations of people, which I think is really cool because that wasn't always the case before. You needed to have the computer, you

00:26:10 needed to have the financial situation to be able to get a website up and running. So I feel like serverless is actually making it also pretty accessible for folks to have a website and even to start a business, right? So I really love that about the serverless space in general. But I think from a business

00:26:30 standpoint, Serverless also serves as a way for you to kind of relinquish yourself from having to stress about your site going down or reaching customers all over the globe, right? So with Fodler specifically, if you have users that are all the way

00:26:51 in Australia, but you're located in the US, we will scale your application. You can reach users within a certain millisecond of time no matter where they are. I guess accessibility is my biggest takeaway from serverless. Like it really makes it accessible from a user standpoint, but also from a builder standpoint.

00:27:12 I think that's, it's for me, That's like the biggest advantage to using going serverless.

00:27:19 Speaker 0: Yeah, yeah, absolutely. And the unique aspect of Cloudflare, I think, is just the number of regions that are available. Like, I think last I checked it was, oh, I'm not, I can't say the number because I'll probably be wrong. What is it?

00:27:35 Speaker 1: 200. So I think by using Cloudflares, I'm going to use the approved statistics.

00:27:40 Speaker 0: Oh, okay.

00:27:41 Speaker 1: Using Cloudflares network, you are within 50 milliseconds of the world's internet connected, like 95% of the world's internet connected

00:27:56 Speaker 0: population.

00:27:58 Speaker 1: And then I think it's in around 270 plus cities is the metric, which is really crazy. Yeah, when you think about that, there's always like a little map with all of the dots all over the world. And when you look at that, you're like, wow, like, yeah, anyone can start a business. Anyone can deploy an application, but then also scale that application, right? Like,

00:28:20 I also gave a talk the other day about, I was like telling the story of a user who was building a game app, like a chess app. And you're a user, you start with your, start playing this game with your friends that you've built. But then suddenly your game goes viral and it starts reaching like the UK and Australia and suddenly

00:28:40 the costs are like way more than what you thought it was. And like performance is all whack because you have a lot of latency from like the connection between like Australia and the US. And I think that what we're trying to solve at Cloudflare is, hey, you actually don't have to worry about that. You can be a developer that has 10 users. You can be a developer that has 100,000

00:29:01 users. You can be a developer with all your users in 1 area, or you can be a developer with all your users in 1 area, or you can be a developer with users in every single region of the world. And I think that taking away that stress of, oh my God, what happens if my site goes viral on Hacker News 1 day and I'm not ready, I think is just like super cool.

00:29:19 Speaker 0: Yeah, yeah. So I think it'd probably be a good idea for me to mention that in for Epic web, I actually, I don't use Cloudflare. I think Cloudflare is very cool. And for all of the reasons that you said, we are using fly.io,

00:29:40 which is a different take on serverless where it's like serverless with long running servers. So you still don't have to worry about setting or managing the servers and all of that stuff. But your server is long running, so more traditional. And the reason, so here we can talk a little bit about trade-offs and stuff.

00:30:00 The trade-off that you make going with a traditional serverless architecture is that it's not long running. And so you spin up and then spin down and you don't really control that. And so doing things like background jobs or long connections to databases and stuff like that

00:30:21 is, or like even with Cloudflare it's running in V8 isolates. And so you don't have all of the power of node although Cloudflare is that those V8 isolates are pretty capable. It's pretty cool what you can do. But I was, for my personal website, I use FFmpeg to generate

00:30:41 podcast episodes and stuff. Like there are just some things that you, it's really nice to have a long running server to be able to do. So that's why I recommend Fly, but that's also why I wanted to talk about this because there are use cases that fit within,

00:31:01 really nicely within Cloudflare. And I just think that it's super cool what we can do with our, the hosting options that we have available to us.

00:31:13 Speaker 1: I think so too. I think also Cloudflare will never be, or our developer platform at least, will never be the platform that says, like, this is the only way to do something. And I think we are very willing and very happy for developers to choose what's right for them. It's also part of the reason why we have not

00:31:33 made super bold claims on like, this is the only framework, but we have really great relationships with a lot of different frameworks. Remix is definitely 1 of our very coveted favorite frameworks that we like to deploy on the platform, but we really like to meet developers where they are. So I think that the point I'm trying to make is that your use case and what you're building

00:31:54 is really contingent on what your stack is. And I think that's okay.

00:32:00 Speaker 0: Yeah, absolutely. So I have the Epic stack that is actually, basically Epic web is like, let's build the Epic stack together. That's sort of what the workshops are. And the big premise of the Epic stack is the fact that there are so many different options that we can choose from for how

00:32:20 we build and deploy our applications. And the fact is that most of those options will work just fine. It doesn't really matter too much which 1 you choose. There are some things that some options can do better than others, but at the end of the day, you'll probably be fine with any of them. And so even though I say EpicStack deploys to fly and you can

00:32:41 deploy to multiple regions, maybe not 250 or whatever, but like still many regions throughout the world and everything, that will probably suit the majority, the vast majority of people building apps. But same thing can be said for the Cloudflare side, that you can be satisfied for most use cases

00:33:01 on top of Cloudflare as well, which I think is pretty cool.

00:33:05 Speaker 1: Exactly, and every day we learn like certain use cases that maybe Cloudflare is not good for, and then we optimize and we're like, hey, this is important, like, let's go figure this out. So that's why the user conversations are so important. And that's why being a PM is a super golden job because you kind of figure out what the holes are in your offering.

00:33:24 Speaker 0: Wow, way to bring that back full circle.

00:33:26 Speaker 1: I know, full circle, right?

00:33:28 Speaker 0: Well done. That's awesome. Well, it's been such a lovely conversation with you. Do you have anything else that you wanted to talk about? We didn't get a chance to chat about.

00:33:37 Speaker 1: No, I think I just want to say that if you are taking this course and you feel like it's challenging, I feel like that's a good thing. I remember starting off, which I feel like you probably have done a really great job to make it not feel like it's super, super challenging and that

00:33:53 Speaker 0: people can't get to the core of it.

00:33:56 Speaker 1: But I just remember, yeah, going through my computer science courses for the first time, or even like starting this job and being like, oh my gosh, there's so much to learn. And there is so much to learn, but I feel like it's so exciting to be in a space. It's so exciting to learn the different trends that happen, the way that like opinions fluctuate over

00:34:16 time. I think it's a really exciting space to be in. I would just want to say, keep at it. And I'm also like, if you become a developer and you want to start using CloudFlare products, I love to have developer chats. I love to listen to you. I like to talk to novice developers. I like to talk to experienced developers. So definitely get in touch with me if you can.

00:34:37 Speaker 0: That's awesome. What is the best place for people to get in touch with you then?

00:34:41 Speaker 1: Twitter, my handle is at N-E-V-I-K-A-S-H-A-H. Definitely feel free to reach out.

00:34:49 Speaker 0: Awesome, do you mind me asking what the K stands for?

00:34:52 Speaker 1: Nevica is actually my real name.

00:34:55 Speaker 0: Ah, okay.

00:34:55 Speaker 1: Yeah, Nevi's like my nickname. I don't, I think my dad, Do you know who Nev Campbell is, by any chance?

00:35:03 Speaker 0: Maybe. I'm not sure.

00:35:04 Speaker 1: She's an actress. She just was in a show called Lincoln Lawyer. And she was also in Party of 5, which is an older show. But my dad had a huge crush on her. And he was like, we have to name my daughter Nev. And then my mom said, doesn't sound Indian enough, because my family's Indian. So she kind of made up this name, Nevica, and that's what my name is.

00:35:23 Speaker 0: I love it. That's great. So there's probably nobody else named Nevica, but that's pretty cool.

00:35:27 Speaker 1: You know what? Apparently there is, because I've been trying to get that Instagram handle and I like messaged this person a bunch of times and I was like, hey, do you mind if I pay you for the Instagram handle? Haven't heard back. But I wish them well. Thank you so much for having me on this.

00:35:45 Speaker 0: I'm such a big

00:35:46 Speaker 1: fan of Remix and I'm such a huge fan of Remix and I'm such a huge fan of you. So it's been honestly an honor to be here.

00:35:51 Speaker 0: Oh, well, you're so nice, Nevi. It's been an honor to have you. And thanks everybody for tuning in. And yeah, we'll chat with you all later.

00:35:59 Speaker 1: Cool, See you later!