AMA and Coding Q&A

JASON: Hello, everyone, and welcome to another episode of Learn With Jason. Today we're gonna do an AMA and kind of a coding/office hours/code party, whatever you want to call it, and I'm really excited because I haven't done one of these in a while. So what's up, chat? How are you doing? How are things? How have you been? How is your mom? How is your dad? You know, all those good things. I'm excited to see everybody here. I already see some folx in the chat. It's good to see you. Thank you for dropping those boops. Always very much appreciated.

I  today, it's been a week, you know? When you get that  it's holiday in the U.S., right? Yesterday was President's Day. So we didn't work. It was a longer weekend. And I'll tell you what, it is real weird to come back on a Tuesday. I mean, it's great to get a long weekend, but I'm so out of sorts. I've been telling people happy Monday all day. Yeah, it's been wonderful. I am using a new mic, Nicky. I'm trying out something new here because I have  I have a guess. I'm trying to  I'm working towards something. So what I'm using right now, this is a lapel mic, right? And so I'm trying this out for a couple reasons. The first one is I like the idea of not having a mic kind of in view here. That's, you know, just aesthetically it pleases me. I have to play with this a little bit because I know that this doesn't sound quite as rich as the SM7B and so, you know, I might do this for a bit and then decide that I just miss the quality too much and go back over. But there's another reason for this, which is I'm trying to figure out if it's possible to stream, like, on the go. Because I would like to be able to take the show on the road and not, you know, if I'm gonna go stay in, like, we've got this big plan once it's safe to travel to go spend a couple months in Europe. And if we do that, I would like to not have to not do the show. So this is all part of a new streaming setup where I've got the lapel mic running right into the camera. I'm using the Sony FX3, which has an audio in. It's actually got, like, four audio inputs, which is pretty great. So I'm running the lapel mic right into the camera and then that is all running into a Cam link 4k, which I'm running into my work  you know, I got a Macbook, the M1whatever. And I run that directly in there. And then I'm streaming the whole thing through Ping Video. So what you're looking at here, this is coming through ping.gg, which is a streaming service that's kind of geared towards Twitch streaming. So it's all very, you know, new. Pretty happy with it overall. I love the quality of the FX3. I'm really happy with the quality of Ping. So far, the M1 doesn't even show me that it's working very hard, like I can't hear it at all, so, you know, got a lot of things. And, yes, Rafa, we are absolutely going to visit you. Actually, I haven't told you this yet, but we're staying at your house. [ Laughter ]

But, yes, no, we really want to spend some time in, like, in the Netherlands, in Denmark, we want to get back to Spain. We spent a lot of time there and it was amazing. And I don't want to have to stop the show to travel and I don't want to have to stop travel to keep the show going, so this is all part of an experiment to see whether or not this can function on a single computer. So I'm still streaming off of two computers right now. I've still got the streaming box over here that I'm using today, but I'm gonna do an experiment where I do it all off of a second computer here  off of a single computer. Probably not for a real stream to start. I'll probably figure out how to set up a, like, a test account or something so that I can stream for a while and make sure that nothing overheats and that the computer doesn't get sad or anything like that. But, yeah, let's see how this goes. And Theo, no, I'm not delaying travel for the show, but as we're starting to see that international travel is a little less stressful, more people are getting vaccinated, the numbers are starting to flatten out and hopefully going down, I would like to start traveling, so I want to have the show ready to be portable to accommodate that so that I don't have to figure out other things. Ooh, I will take you up on that and start talking about how we make this work, especially the biggest question mark I have is how to get fast enough internet to stream off of anywhere.

So, you know, still dreaming about that little satellite box that will just give me fiber speeds anywhere I am, but, you know, we'll see how it goes. All right. Okay. So, how is  what's everybody up to today? Let me  everybody think about if there's any questions that you have. If there's anything you want to take a look at. I figure I can pull up my laptop and we'll  we can do a little code along stuff if there's anything you've got questions about. I'm also happy to answer questions about the industry at large. Whatever my experience can lend in that area. So, developer experience, career growth, network growth, you know, you want to talk about burgers, you want to talk about anything. Anything, really, I'm down. So, you know, today is your space. Let's give y'all some time.

While you are thinking, I'm gonna do a quick shoutout to our sponsors. So let me switch over to the desktop here and pull the right thing on screen. I only sort of prepped for today. Sorry. Yeah, let's get this up. So we have the show. It's cool that it's only that wide. That's fun. But okay. This show, like all shows, is being live captioned. We've got Jordan here today from White Coat Captioning taking all this down and making the show more accessible. Thank you very much, Jordan, for being here. You can find that right on the homepage of learnwithjason.dev. That is made possible through the support of our sponsors. We've got Netlify, Nx and Backlight all kicking in to make this show more accessible to more people. That also helps me just keep all the lights on, do all the things that I do like the highlight videos and being able to, you know, take time to build this stuff, and build extensions, and I have, you know, Aiden who helps me with keeping the admin side going. Chris at Lemon Productions is helping me with all the video editing. White Coat Captioning, I pay them for the accessibility and the captioning. A lot of things kind of creep in to make this show cost money and the sponsorships and your subscriptions all make that more sustainable. Speaking of subscriptions, thank you very much, Brennan, for that. I really appreciate it. I will put it to boopy use.

Let's see. Hold on. What's implying that a burrito  a burriti. Let's see. What is the ultimate breakfast sandwich? Ooh, this is a good question. All right. I have feelings about this, all right? So let me talk a little bit about my world view on food because this is an evolving theory of food that has been kind of marinating in my head for a while. But I'm starting to come to the conclusion that I believe that in order to make something truly excellent, to cook really, really well, you have to love that thing. Like you have to have, like, sense memories of that food so that when you're cooking it, you  you're, like, connecting it to good member rips and love and care and all of this history. Because that's what makes food truly amazing. And for that  I mean, I think that's why I'm good at burgers. A lot of my, you know, my great memories as a kid were getting, like, you know  about the only time I got to see my dad for a few years was he was working at, like, a highstress job, and so we would go and pick up cheese burgers and bring them to his office, and we would sit around and that was, you know, so that was really close to my heart. That meant a lot to me. And, you know, the same thing around breakfast. Like my whole family would get together and we would all cook breakfast together. So you get all these not just, like, experience cooking the food, but, like, emotional investments into a meal. And I think that that makes you really  that's how you excel at cooking something. You know, you really care about it. You really bought in, right?

And so I think that there are, yeah, there's so many amazing things that you can do with this. But to kind of work that around  I also think, I will say, this is why I'm not good at cooking fried rice. If you come over to my house and I cook fried rice or I try to make you know, bun cha, one of my favorite Vietnamese dishes, it's gonna be just okay. I love it. I'm basically living about Asian food right now because I'm trying to cut down on gluten and dairy. I can't cook it the way someone grew up on the food cooks it. Obviously if I studied and practiced and had people who had those memories, I'm gonna build those memories and become great. That's not saying if you didn't grow up with a food, you can never be good at cooking it. It's just I don't have the context and the history of it. So, let's take that back to the original question about what the best breakfast sandwich/burrito is. [ Laughter ]

I am a big, big fan of a fairly simple breakfast sandwich. I think that you want probably like a sausage patty or ham but not a lot of it. You're not looking for a big honker, you know, huge amount of food. You're probably looking at, like, 2 ounces of sausage or, like, thick but not like super thick cut of ham. You want an over medium egg. So done enough that it doesn't just  it's not just a water balloon, but not so done that you don't get any of the runny egg yolk because that egg yolk is the condiment. Like that's what you want on the sandwich to really make that work. And then you just want, like, a slice of cheese, right? Something to hold that together. I like a cheddar. If you, you know, you want to make it a little more, like, creamier, you can throw American cheese on there or you can throw havarti. The catch is if you build the sandwich wrong, the havarti is going to immediately separate into two globs that will squeeze out the side of the sandwich. You got to think about the construction of the sandwich. Not letting everything get too soggy. Putting the egg and the cheese together because then it becomes like a slip n slide. The sandwich falls apart. It gets really messy. Choose whatever bread you want. I love a biscuit. Chance the Dev on Twitter has hooked me up with a really good biscuit recipe. So take a biscuit, put it in some butter, get that nice and toasty on both sides and build the sandwich on top of that. It's amazing. Do the same thing on some good sour dough bread. Sour dough's a little tricky because it has tact to it. If you bite too hard, the whole sandwich is gonna pull apart. Again, you've got to get the textures right. If you've got swishy ingredients and really tough bread, everything is going to squish together and blow the squishy ingredients out of the back of the sandwich. Then you got a mess. You got to eat it with a fork. It's not great anymore. There are a lot of ways to make that. One of my alltime favorite ways is if you can get a really soft roll, like a potato roll or just any kind of  something that is soft but not, like, immediately gonna turn into tissue paper as soon as it gets any grease on it. And then you just butter and toast the one side, the butter kind of seals it so the grease doesn't immediately soak in. And then make your sandwich on that. Oof, that's a great time. What a great sandwich that is. I also like vinegar on sandwiches. Something to brighten it up. A little bit  honestly, squeeze a little lemon on top. Real good. You can put pickled onions on there or just a tiny little dash of, like, oil and vinegar to kind of bring out the brightness of it. But, you know, you got to be  you got to do you, right? Not really a wrong way to make a sandwich. You just got to make it with a whole lot of love. So how long did I spend talking about that? Probably way too long. Let's see. You can show me fried rice if I show you burgers. Deal. 100% deal. I'm so ready for that. Okay. So let's talk about  what else do we got in here? What is IC? I obviously don't know anything about your circumstances, but bear in mind some managers give you daft goals. It's always worth checking them. What's IC? So, Graham, if I'm understanding correctly  like, hold on. Is this a response to  you're responding to somebody else, aren't you? Let me go and find the original question. They asked me to  got my perf review feedback. They asked me to focus on crossorg contributions. How on Earth do I do that? I'm just an IC. This is a great question. This is very top of mind for me because I'm working on career ladders right now. So for an engineer as an IC, there's a career ladder that I'm gonna give you the progression that we have at Netlify. These are gonna vary a little bit because how somebody defines staff is different at different companies and there are different titles and different things. Just assume we're going from the beginning of your career to as far as you can go as an IC. So at the beginning, you've got what we would call software engineer 1 or early career. Then you've got software engineer 2. That would be  you've got a little more experience. You're doing good work. Senior. Then you go to staff. Senior staff. Principal. And then there is another rung for distinguished engineer. If you get to distinguished engineer, that's somebody who is, like, 15, 20 years into their career. They're effectively being  it's like getting tenure as a professor. You are there because you're proven to be super effective and you're really just trusted to solve problems. But so let's go back down. At software engineer 1, early career, I expect you to be able to learn. That's really my only expectation of an engineer at software 1. You are, you know, you're curious, you retain information. We don't have to tell you things half a dozen times for them to stick. You are, you know, proactive in asking. You are out to progress as an engineer, right? When you get to software engineer 2, the idea there is that you're now capable of doing individual tasks kind of on your own. You're selfsufficient if you've got a clear todo list and the todo list is made of smaller tasks. A senior software engineer is someone who I would say we need to build, like, a website. And I need you to do that, right? So I expect you as a senior engineer to be able to take on more  slightly more ambiguous tasks and be pretty selfsufficient at that. You should be able to break it down from one big kind of websiteshaped cloud into a list of tasks and then break those tasks into subtasks and, you know, kind of work through this thing in a way that gets you a good result. That's senior to me. So after that point, you're no longer selfsufficient as you look at career advancement. When you get to staff, what I'm looking at staff is that you start empowering the rest of the people around the team. I'm looking for you to be kind of a tech lead. You're advising people on the team. You're able to, like, break down tasks in a way that other people can pick them up. So if you were to be  you know, if I'm your manager and on a team of let's say three people on a project, if you're the staff engineer, I would expect you to be the one who is able to kind of help do the tech leady part of setting up the earlier career engineers with their todo lists and helping them talk through scoping issues and all those sorts of things. When you get to senior staff, I'm looking you to do that across the org. So, developer experience is for teams, for example, inside of Netlify. My senior staff engineers, I'm expecting them to move between teams and start thinking about how these different teams work, fits together, and how can, you know, like, for example, we're doing work on our doc side. The docs is a team that sits with developer experience and our developer experience engineers are out there talking to customers. So my senior staff engineers, this is Ben Huang I'm talking about, he is talking to different people who use different technologies and he's coming back with ideas saying, hey, the way I'm hearing about this, I could write a tutorial, but it would actually be better suited if I did a little bit of tutorial but a lot of what people were asking to live in the doc. Can I work with the docs team to kind of scope out a project? Ben's not gonna do that work. He's not gonna manage that work, but he helps to raise awareness to allow the docs team manager, Rachel, to have broader visibility into what people are trying to accomplish and they can make a bigger impact that way. Now, principal engineer, I'm expecting them to make companywide impacts. And a good example of this would be, say, if I  like when I was  I was a principal engineer before I took over as the VP. One project that I worked on was I worked with Marisa on our research team and she had this idea about, like, we needed a faster feedback loop. And so she came up with this idea around Netlify Labs, and then I started talking to the engineering team and the product team and the DX team and the docs team and the support team about how Netlify Labs could fit into the Netlify story. And how would this help us ship faster? How would this help us get fewer mistakes that are, like, huge and hard to roll back? How would this help us cut down on resourcing spend? Like all these things that, you know, they're not me as an IC. This is more, like, how could this system, this idea, this project  I built the project, right? I built out the original incarnation of Netlify Labs which has since gone through a whole bunch of work by the engineering team, which is why it's better now. You know, I was the IC who built that original implementation, but I was also an advocate who helped connect the idea and the goal that Marisa had with a, like, the goals of the other organizations, and I tried to think about how if we architect it like this, how does that fit all of these different pieces to the and how does that change the way that we work together as a company? How do we make sure that doesn't leave support holding a really big support burden of extra questions coming in. How do we make sure this fits into the product roadmap that doesn't, like, whip everybody around and change their priorities? How do we make all this stuff fit together? Because as a principal engineer, your job is to then understand how does the work I do individually affect other people? Not just on my team. Not just in my organization, but across the entire company. And I think the broader scope is where you start to see that seniority. So, really, after you get to senior, everything about advancement is in expanding your impact beyond yourself, right? So when you get to staff, it's team level. Senior staff, org level. Principal, company level. And it's never about being a manager. It's never about, like, controlling other people's work. It's about thinking about their work. Can you think through how different roles and responsibilities and impacts are gonna affect different people's goals and motivations? And can you communicate about those things in a way that helps people connect their goals and their motivations to the outcome that you're trying to achieve so that you can drive that kind of crossfunctional work and get those impacts that you want?

So that's a pretty long answer there. But, yeah, that's  this is  it's a tricky one, right? Because you're an individual contributor. You're not in charge. Honestly, individual contributors drive a significant portion of what happens at any given company. It's through advocacy and helping tell better stories about what we're trying to accomplish and why. So I think that's a really important thing to do. Let's see. Scrolling through to make sure I'm not missing any questions. What is my favorite dish or entree? I cannot answer that question with an actual dish. I will answer that question with, I  my favorite thing is the thing that the chef loves more than anything in the world. Like I have had dishes that I would have sworn would be boring or even flatout gross. I went to Slovenia, an amazing restaurant, and they served us squid stuffed with organ meat. Which sounded disgusting. They were explaining it to me and I was like, ooh, boy, I have to choke this one down. It was one of the best bites I've had in my life. It was so good my partner actually teared up a little bit. And it sounds so disgusting. Nothing about that meal sounded appetizing, but that chef loved that food. Absolutely loved that food. And because of that, the food was prepared with that level of care, that emotional investment. And you know what also comes with, that restaurant is out in the middle of nowhere. You've got to road trip and stay in an Airbnb. There are all these things that add to the experience. But at the end of the day, it's the thing that the chef really, really loves. Or just something that kind of encapsulates a moment. I went on a hike once and I was with some people that I really care about, and when we got about halfway up the mountain, we realized the hike was gonna be way too steep because I had, like, sneakers on. I wasn't wearing hiking gear because I thought we were going on a walk. Didn't realize we were gonna hike a mountain. When we gave up this hike, we sat down and turned out my friend had been planning a surprise picnic. I was feeling discouraged like I ruined everybody's day. Everyone wanted to go to the top of this mountain and I had to quit. So I was bummed. My friend all of a sudden just starts unpacking all of the  it was, you know, local charcuterie. He had a couple of bottles of wine in there. We had this incredible picnic on the side of a mountain. It turned what could have been a terrible day into a really memorable meal. Now I remember that being one of the best charcuterie meals I've ever had. I don't remember what the food actually tasted like. It matters so much who you're with, what's the story of why you're eating in the first place. I went back with a different group of people and, this is just okay. What's different? I think it's so much about circumstance. Let's see. Any thoughts on the Netflix documentary about the 737 Max? I honestly have not seen that documentary, so I cannot comment on it. Sorry. Let's see. Is it time for a website publication dedicated to Jamstack and related tech? PeakZebra, I would say there are some already. Brian Douglas has Jamstack radio. Brian Rinaldi has  I'm blanking on the name. Sorry if you're watching. He has a suite of things. Raymond Cannon does a lot of things on Jamstack. Salma on the  whitep4nth3r on Twitch. There is Jamstack.org. So there are some publications. However, I do think that this style of building is  it's not showing signs of slowing down. And I think that we're probably due for a little bit of a rework of what we think Jamstack means. I think it's gotten, you know, it started out as, like, a tiny thing and then as we worked on the concept, it's ballooned and I think it's too  it's too broad. It's too vague now. We're probably going to pare it back down. Ultimately, you've probably heard me say this before if you've ever watched the show. We're not about dogmatism. It's not about doing things on one stack. It's about doing things that's pragmatic. You got to look at the solution, the outcome you're trying to achieve and make sure you're choosing tools that support that. We think the Jamstack, this idea of precompiling when you can and shipping assets to a CDN instead of having to run a server all the time, it's a good default. It's not gonna serve all your needs. But if you start that with your default assumption and escape from it when it's time, that's gonna help you build the best website experiences out there. So is it time for a publication? Yeah, could be. I mean, I think, you know, everybody is always looking for more expertise. People are always looking for more case studies and how do I solve my particular use case? So there's a lot of potential there. That I think is  so, short answer, yes, let's do it. Let's see. What's an IC? An IC is an individual contributor. Yeah, somebody who does not have direct reports would be an IC or an individual contributor.

Hi, I built a back end for the ecommerce using Django. Is it a good product for the r�sum�? Yeah, anything you built. Look, the particulars of the tech you use sort of matter. If you are applying to a job where all you're gonna use is JavaScript and everything in your r�sum� is, like, C++, it doesn't mean you can't do the job. It just means that you're looking at a learning curve to get started because you're switching from a language you know to a language you don't. However, I am never looking at a r�sum�, like, oh, you didn't use exactly the framework that I prefer. In fact, I'm looking for people who have a little more breadth of experience. I like it when someone has worked in different tools because, to me, the breadth of experience adds a  I'm gonna  I think pragmatism is the word of the day. It adds a pragmatism. You can look at tools and assess them for what they are instead of saying, well, this is my stack, and I love my stack. So I'm going to use it no matter what. You know, I think we're ultimately trying to look for a way to prevent the  you know, we don't want people to be fanatic about tech. That's not a good way to do anything. You don't want somebody to say, like, do it this way and then you're like, well, but why? And they're like because I said so or because it's correct. That's not a good way to live your life. That's not a good way to build tools. You should kind of understand what you're trying to accomplish and make choices that way. Building in Django. Yeah, do it. Show it off. That is a great thing to show off. Show off anything that you built because it shows you were able to follow through on a project. It shows you were able to use some tools and get them all to fit together. Just build lots of things and share them all. That is a really good way to show somebody that you are invested in growing your career. Let's see. Let's talk a little bit  let's see. Lots of people giving good answers to that portfolio question. So, thank you to MHuggins and Brandon for weighing in there. Yeah, showing that you can learn a diverse set of skills and languages will only help you out in the long run. That is a great callout, Brandon. Thank you. I'm trying to get into product design and I do it in my job, but in a completely different industry. Any tips for shifting? Okay. Let me  so, I don't have direct experience with this because I've  well, I guess I kind of do. I don't know. My whole career has been, like, this slow imperceptible shift between roles. Because I started out as a musician and somehow ended up here. But I think what I've noticed is that the vast majority of the things that you'll do in a daytoday job are pretty similar in terms of just operating on a team. And so if you start plotting out the job and you look at the Venn diagram of, like, okay, here's what I did in this industry, in this role, and here's what I'm gonna need to do in this industry in this new role and you  you'll start with, like, just the highlevel stuff. Oh, I'm a designer, right? And before, I was in IT or I was in customer service or a managed a Starbucks, whatever. Any of those things, you can go, oh, well, there's no overlap. There is nothing in common between those two jobs. If you start to think about it. Okay, hold on, though, because I was figuring out how to, like, understand how work fit together. I was managing my schedule. I was working cross teams. I was trying to understand how different projects fit together. I had to stay on top of my deadlines. I had to understand how, like, the work of one thing  and suddenly you're looking at, oh, dang, 80% of this job is the same as it would be on any team. Like I have a skill set that is I am a functional adult in a professional environment. Right? That is really hard if you don't have that skill. It doesn't matter what your other skills are. So finding a way to practice the new skill in a way that you can somewhat demonstrate. And with product design, I'd say you're probably looking at public critiques. Do, like, imaginary projects where you kind of break something down and redesign it and talk about why. Kind of case study stuff. Talking through, you know, the choices that you make and why. What do you think it will impact? How is this gonna  how would you resource this? Like what  and it also depends what level you're trying to go in, right? If you want to go in as a junior product designer, a lot of what I said isn't gonna be relevant. But, you know, showing your body of work and, you know, as far as industry shift goes, it depends on the industry. Some industries are really insular. And some are really stoked to get somebody from one industry coming into another because it provides a whole different insight and level of experience. So I would say try to look at the strengths of what you were doing before as a set of benefits to the company that's bringing you in. You bring a different perspective. You have a more wellrounded look. You can connect different dots because you've done different things. All of those are really, really beneficial if you look at it that way. I've got  Natalie Davis joined the Netlify team, and she came in as, like, if you were to look at just experience, you might go, oh, well, she's a junior developer. Is she gonna do well here? If you look at her r�sum�, she spent a long time being the manager of a retail store and, like, dealing with a whole lot of complexity that comes with that. And so her ability to understand projects and manage and all of those things has made her kind of unstoppable. Like she came in and her ability to quickly learn and figure out where to get information and make sure that she remembers things and connect dots and get to the right people about the right information, I've never seen anybody do it like she does it. And that is, you know, that is something that she could have easily said, well, none of that's relevant. But that is honestly, like, a superpower for her. And so I think it's important to think about, you know, what are your strengths in your current job and how would they help you do a better job as a product designer? Let's see. Asking: What do companies want when they ask if you have experience with cloud like Azure, AWS? A lot of times, companies are going to be built on top of big cloud providers. So when you  if you look at their stack, there is a decent chance that they've got some microservice that they built inhouse that's running on EC2 or they've got their, you know, their front end is on S3 and CloudFront. You've got route 53 in front of that. Using an API gateway. AWS Lambda and container management systems, all that stuff. Now, you don't have to have done any of that stuff to get a job, but if you already sort of understand how those pieces fit together, it can make it easier for them to onboard you and that makes them feel more confident in making a hire. Generally speaking, I find people are pattern matching in their r�sum�s. They're looking for people to, you know, put this in the least charitable way possible. As a hiring manager, you are completely overwhelmed and so you're looking for the person who is going to make you do the least work to hire them, right? That's  and I don't think that is the whole story, and I don't think that is a, like, I wouldn't say that is, like, the only thing I would say about hiring managers, but generally speaking, if you as the applicant can show a hiring manager that you are  you're gonna be the selfstarter. You have enough experience with the things that they use at the shop that you would be able to kind of hit the ground running and you're not gonna have to ask them a whole lot of foundational questions. You're not gonna need a lot of handholding to get going. All of those things make somebody more confident in making that hire. So I think, you know, the  a cheat code for anybody who is trying to get a new job is to if you really want a job, research that company and figure out what is their stack. Like you can always find their engineers on  if you're trying to get into engineering, find their engineers and ask them a couple questions. Like don't be  don't be overboard here, but ask a couple questions. What's your stack? What do you work on every day? How do you manage this stuff internally? And just familiarize yourself with it a little bit. Get a sense of how all that stuff fits together. Because then when you have a conversation with the hiring manager, with the rest of the team, you'll have enough familiarity with the rest of their stack that when you talk about it, you're gonna sound capable, you're gonna sound confident. They're gonna hear that and they're gonna feel that and that's gonna make them more confident in saying, yeah, this is gonna be a great fit. It's all stuff you'd have to learn anyway, so it's a great way to show initiative, too. You know, like, if somebody comes in and they can tell me, like, I've done this research on the Netlify product. I see the way you've done things in the past is like this. And, you know, I've done a little bit of that myself. Here's how. You know, here's a similar challenge that I had at another company but it was a different stack. Here's how we overcame it. I'm getting the sense that this is somebody who is really invested in this job. That is not practical to do if you have dozens and dozens and dozens of companies that you're going after. But when you're looking at a key set of, like, dream jobs, it's probably worth doing that research for each of them so you can go in. I've seen this  I know that Ramit Sethi has kind of a reputation, but if you  he has this one concept he calls the briefcase technique, which is this idea of going into an interview super wellresearched. You should have things ready so that when somebody talks to you, you are just projecting, like, I did my homework. I want this job. I'm invested in getting it and I did the work ahead of time so that you don't have to educate me. That's the kind of energy I'm gonna carry into this job, is being ready and being proactive. That, to me, is solid gold. I love when somebody comes in that prepped. It's an automatic, like, ooh, let's take this person seriously, for me. All right. Let's get in here. So I know I'm kind of slacking on the chat here. Running behind. So I'm scanning back through. Let's see. We've got Brian Robinson. I was talking about Brian Rinaldi earlier. CFE.dev is what I was talking about, yes. That is a series that Brian is running. Let's keep going. Ooh, Theo. Hot take. So, Thea says, I think we're nearing the end of specialized publications. Producers are getting more specialized and the platforms are getting more generic and algorithmic. I think you could be correct. And, I mean, obviously, that is what's happening on TikTok and YouTube and Twitch and all those things. But I'm  I think there might be a place in the market for niche publication still. We'll see, right? Like  and it always depends on who does it, right? Because if the right person has the right idea, it doesn't matter how much it doesn't make sense in the market. It's gonna work. And if the right person chases an idea that they don't care about, it's probably not gonna work the same way. So I think there's always room for somebody who brings in, like, a unique take and puts the right amount of, like, love and care into it and does the work. Because it can create a whole new kind of category, right? So, yeah, I'm not sure. But I do  that is a good take because that does seem to be true. At least as far as, like, startups go, right? There's a difference between are you seeking venture capital versus are you seeking a publication where, you know, you could pull in some advertisers and make it a lifestyle business that pays enough for, like, you and maybe a little bit of help, but not necessarily, like, a multimilliondollar business. Yeah. Let's see. Let's see. Let's keep on going through these. Ryan Solid. What's up, Ryan? The challenge that Jamstack has  the challenge is Jamstack has grown beyond the original differ information. 100% agreed. Yeah, I think  I mean, I think this is a big  a very big challenge and it's something that we're talking about a lot inside of Netlify and the Jamstack community. If you're in the Jamstack Discord, you can join up and see a little bit of that discourse. I think the general sentiment is, yeah, it got too broad. It got too murky and cloudy and we need to figure out how to explain it in a way that makes sense. Like right now, it's kind of a  Jamstack is a feeling. Not a good way to talk about tech. [ Laughter ] Let's see. Theo, also music to tech. Yes. There are a ton of people who are music to tech. Let's see. Let's see. Just diving through more of the questions here. Nicky. I do have a particular set of skills. Let's see. Just digging on through these questions. Yeah, Theo, that's a good way of putting it. My framing for a hiring manager is not generous. It's not the last thing I would say, but if you assume that every hiring manager is trying to get out of doing work, it's going to give you a leg up as an applicant because that's kind of a cheat code. Prevent the hiring manager from having to do work and you are going to have an easier time getting that job. Let's see. All right. Ben Holmes is asking  I know you've been pretty bullish on Island's architecture recently. Based on what you've seen, like Jamstack sites like Astro and not as Jamstack sites like Next.js and Remix and when do you cross that line? Oh, no.

All right. Don't know why that would reset my Zoom, but here we are. Okay. Audio's back. We'll see if it does anything on me, but, yeah, fingers crossed that it doesn't overheat again. It's also hot in my office. I don't know why. So maybe I just need to keep a window open or something. Okay. So let's go back to Ben's question and say, bullish on the Islands architecture. So where's the line between Astro Slinkity and something that is more servery like Next and Remix? I think the answer is Remix is not a Jamstack framework. It's not intended to be. However, what it's doing is it's similar in motivations and I think it's just the underpinning, like, what's the bottom goal here that makes a big difference. So what I'm seeing out of Jamstack sites is a push from static to let's see if we can get to the edge, and so we're seeing collapse  workers. Netlify's been working on edge functions. Fingers crossed, we'll see those come out soon. And that gives us this ability to have serverlike capability at the edge. Because serverless functions give us serverlike capability, and we all like that. It's kind of been broadly accepted that is a Jamstack extension that makes sense for Jamstack. Whether or not that sticks when we decide where we're drawing lines, I don't know. But so, you know, with Remix, we can run all of Remix in a serverless function and it's great. Remix has designed  they're spending a lot of time thinking about how does Remix run in a web worker? How does it run at the edge? And that, to me, is really, really interesting because it starts to tell a different story where it's no longer, like, let's have a server  okay, maybe let me back up a little bit and try to add some context to why I'm about to say what I'm about to say. Jamstack was created because at the time, when you started looking at servers, you had these really challenging problems where a server was a longrunning process in a container or a physical box that you then needed to figure out, how do I deal with scale? What happens if a whole bunch of people show up to my website because we get featured on the front page of Dig or Reddit or Hacker News or something? What happens if we, you know, we run a Black Friday sale or a Super Bowl ad or whatever and suddenly the whole world is checking out our stuff. What would happen before is the servers would get overloaded. You might remember the Twitter fail whale or you get over capacity messages or just anything like that, where it was very clear that whatever was going on, the service had reached the absolute limits of its capacity and it just couldn't take any more traffic. So that was a problem. We needed to solve that. People started solving this in different ways. One of the ways people would do that is by aggressive caching. So you would take your server and put a varnish cache in front of it. Whenever you request a page on a server, varnish would take the rendered output from the server and stick it into this varnish cache to prevent people from hitting the server and instead serve the rendered version. This might sound a little familiar. It sounds like Jamstack. Except varnish is hard to set up. Your server can still go down. Because it's complicated to configure properly, the risk that you run is when you set up Varnish, if you don't have great documentation on the way that you have set it up, your developers might get frustrated because they can't get fresh content, so my might do something like, I don't know, attach a random number as a query string to every request to manually break the Varnish cache. Not that I've ever done that at my job before. And so you run into these problems where, like, the cache is there, but it's more of a hindrance than a help in some cases. It can lead to some really complicated stuff. And developers don't quite understand how it works or why. So then they'll work around it. And so then it gets even more complicated when you start looking at, like, your backend microservices and you're like, okay, well, let's also cache APIs by putting a Redis cache in front of that. Now you've got a Redis cache and a Varnish cache. Those are talking to one another. If you clear but not the other, you can get into this loop where you can't unbreak your cache without turning them all off, letting them refresh and turning them back on. I've seen this take down production sites for, like, days. Recently I saw somebody do this where they set up their cache in a way that was dependent on another cache, and only one of those got cleared so they got this partial state and couldn't figure out how to clear it. The website was down for, like, a day and a half. That is completely unaccessible. So Jamstack was an approach to solve that complexity. We've got a server. We want to get a lot of content out to a lot of people and we need that scaleability to work. And caching is too hard. So Jamstack, instead, says, well, we know what's happening with the Varnish cache is we are getting a request, getting some assets and putting that into the Varnish cache. What if we move that ahead of time. Build this site once, get that cached output and throw that out to our users on a CDN, which CDNs are famously hard to take down. If you're gonna D Dos anything, CDN will be about the last thing. Not saying it can't be done, but it's way, way harder. So that built this resilience in. But at the tradeoff of now when you want to get new content on to the site, you have to rebuild the whole site. Okay. Not great. Enter serverless, serverless gives you the ability to opt in to partially dynamic content without having to give up the benefits of most of your static content that only changes once every week or couple of weeks or potentially never. That stuff just sits and stays static and nobody ever has to worn about it. You never have Varnish caches or Redis caches or any of these other things that can get really complicated to manage. So then you get to the serverless side. This is where things start to get murky because now, like, okay, Remix is running entirely in a serverless function. Is that a Jamstack framework? The obvious answer is no. You don't cache anything, right? You only cache actual static assets like JavaScript files and CSS and stuff like that, but you're not caching the rendered page. You're caching the supporting assets, which is what we were doing before. So that's why I think we need to have this conversation about what the differences between, like, the Jamstack philosophy of setting the right defaults  and, again, this is where it's become Jamstack is more of a feeling than Jamstack is a stack. Because using the traditional acronym of JAM, JavaScript, APIs and markup. We have to rework that a little bit and come up with a better way of communicating this as a community so that people can understand and so that it doesn't sound like we're just trying to, like, be slick and say, oh, well, Jamstack is whatever I want Jamstack to be because that's my favorite stack, right? This is where that pragmatism comes in. Jamstack is a set of defaults. You're gonna escape those defaults. Like I have a lot of sites and all of them have at least one little piece of dynamic content. Sometimes I do that in a Jamstacky way by having a singlepage app and React makes a call from the client. A lot of them use serverless functions. Some of them, I have a backend that I set up that is, you know, I'm using, like, I'm using Remix for the Learn With Jason site now. Is that a Jamstack site? Kind of. I don't know. Like technically not. But I'm still following a lot of the same principles. So I honestly don't know. Like it's very murky right now. Which is also why I've started talking more about modern web development versus Jamstack specifically. Because I'm not sure the distinction matters because I think the goals are the same. We're trying to create really good web experiences and when Remix is the right choice, it's the right choice. I don't want to have to explain why it's technically Jamstack to make that work. All right  this is gonna  [�Lost audio ] It's not gonna sound great, but we're gonna roll with this mic. [ Music ]

And then go back here. And that should all sound a little bit better. It's still too quiet and I apologize for that. And I'm gonna have to figure out how to run some cooling through to this camera. But we're gonna just  we're gonna roll with it, as much as we can here. All right. So that was a  that was a  we're gonna call that a monologue, diatribe, soapbox? Dang. All right. Let me go look here. Jamstack is not a technology, it's a lifestyle. I know. I know. I know. But, yeah  yeah, it's framed in a way that just feels like you can shove anything under the Jamstack label. Yes, that is correct and that is not what we want. Tony, this is a  it is a Mirrorless. It's the Sony FX3. You can tell I'm going a little red here. My heat is on and I don't know why. I need to stop that. I'm actually gonna go open a window so that it's not, like, a million degrees in here. So everybody bear with me for one hot second. I'll be right back. All right. Welcome to my 85degree office, everyone. We did it. We did it. All right. Let's see. We got  yeah, Theo, I do think it's the battery replacement, so I'm gonna have to figure out how to make that work. Yeah, the last one I had was, like, an official Sony battery pack replacement, and this one is not, and it's not doing great. Yeah, I mean, the fail whale and, like, dig and stuff, that was the era we were talking about, though, was people trying to work on those types of systems, and we just didn't have the  we didn't have the infrastructure for it. But a really good way that I've heard this put. I heard this from Ryan Florence, but the quote is from Herman Hess, and the quote is, we're not going in circles, we're going upwards. The path is a spiral. We've already climbed many steps. If you look at it from the top, it just looks like we're going in a circle like this. But if you look at it from the side, what's actually happened in the industry, we started here. We had some problems so we went over here. We solved some of the problems that were originally down here. We come back and take the best of that. And, you know, we solve in areas and we eexpose shortcomings and because the shortcomings take a while to solve, we move on to solutions that patch those shortcomings and expose new opportunities. So we kind of move in this upward spiral where we're pushing the limits of things. And that's good. That drives innovation. That's what makes, you know, the web what it is today, is that there is this market of people saying, well, I'm not happy with what I can do with static assets only. I'm gonna go further. And that's why Remix is doing what it's doing. That's why it's cool. Then we've got people saying I'm not happy with React as  or JavaScript being the only medium for the web. That's why we've got Islands architecture. Both of those are going to inform each other in the spiral. So a lot of really exciting stuff going on here. Let's see. Let's see. We got a lot of  PrincessPJs, thank you. I'm sad that my camera is being difficult right now, but I'll dig into that and figure out what's going on. Jump into more questions. More questions. All right. So, Peak Zebra and Theo, y'all got a whole blog going right here. MHuggins, yes, that spiral example. I feel that kind of changed my perspective because I was getting frustrated reading conversations where it felt like, you know, we just 5 years ago, we had so much pain on Teams from cache management. You'd have these teams, like  like I said, even last year, I had a team take down a full production page for a huge company. Like a company that employs tons and tons of developers. Their whole website went down for a couple days because they couldn't figure out caching, right? So, to see people  it felt a little bit like people throwing the baby out with the bath water. They were like, well, static assets are hard, so let's just go back to caching, right? My initial reaction to that was, like, what are we doing? Why? We're all about to relearn a very hard lesson here. But when you actually look at it from the upward spiral perspective, what's happening is the shortcomings of static assets are real. You can precompile and put things on the edge, and that's great, but you can't build ultra personalized, ultra dynamic experiences without some sort of live thing. You need serverless functions or edge functions or, you know, something that can do that work for you. So that's, you know, and that's why we're seeing, like, you know, even at Netlify where you might say we try to make everything Jamstack, we're heavily invested in serverless functions. And what we call ondemand builders. Where you call a serverless function once and that renders to the edge. We're looking at  we added, like, TTL support so that if you want that serverless function to build once, cache for a certain amount of time, and then rebuild again on the next request, we can do all of those things in a way that allow you to be more dynamic with your static assets. It's not philosophically pure but we don't care about purity. This isn't about dogma. This is about building great experiences for the web. And, you know, edge functions are gonna be another iteration of that. And, to me, that's really important. Like I think we should be focused a lot on building out these great experiences and not so worried on the minutia, but that doesn't mean we can't  that doesn't mean we get to ignore the naming. The naming is how we communicate to each other, and if I say Jamstack and that is an utterly meaningless term or when you hear Jamstack, you think of a very different thing than I'm thinking of, that's a problem. Like we need names for things. But it's also a good demonstration of why people struggle so much with naming, is that once you put a label on something, people start to form different opinions of what that thing  what that label stands for. And they diverge. And so, you know, what, we're 7, 8 years into React's lifespan now and we're still having people argue over whether it's a framework or a library or something else. And, you know, those are important debates to have because words have to have meaning. But they're not important to accomplishing goals. They're not important to building. So there's the communication side where it's important. And then there's the accomplishing goals side where it's not. Right? I don't care if I'm using a library or a framework. What I care about is that I'm building a great experience. And so that's sort of the balance that we have to bring to these discussions. It's just like your opinion, man. No, you're absolutely right. It is. And, you know, I'm gonna stand up here and talk like I know all these things. I'm forming these opinions as I go, you know? I have a conversation today and, like, I change my perspective on this we're going in circles thing based on a conversation with Brian Florence. Prior to that  I change my opinion all the time based on new information. And I think, again, that's that pragmatism. I'm not right. I'm just more right than I was a while ago because I learned new things and I adjusted based on that information. If I try to double down on a static version of right, I'm already done. Like I already lost. But, yeah, strong opinions loosely held, I like that kind of. I don't think they need to be strong opinions. I think they need to be directional opinions. I am confident that what I believe will get me to an outcome that I will be happy with. I don't care if you agree with me because I don't have to. Like if we're on the same team, we need to figure out what we're doing and how much that's gonna impact our work. And if we're, like, fundamentally opposed in our opinions on how to build things properly, that's gonna be a problem. We're gonna have to work through that as a team. But, like, you know, you and me, AJ, it doesn't matter if you want to build things differently. That's an amazing thing to do. Go and do that. We'll compare notes. When you get a better result than me, I'll change my opinion. And I hope when vice versa, you'll be willing to do the same because that's how we get better as an industry. So, yeah, if I'm strongly wrong, it's much easier to notice. That's a good point. What's that internet truism where, like, the best way to get information is to state a slightly incorrect opinion and wait for the internet to correct you? [ Laughter ]

Which is not  I mean, but that sort of points to a whole other thing that I think is really interesting, which is , like, the fear of having an opinion is  it turns into an avoidance of learning and growth. Because if I'm  if I'm willing to say something not in a way that says, like, don't you dare challenge me or I am absolutely correct, but, rather, to say, based on what I'm understanding about this situation, I think this makes sense. Does anybody see any problems with that? That opinion will either move us forward. We'll make a decision and continue on about our day. Or it will get shot down. If it gets shot down, assuming I've got a team that I trust, my team's gonna shoot it down for valid reasons. They're gonna say, oh, well, you're not considering X, Y, and Z, which would mean that's not gonna work. I'm willing to say, oh, you're right. That's a thing I hadn't considered. Thanks for bringing that up. What else do we got? Or if no one else has any ideas, can happily come in and say, yeah, let me change this. My door is popping open. Hold on. I'm having all sorts of strange issues today. Sorry, everybody. Got poltergeists. Got cameras that don't want to cooperate. Like it's bleak out here. [ Laughter ]

This is  this is it. This is the new setup, right? I'm trying to test something out and it's all being weird. I'm very glad that today is a solo stream because this would have been such a nightmare to put a guest through. And thank you all for hanging out with me. This has been a lot of fun. So, we are at about the just under the 25minute mark here, so if you've got questions, if you want to ask about anything, now is the time. I'm also down  I had called this, like, a coding Q&A, too. So if there's  if there's a thing you want to see, I'm not gonna be able to do much, but I can pull up my editor and we can do a little codealong. We can work through some ideas. I use that strategy all the time at work. I've had people tell me it seems unconfident, which has always bugged me. So, this is a safety thing, right? Like it depends on your team. And every team is gonna handle this stuff differently. I'm of a mind that it is critically important to build a team where asking questions and getting people to weigh in is, like, at the core most fundamental, foundational element of a team. Because if my team is afraid to bring me an opinion, I'm doomed. I just, you know, for every person who is afraid to challenge me, I just lost that much talent and value on the team. Because, you know, now I'm relying on my brain. And, like, I think I got a good brain, but I'll tell you what's way better than mine is this whole team that I've got around me. All of them have to feel confident telling me you're wrong and here's why. Or else we're not gonna  we lose all that value. We've got people who just feel like a pair of hands. They're just gonna trudge through because I wasn't willing to compromise or listen to their opinion. And it's really important, I think, to make sure that the framing is done so that that's what's going on. Like there's a difference between I'm gonna ask a question in a way that tries to make sure I'm not responsible for doing the work. There's I'm gonna ask a question so that somebody else has to , like, do this part of my project for me by coming up with the answers to these questions that we have to answer every project. And then there's the I'm, you know, I'm using the limited information I have to make a series of calls or plans or steps, and this is what I think would work. Does anybody, like, what do you feel about that? Are we missing anything? What should we be asking that we're not asking? And I think that if you go into it from that kind of proactive mind state, like, I think I have what I need to make a call. What didn't I consider? That's very different from, like, I don't know, I've been on meetings with people who only ask questions and are kind of unwilling to commit to any outcomes or solutions. And that is also very frustrating. So, you know, it's a balance. Like everything. Jacob. Okay. Let's see. Let's see. Predictions on where the next cycle will go after we go through edge all of the things. Well, let's reason through what went wrong in the last couple of cycles and see if we can get to a prediction that makes sense, right? So, we talked about servers, and the problem was how do you keep servers up when you've got tons and tons of traffic, okay? So we went to CDNs. CDNs let you have tons and tons and tons of traffic, but the tradeoff is flexibility. Edge workers are promising the best of both worlds here. They're saying that you can personalize content at the edge, which is basically in the same CDN nodes, and so that would also distribute the load, which means you're less likely to go down under high traffic. So what are the things that are gonna be painful about that experience? And my assumption is that the big pain points are gonna be developer experience. We're gonna have to learn a lot of mental models. We're all making this stuff up as we go. Cloud Flare basically invented a spec. Dino is doing something similar. They're inventing a cloud spec. We don't know what that's gonna look like. We don't have anybody using it for real things. My guess is we're gonna find some serious dragons in the way this stuff fits together and functions because we just haven't seen practical use cases at scale yet. We haven't seen what developers do when they start using this stuff. So there's gonna be an education gap. There's gonna be a lot of things like that. My sucks is there will be something people pick up as a pattern in workers that is real troublesome. And that trouble is gonna lead to  because I would say it's the same, like, when you talk about static assets, one of the things that people will say is, well, my build gets slow. Okay, you can break a site into as many pieces as you want and only build the pieces that you need to rebuild. And they're like, well, I don't know how to do it. Okay. That's a knowledge gap not a shortcoming of the technology. It's an arrangement thing. And, like, when you look at your tradeoffs, is rebuilding your entire site on a new stack less work than building these components of your site that already have a build system and just breaking it into smaller pieces? And the answer is probably no, but that doesn't matter. People aren't willing to do it. So they moved over to this kind of edge focus, right? And reasonably so. Edge offers up some stuff that you can't do on staticonly assets, like real personalization and that sort of thing. But my guess is that it's gonna  it's gonna expose some new dragons and a lot of new problems that we're gonna have to address. And my guess is that we'll do it by swinging in the opposite direction toward who knows. My big prediction here is I think we're gonna see workers replacing singlepage apps. I think people are gonna try to build no JavaScript frameworks that are as dynamic as Next and stuff that don't serve any clientside JavaScript because the workers promised to solve that problem by letting us execute that stuff at the edge. In a serverlike environment. Which is huge, if true, right? And we'll see how that goes. I'm cautiously optimistic. Like I'm seeing things that are coming out on Cloud Flare Workers and I'm seeing the things that we're working on internally at Netlify with Edge Functions. And it's cool. This is a cool new world. If we get the developer experience right, maybe we get a good, solid few years of run before we spiral the industry again, but who knows. We'll see. I think that's gonna be a  it's gonna be a fun challenge and fun to watch. Let's see here. Let's see. Data security will be fun. Yeah, that's a really good point. Like data is one of those things that is easy to forget about when you're working with static assets because if you  well, actually, I shouldn't even say that because we just saw that whole thing with the government office that, like, preloaded everybody's data, including their Social Security Numbers, and embedded that in the site as output so it could be rehydrated. They didn't prune that data down. So, a huge security leak because people didn't understand how static generation works. We're seeing the same thing with, like, your Remix loaders or static props, any of those things. Whatever you put in there, you can make privileged calls and get this data. If you return that data from get static props or your loader, it goes into a JSON bundle that is on the client that anybody can view. So pruning that stuff down and getting careful about the way that stuff works, I don't know how we automate that, right? Because we've put the power of APIs back into the front end developers' hands, which means they are going to have to learn a little bit about the safety and security of that data. When you get to the edge, you've kind of got the similar but different problem, like serverless functions and edge workers are gonna have access to  we'll see. I think cloud workers get environment variables so you can make privilege calls. And, you know, the serverless functions definitely do. So you can make these calls that are secure, but if you return things wrong or if you're not guarding who can call that or from where, then you open yourself up to potential issues where somebody can request data they're not supposed to have or they can figure out where your serverless functions run and then they can try to spam those or do naughty things and stuff like that. But, yeah, the trick is definitely gonna be on getting that right. Cold start problems is a good  like yes and no, right? Because the problem with cold starts is significantly better than it was even a year ago. And as we're looking around at the way that this technology progresses, like, I suspect it's gonna be similar to the way that Kubernetes has made it  like you don't really think about horizontal scaling of containers as much as you would have needed to before. It kind of just faded away, right? And I think that I suspect we'll see something like, you know, AWS and Azure and Google Cloud introduce multiregion serverless functions and, you know, better ways for keeping them alive. And even now, the cold starts are  they're not in the seconds anymore, most of the time. It's very rarely more than a couple hundred milliseconds. So it's stuff that is less of a factor now than it was before and it will continue to become less and less of a factor. However, the, like, edge workers are a whole different ballpark where it's, like, you know, 10 milliseconds to deal with that kind of stuff. You've got, like, 50millisecond  what is it? There are execution timeouts. You have, like, less than a second to get all this stuff done. And that's to keep it really, really fast by default. It's gonna be pretty wild. I suspect we're gonna see a lot of innovation in this space, you know, partially because edge workers are gonna set a new bar for what serverless functions should feel like because they're very, very different technically, but conceptively, they feel the same. Well, I am writing a piece of dynamic code that is going to execute when somebody calls this page. Why aren't my serverless functions as fast as my edge workers'? And I think we're going to see the industry realize, oh, well, I guess that gets prioritized now. But let's see. There really isn't a good security story. Yeah, the security story, like, the security story right now is it's good. It's really good when you're only static, right? Because you build once. You can literally not have references to any of your back ends and your data and all that stuff. And suddenly your backend is extraordinarily secure because no one even knows it exists. Because you're looking at the rendered site, there are no calls being made to that backend. When you get into serverless functions, still pretty secure as long as you're careful about access control. You can do that by requiring, you know, same site. Don't allow cores. That kind of thing. And, you know, if you just make sure you don't ever return an environment variable, which why would you, you can make sure that your serverless functions stay reasonably safe and secure. When you start getting into the SSR stuff, this really dynamic stuff, now you're looking at user input. There are challenges. There are things that get tricky. So it really kind of comes down to how much are you trying to do and how does that all fit together? And also how sensitive is the data, right? Like if I  if I get access to a list of, you know, who booped a Corgi's nose on a demo app, that's very different than getting a list of people's financial data and Social Security Numbers. And so it's  you kind of got to weigh the security implications of what's going on and, you know, like never be light on security, but also sometimes, you know, a user ID to count is not really important. Like you could probably keep that  like, you know, your Wordle stats are stored in  I think in local storage. Cool. Who cares? I don't care if you know about how well I do on Wordle. I just care about as long as it's not  it doesn't give you my email. My Social. My credit card number. Anything like that. Let's see here. Yeah, I mean, yeah, when Ryan's talking about GDPR and the education sector, that's  it keeps people from moving to new stacks, right? You'll see  I remember when I was at IBM, we would look at a new vendor and there were questions if you didn't answer yes to this question, it was a hard no. Couldn't use your tool. And I think that's increasingly true for companies that are growing. Like, you know, we're starting to see that at Netlify for certain tools. Like there's an audit. We get to say we want to use a tool and the audit has to run. If everything on that audit doesn't clear they say, well, you can't use this tool, but look into the alternatives that pass the audit. That's a critical safety measure that we have to take to make sure we don't expose ourselves to nonsense. And so it's gonna become more important for us to be aware of what that stuff is because, like, if we want you to use Netlify or whatever company we work for as a tool in your chain, then we need to answer yes to all of those audit questions so that when you get asked those audit questions about whether or not somebody can use your tool, we're not the reason that you have to say no. You're in control of that on your own. So, you know, those are big questions that I think a lot of the platform companies, if they're not thinking about it, they should be. And it's definitely something that we're paying a lot of attention to at Netlify and trying to get right. I know for a fact that the big clouds think a lot about this stuff. And that's, you know, some of the reason for the more Byzantine bits of how access and permissions work on AWS, is because they're fulfilling those needs, and, you know, I hope it doesn't have to be that complicated, but I can definitely understand why it is that complicated. All right. I got time for one more question. Anybody got anything for me? I'm gonna dance while I wait. It's less hot in my office now. This is nice. I bet my camera would work but I'm not gonna risk it. [ Laughter ]

VR  will VR change things and how? I don't know. I'm  I am not a VR person. At all. I don't  like I've used it maybe once ever. And it's not particularly interesting to me. I am way more interested in augmented reality. I think that those types of applications are really, really fascinating, and I can see things like, you know, like, if we can make them more fashionable, which I know we can. Things like Google Glass where you get a little bit of a headsup display. Or if I take my phone and go to Google Maps and turn on the AR view pointed on the street and draw my map on the sidewalk so I know exactly where to walk. That sort of stuff is really, really cool. I have a feeling that we're gonna see a huge amount of AR work its way into life. I mean, we already have, right? All the social apps have AR. I'm  who knows if and when we'll ever get to the point where people are, like, really existing significantly inside VR headsets. I have a hard time believing it, but, look, don't take tech predictions from me. I am, like, the biggest gear curmudgeon. I remember  I was like 14 years old when text messaging came out, and I remember seeing it and, like, Carson Daly was pushing it really hard on  what was it called? TRL. I was just ranting to my friends. This is the stupidest idea. Why would anyone ever want to write out a text when you have a device in your hand that lets you call them and get an answer instantly? And I was so wrong. [ Laughter ]

I mean, I don't know if I've used my phone as a phone  I don't even know if my phone is a phone. Do they still do phone stuff? It's a text box. So who knows. Maybe my prediction of VR isn't going to catch on is a really strong indicator that it will. But real bullish on AR. For sure. Best dog breed other than Corgi? French Bulldog. I honestly  so I don't have a dog now. I really want a dog. But I don't want dog hair all over my house. So I wouldn't get a Corgi for that reason. They shed so much. Like they're just little fur balls. But a French Bulldog, Frenchies, they don't shed that much and they look really cool when you dress them up in little outfits. And, you know, I think that me and my Frenchy could be fashion icons together. So, yeah, French Bulldog. [ Laughter ]

AJ, your phone is literally not working and it is better. Yeah, I mean, I agree. I had my phone on WiFionly for a while when I was out of the country, and I didn't have Project Fi. So I couldn't use my phone for texting or calls. Could only use it when it was hooked up to WiFi. I loved it. It was so great. I love being disconnected from stuff. Portuguese Water Dog. Wait, are those the giant ones? I just spelled that wrong. Yes, these are the giants, right? How big are these? Oh, man, that's a cute dog. Holy crap! Wait, these aren't giants. These are  are they little? Well, do these dogs shed? Portuguese water dogs are mediumsized dogs. 35 to 60 pounds. Okay. That makes sense. These dogs have no undercoat and do not shed. Oh, no. Hold on. We got to do the side by side here. Here's images. Then we're gonna look at a French Bulldog. All right. So let's take this one. And then let's take this one. And y'all, look at these  look at them. Look at French Bulldogs. Is everybody looking at French Bulldogs? Because this is, like, this is really important stuff. Also, if you put a French Bulldog  just type  watch what happens. They look so freaking cool in hoodies! Okay. You can put a French Bulldog in a Hoodie and it looks like a total badass. Look at this one. Look at that. That is a cool dog. So, anyways, this. Anyone? No, look, put it on a French Bulldog. Yeah. You don't put outfits on Portuguese Water Dogs. And so I do think that changes my math a little bit. Frenchies shed small hairs. I can live with small hairs. I'm okay with that. They're too smart for that nonsense. Yeah, that's probably fair. I don't know, man, I kind of like  I kind of want my dog to be low energy and a dufus like me. [ Laughter ]

Oh, God. Like a poodle. Yeah, okay. All right. This all makes sense. Okay. Well, you know, we'll see. Maybe I'm gonna end up in one of those weak moments where I accidentally adopt, like, six dogs and just have to do a side by side comparison. All right, y'all. So with that, I think we're gonna call this one a success. Thank you all so much for hanging out today. I had a blast. I hope you learned something. If not, I appreciate you sticking through it anyways. Let's do another quick shoutout. We've had Jordan here today having to just handle my monologue. Jordan, you are a hero for putting up with that. So, thank you. Jordan's here from White Coat Captioning. And that is made possible through the support of our sponsors, Netlify, Nx, and Backlight, all pitching in to make this show a little bit better and helping me do a little bit more with it. So, thank you all so much for hanging out today. We're gonna go find somebody to raid. You got any opinions? I can see  let's see, Michael Jolly's live, Bald Bearded Builder. We can go raid the Twilio. Ooh, Ben's live. Is Ben actually live? Starts in 3 minutes, 8 seconds. All right, y'all, I'm gonna send you over to Ben. Wait it out. Hang out. Ben is amazing if you haven't watched. He was just on the show last week, and you can see that here. And while you're checking out things on the site, make sure you go check out the schedule. We got all sorts of good things happening on there. And you can see, like, we got David coming on later this week. This is gonna be a lot of fun if you've ever work with State Machines or seen them. We're gonna create them visually using David's work on a tool called Stately right now. Really, really cool stuff. We've got lots and lots of amazing people coming. And we're gonna go say hi to Ben, and we will see you next time, y'all. Thanks for hanging out.