Kate: Welcome to PodRocket, I'm Kate. I'm the producer of PodRocket. And with me is Swizec Teller, software engineer, and many other things. Hello Swizec, how are you? Swizec Teller: Hey, I'm good. How are you today? Kate: Good. I was just listening to the React Podcast with Chantastic from 2019. Swizec Teller: Yeah, that was fun. Kate: You guys were joking about... Swizec Teller: Long time ago. Kate: Yeah, right. Seems forever ago. You guys were joking about how it's easy to know people in the web development Twitterscape. I feel like I know you, but yeah, it's really nice to meet you, really good to have you on. Swizec Teller: Yeah, definitely. Kate: Yeah. I was just going to say, maybe introduce yourself. I am aware of what you're working on, but maybe our audience isn't up to speed. Swizec Teller: Yeah, that's a good point. Yes. Hey, I'm Swiz. I'm currently senior software engineer at Tia, which is a women's healthcare company. Other than that, I work on a lot of info product stuff, I'm trying to help engineers be better software engineers. The main space I'm exploring currently is kind of the differences between what makes somebody a mid-level or a senior engineer, especially the differences between good engineers and great engineers, because I think there's a lot there that we miss where we kind of get... Swizec Teller: You get to that point in your career three or four years in and then suddenly, you kind of plateau and it's like, "Okay. What now?" And the joke that people often say is, a junior engineer is anyone from zero to two years, a mid-level is two to maybe three or four years, and then you're a senior engineer for the next 30 years of your career, which is weird. Swizec Teller: I've been thinking about that kind of thing a lot lately. And on a more technical side, I've been exploring the Jamstack a lot and serverless. Jamstack, serverless, I've been dealing with React for a long time now and I have a couple courses on that out. That sort of thing. I'm just trying to explore what I think are interesting new technologies, and avoid NFTs. Kate: Right. Yeah, that's awesome. No, that's super cool. Just to dig in a little bit, I guess... I think that's super interesting. You're a senior engineer for a long time. There's so many technologies out there, what does it mean to be a senior engineer in 2021? Swizec Teller: I think there's two different ways that people become senior engineers, or there's two different types of senior engineers, I think. One are the people who, you just join a company, especially a fast-growing company, and if you stick around for a couple of years, you get the senior engineer title. Everyone gets that. I've now heard stories of even people, two years after a boot camp, and they get lead engineer title and it's like, "Hey, that seems a little early." Swizec Teller: But then you also have the true senior engineers, or what I think are true senior engineers. The people who have the battle scars and the experience to actually support the title that they have. And that usually happens later, but it's not specifically just tied to the time you've spent working. It's more about the depth and breadth of experience that you have. Kate: Yeah. Kind of along that line, what does it look like to break in as an engineer? As a junior engineer, what does that look like versus a senior engineer? Swizec Teller: Yeah. I think right now, there's really weird things happening in the market right now where for senior engineers and experienced people, it's a red-hot, flaming hot market right now. People are basically fighting over who can hire who. The craziest thing that's happened recently is, a recruiter reached out to me, and in their first initial email, they were already like, "Oh yeah. By the way, we do compensation between 400 and 500K." It's just like in the first email. Kate: Wow. Swizec Teller: "Please respond to us. Just have a pulse." And then you have the other side of the engineering market, which is more juniors or people trying to get into the industry. And from what I've heard, it's the hardest it's ever been. I think it used to be a lot easier. I don't know exactly why that's happening. I think a big part of it is the pandemic and the remote culture where everyone is... Because everyone is remote, I think companies are kind of afraid of what it's going to look like to train people and to build them up into full software engineers, so they're kind of wary about hiring juniors. Swizec Teller: If you're a junior right now, as a piece of advice, what I've seen doesn't work these days is trying to go for your dream company straight out of school or straight after switching careers, because they have a lot of competition, and they have their pick of the litter, not as an engineer, but my girlfriend said that when she was applying to jobs at very big companies, she's at VISA right now, she said over 2 or 3,000 people applied for her position. And out of those 3,000, I think 10 got an interview. Swizec Teller: From that perspective, maybe going straight to a big company is not a good bet. Not that they don't have the jobs, they definitely have the jobs. And especially for junior engineers, it's kind of funny because going to a big company will probably give you a smoother, more streamlined training experience, because they have the jobs, they have the processes built in where they know how to take somebody from junior to senior, and they have all of the internal boot camps and programs and so on, but it's so much harder to get in because everyone is trying to get in. Swizec Teller: Whereas if you go for a smaller company, a lot of those are actually super desperate to hire engineers as well, and they would love to hire more junior or mid-level people partially because they can't afford to compete with the big guys, a company that's making 20, 30 million dollars a year. They're a good company. It's a great, successful company. If that was a restaurant, they would be on the cover of magazines like, "Oh my God. They're making so much money." Swizec Teller: And they do good tech, they do good work, and they're amazing, but nobody's applying to their jobs and they're desperate to find people who are interested in jumping in and learning stuff. And at least for me personally, that was my approach to getting into the industry. It was going to these smaller companies where you don't have a training program when you get in, but you get exposed to a huge swath of experiences and you can grow a lot faster because you become their person. They're like, "Oh my God. We got somebody that can do really cool stuff. Let's just give them everything. Let's ask them to do everything," and you get to learn really quickly, but it is a kind of... Swizec Teller: When you're learning that way, it can be a little bit more challenging or more daunting because you don't have somebody holding your hand, but you do give a lot more impact. And then with more impact also comes a much better résumé for your next job. Kate: Yeah. Kind of talking about junior engineer, I guess, what skill specifically would you emphasize on honing, I guess, that could be technology or even non-technical skills that are good as a junior developer? Swizec Teller: Yeah. When companies hire people, they usually hire juniors as, "This is somebody who has a lot of potential, but they're not there yet. We're looking for talent, we're looking for potential, we're looking for somebody that can be trained to become really amazing." When you're looking at mid-level engineers, you're usually looking for somebody who can hold their own, who has a specialty in some sort of stack, whether it's your stack or some other stack, but they have a track record of solving problems, delivering solutions, and writing code. Swizec Teller: When you're looking for somebody senior, it's usually more on, "Can this person mentor others? Do they have a really strong technical specialty? Are they really strong technically in at least something? Can they also mentor, and how fast they can pick up, and are they an expert in whatever it is, their field?" There's a famous TED talk from a long time ago about T-shaped people, and I think that's what they're most looking for or they want. Especially mids and seniors, you want somebody who has a broad experience and a strong specialty, or maybe even multiple specialties because they have been in the industry for so long, so they're almost like a cone-shaped person. Kate: Yeah. Swizec Teller: But with juniors, I think people are most looking for that potential and the energy, the potential, and whatever you can do to showcase that, because nobody expects a junior to come in and take a project and just do it. You're expected that, "We're going to help you. We're going to work with you. We're going to give you smaller projects first and then bigger and see how fast you progress." Especially in interviews, the most important part for a junior is to really show that you're not afraid to ask questions, you're not afraid to maybe even ask stupid questions, because those are often the best questions. And that willingness to learn. Swizec Teller: An analogy I heard recently is that a really solid junior is somebody who is almost like a dry sponge. If you add a little bit of water, they just soak everything up and they're really excited to learn stuff. Kate: Yeah. Swizec Teller: I don't know if that makes sense. It's hard to explain these things, but a lot of it comes down to when you talk to somebody, you can kind of feel whether they have that mindset of growing quickly or they don't. And if you don't have that mindset, it's going to be really hard to be a junior. And if you don't have the mindset of learning fast and trying to grow, it's going to be almost impossible to get into the industry. But if you do have that mindset, then it's more about showing it and really showcasing that, "Hey, I am here to learn. I'm looking for an opportunity to show how amazing I can be, but I know that I'm not there yet." Kate: Yeah. That makes perfect sense. Kind of the other side, what advice would you have for anyone hiring right now, or even managers who are... We always talk about this on this podcast, but technology is changing so quickly. How do you know what tools to pick? How do you know what... I mean, everything. There's always new libraries, there's always the newest trend. What advice do you have for someone who is hiring or a manager who may be isn't on the front lines of all that stuff every day? Swizec Teller: It's a really good question. There's a couple of different philosophies when it comes to choosing libraries or technical stacks. I would always try to choose... Basically, it kind of depends on how long-lived you believe the project to be. If you're working on something that's going to live for the next couple of days or a couple of months, it almost doesn't matter what you choose, because whatever, just to solve the problem and move on. Swizec Teller: But if you're looking to, "What can we bet our entire company on?" Well, how long do you think your company is going to last? And how easy is it to adapt later? One of the things that people often forget is that a lot of what we do is just code. You can always throw it away and change it later. A lot of these decisions aren't as make-or-break as people like to think they are. It's often just, it doesn't really matter, we can just change it later. Swizec Teller: I would base the answer a lot on how easy it is to change later. Changing what your marketing page for Black Friday is built in is super easy. You just build it in a different thing next year, because you're going to have a different design anyway, and nobody really cares. It only needs to live for a week or two. But your payment architecture or your checkout cart, that's a little bit more critical to the whole company, so maybe bet on something that's been around for a while. Swizec Teller: The Lindy effect is really useful here. The Lindy effect is a mathematical principle that says that anything that's alive is roughly at the half-life of its lifespan. I think I'm explaining that poorly, but we've had the web for 20, 30 years now, so you can reasonably expect that it's going to be the thing for the next 30 years or so. We've had React as a library. It has been around... I think it's been popular for maybe six, seven years now. You can reasonably expect that it's going to survive another six, seven years before you have to change to something else. Swizec Teller: Is your company still going to be around in six, seven years? Hope so. But if you look at the number of dead links on my blog, because I've been writing for 10 years, it's pretty sad. There's a lot of things that don't survive five years. No, seriously. I think five years is actually... Statistically, I think 90% of companies fail within their first five years. If you're starting a new company, just don't worry about it. Pick whatever you're most familiar with and lets you get to market the fastest. If you're choosing a new product for Google, you're probably going to have to support that product for the next 20 years, so choose a little more wisely. But if you're Google, you probably have plenty of smart people who can help you make that choice. Kate: Yeah. Yeah. No, totally. Okay. I want to talk about the Serverless Handbook for Frontend Engineers, the book you wrote. Yeah. Tell our audience a little bit about that. Swizec Teller: Yeah. The Serverless Handbook is, it's basically the book I wanted to have when I started going into serverless. I do have some backend experience, but I'm mostly have been a frontend engineer for the last several years. And serverless kind of blew my mind because it makes all of the annoying parts of doing backend development really easy. They're really easy for the simple things and it kind of depends on which provider you pick, but all of the annoying fiddly details that I always hated dealing with, like keeping servers alive or dealing with processes and dev ops and all of that kind of stuff just goes away and you let somebody else handle it for relatively cheap. Swizec Teller: Serverless, I think, is really an inflection point in how we build web apps and how we work on the web. I think serverless represents kind of an inflection point with moving away from dealing with the details of your execution environment and your code and focusing just on the business logic of what you're actually trying to build. The quickest way to grok serverless, for me at least, was, you write a JavaScript function, or in whatever language you like. I like JavaScript and TypeScript. Swizec Teller: You write a JavaScript function and it just runs on the web. It gets a URL, you can call it, that URL calls your function, and whatever response the function returns is the response you get from the server, and that's all you have to deal with. The Serverless Handbook kind of grew out of some of my experiences around building a bunch of different things with serverless and exploring how it works, and then expanding that to some of the adjacent topics of, well, when your backend starts growing, what do you do when you need to save data somewhere, when you need to deal with persistence, what happens when you have to think about reliability and resilience, and how I think you can get there with using the serverless... Swizec Teller: Not metaphor. Serverless paradigm of backend development, where everything is kind of on-demand and more event-based, and there's a lot of interesting things that come out of that. Serverless Handbook is meant as an introduction to the concepts and ideas behind serverless. It's specifically not a tutorial, so it's meant more as giving you a way how to think about serverless, how to understand what's going on, and really grok how to do modern backend development, because then once you know the ideas and once you understand the concepts behind it, it's, in my experience, pretty easy to switch between specific technologies, because you know how it works, so you know what to expect, what to look for, and then you can either read the documentation or find a specific tutorial for what exactly you're working on. Kate: Yeah, awesome. I mean, you talk about it, so it's the modern backend, which we cover a lot in this podcast as well. Kind of how the role of the frontend developers changed over time and there's a lot more responsibility to take on. From your experience, what have you seen in that space? Starting as a frontend developer to now, what has kind of been the change? Swizec Teller: Yeah. The whole concept of what is and isn't a frontend developer is getting kind of murky these days. I've heard some people say, "Well, we're not really frontend developers because it's weird to describe ourselves as half of something." Kate: Yeah. Swizec Teller: Especially if you look at modern web apps that have really rich experiences, it's a lot more like building an entire client, or especially modern frontend development or modern web app development is much closer to building a desktop app or a mobile app with all of the complexities and intricacies of everything that goes into the AI. You get this frontend where you have the actual UI of what things looks like, HTML plus CSS, some JavaScript, then you have almost like the backend of the frontend, which is all of the logic and the machinery and state machines, and there is a whole topic there that you can probably talk about for ages. Swizec Teller: And then you have the modern backend which deals with... You have a frontend of the backend, which deals with how to talk to a database, giving you some API support so you can have states that persist across different web app reloads or across different sessions, and then you have the very deep backend, which is machine learning and data pipelines, and really a whole world of weird esoteric stuff that I've never gotten into. Swizec Teller: And what people consider frontend and backend kind of depends on who you ask. If you talk to somebody who is really into machine learning and AI, they're going to say, "Yeah. Anything that even remotely talks to the user is the frontend. Of course my Postgres database is the frontend." But if you ask somebody who is more of a designer who knows CSS and some HTML, they're going to be like, "No. Postgres is the backend. It runs on the server." Swizec Teller: And then it gets even weirder when you take something like React server components or with Next.js where you have server-side rendering, where you have the frontend, the actual UI, that first runs on the server and renders there, which is kind of traditionally was the backend, and then on the frontend becomes a web app via hydration and becomes interactive. It gets really murky. And I think serverless is kind of a good middle ground there because serverless is, it is the backend, but it's also very particularly useful as an API. Swizec Teller: It's like, this is the interface to your data, the interface to your persistent user state, to your persistent data modeling. Basically, it's almost like, depending on how you design it, you can almost think of it as a thin wrapper on your database, and then the web app, the actual UI portion, is where all of the interesting complexity lives. Kate: Yeah. Yeah. We talk about this a lot on this podcast. We actually talked with Chris Coyier about it, and he wrote the blog post. It's very well known. Two frontend engineers walk into a bar, and they had nothing to say to each other. Yeah. It's just really interesting how all that changes so quickly. Swizec Teller: Yeah. Yeah. I think what's really cool, what excites me personally about serverless is that because we've... I say "we", but we, as an industry, have found ways to automate a lot of the gnarly parts of server-side development, so instead of saying backend, I'm going to say server-side development, because we've automated a lot of the gnarly parts. You can now have anyone who knows JavaScript can just write a JavaScript function, you can do that. You can run it either on the frontend or you can run it either in the browser or you can run it on the server. The JavaScript function itself doesn't really care. That empowers you to do both parts. Kate: And then I'm really curious about the Senior Mindset series, your series of essays. Yeah. Tell me about that. Swizec Teller: Yeah. The Senior Mindset essay series kind of grew out of just my experiences and learnings over the years. I've been blogging for a while and I usually write a lot of technical stuff, but then I started writing more and more about my career experiences and just things that I've learned on the soft side. Swizec Teller: And then as I started interviewing others more and more, I started realizing that there was a big difference between people who come to interviews and say, "I'm assuming you're a software engineer," and you ask them about their experiences or you ask them those really hard, "Tell me about a time when you X" questions, and they just don't have any answers, or you say, "Okay. So, you've built this technology, and it was really cool. Why did you build it?" And they're like, "I don't know. My boss told me to." "Okay. Your boss told you to build this, but did you push back? Did you ask them why this needs to be built?" "No, they just told me to do it, so I did it." Swizec Teller: That's not a senior engineer. A senior engineer needs to be somebody who can be a real partner, especially at a startup where every decision that you make as an engineer can really impact the trajectory of the whole company, because the difference between, "We have a problem and we need to solve it. Here's my idea for how to do it," and if you, as engineer, just go off and do it because they asked you to, but it turns out that there's some technical gotcha or some weird thing that you run into, and suddenly it takes a week to solve that problem, well, that's a week that you could've spent doing something much more important. Swizec Teller: I find that a lot of the times when PMs ask me, I'm going to say stupid questions, but they're usually really smart questions, but from an engineering perspective, it's like, "That's a dumb idea. Why are you asking me to do that?" And if you push back and you say, "No, that's going to take a really long time. Are you certain we need to do it exactly that way?" They're going to be like, "Oh my God. No, I had no idea it was that complicated. Totally not worth it in that case. Let's do this other thing that actually makes money." Swizec Teller: And that's where the mindset of a senior engineer really comes into play. When you have a startup or a company that's trying to hit a certain trajectory and every little decision matters, how you make those decisions is really important. And a lot of senior engineers don't have that ownership mindset of, "I need to really be a partner to the business. I'm here as the expert. They don't know everything. I need to help them know it. I need to help them make better decisions." Swizec Teller: Whereas a lot of people, especially folks who just have the title, senior software engineer, because they've been there for a certain number of years, they can be almost people-pleasy or one expression I've heard is yes-man, but I don't like it because it's kind of gendered, where they just do whatever they're told, and it's like, that's not really how a software engineer, in my opinion, should behave. You should be a partner, you should own what you're building and really think critically about everything, because that way, the business side can rely on you and they can rely on you to keep them in check as much you rely on them to keep you in check. Swizec Teller: And obviously, that requires some modernity or it requires a certain kind of company as well. You can't do that everywhere. If the company thinks of you as a feature factory, you're not going to have a good time with that kind of attitude. There's a lot of companies who would kill for people like that and can't find anyone. That's kind of what the Senior Mindset series came out of. I was looking at those experiences and I realized, wait, I've written a lot about this and about this mindset, and the mindset has been really helpful in my own career in advancing through... Advancing through the ranks sounds weird, but getting through my career and to wherever I am now. It was really helpful to think like this, so I decided to collect all of those essays and make sort of an evergreen newsletter. And so far, people are loving it. It's probably the most positively-feedbacked thing I have ever produced. Kate: That's great. Yeah, that's awesome. I'm trying to remember on your blog. I saw you'd share how many newsletters you sent, how many blogs you wrote in a year, how many conference talks. Swizec Teller: Oh yeah. Yeah. Kate: And it was a lot. One, what does your newsletter look like? Tell me a little bit about that. But then also, how do you find time to do all these things? Swizec Teller: I've been blogging for a long time, and I think the official count on my blog is around 15 or 1,600 articles over the last maybe 10 years, 10, 12 years. It adds up. It's not like I woke up one day and churned out hundreds of articles. I like to use the analogy that Amy Hoy uses called Stacking the Bricks. You just show up every day and you do a little, and then when you look back on it, "Oh wow! I have created so much." But on a daily basis, it doesn't feel like that much. Swizec Teller: And a big part of why I blog is because it helps me think. I like to use it as a tool for learning, as a tool for thinking. A friend of mine, Philip Morgan, who does position, who has a really good book on positioning and how to present yourself as an expert. He once said that he writes every day because he thinks every day, and I really love that. I don't write every day, even though I do think every day, just because I physically run out of time, because I like to make my newsletters and my blog a little bit more than just like Twitter. Swizec Teller: Twitter is where I shitpost every day and I develop my ideas, but then when I think I have something really meaty, I try to put it in an article. My newsletter right now is two to three emails per week that are more like blog posts. Some of them are super fleshed out and work as long-term essays, as evergreen essays. Some of them are more, "Hey, I found this really cool technical thing, and I figured it out, and I thought you might want to know as well." Swizec Teller: And some of them are more on the career side of things. But I try to keep myself to at least two a week because that helps me come up with more ideas, and it helps me notice what in my life have been really useful lessons that might be helpful to others. Because without that deadline, they kind of just slip away and you forget about them, but if you have that deadline, you're like, "Oh wait. I did learn this really cool thing yesterday." I can write about it, and then because you write about it, you understand it better and you remember it for longer. Swizec Teller: And the best part is when we get a story at work that's similar to something I wrote about a year ago or two years ago, I just paste it in the comments and it's like, "Hey, here's a roadmap of how we can solve this so we don't have to figure it out from scratch," because I have done something similar in the past. Kate: Yeah, totally. Yeah. We talk about this a lot on this podcast as well. We just had James Quick on actually, and he was talking about if he works on something that work, he goes through it, understands it, and then writes about it, and then teaches other people how to do it, and that's a big part of his workflow, which is really common in this community which is great. Swizec Teller: Yeah, I love that. I think explaining things to others is probably the best hack to make sure you've understood it and you have actually learned it. Kate: Yeah, for sure. Swizec Teller: I forgot who it was but there's a really good quote that says, "If you can't explain it simply, you probably just don't understand it well enough." Kate: Yeah. I've heard that too, I think. Yeah. Yeah. Another thing you've worked on is React, D3 for developers. It's your course. And you gave a few talks on visualization, that sort of stuff. Yeah. Can you tell us a little bit about that as well? Swizec Teller: Yeah. React for data viz is probably my most financially successful course I've done, and it focuses on how to work with React and D3 together, because they have slightly different ideas of how you should work with the DOM and how things should fit together. It's just different enough that it's really annoying to figure out. And over the years that I've worked on this course, I've developed a bunch of different techniques for how to do it well, how to do it scalably that have been used by a bunch of different companies. Swizec Teller: I think probably my best success in this area is that I've had people from Facebook come to my React and D3 workshops to learn how to use React with D3 together, which was just cool because I'm sure they have plenty of people at Facebook who can teach you React. Yeah. It's focused on the technical aspect of building data visualizations in React with a bit of side exploration of just D3 itself, because D3 is like the jQuery world of web-based data visualizations. Swizec Teller: It's used by New York Times, I think The Economist uses it. Basically any data visualization that you've seen on the web most likely use D3 somewhere in its stack. And React, as the currently most popular frontend framework, just seems like a good fit. And in my experience, it solves a lot of the kind of sharp edges of D3, are nicer when you put it together with React, so that's what the course focuses on. It talks also about D3 itself so that you can understand random examples that you find online, and you can translate them to use in React. Swizec Teller: And there's a couple things in there about just the aspects of data visualization, what makes it good, and how to think about data, because I just think that's super interesting. You get a pile of data, how do you decide what's actually useful here and what's interesting. But I'm not a data scientist, so I didn't dive too deep into that topic. It's more like, I've been around data for a while doing data visualizations and playing around, so I've picked up stuff by osmosis and then try to tell others about it. Kate: Yeah, that's great. Yeah, I guess I'm curious. It sounds like a lot of the content you create, courses and newsletters, comes from stuff you've experienced, I'm assuming at your day job. I guess where you're kind of getting your information and what kind of content are you consuming, and where you're getting inspiration from these courses. Swizec Teller: Yeah. My favorite way to develop new content is, there's something new myself that I think is interesting, and then try to share an opinion or an insight. I really try to focus on sharing things that are new at least to me, or where I feel like I've figured out something that not enough other people are talking about yet, because nobody really cares about the 10,000 to-do tutorial in React. But when I work with these things and because I use them in my day-to-day life, sometimes you discover something new and you're like, "Oh hey, this is a new angle that I don't think people have discovered, and I think it could really help everyone and it could improve how you build stuff, so I'm going to write about it." Swizec Teller: And then if people respond, if people like it, I then try to dive deeper into specific topics. A lot of it is random exploration. In terms of my own content, I spend way too much time on Twitter, but the interesting thing about Twitter is that most of it is a waste of time, but sometimes you really get an insight into, "Oh shit, that's where the industry is going. That's where everyone is going to be in six months or in a year." It's really cool, sometimes you can see somebody developing ideas and talking about something. And then six months later, it's the same thing as a keynote talk at a major conference and shifts the entire industry in that direction. Swizec Teller: Twitter is great from that perspective, but I try to also read more and more books; buying technical books or business books and reading there, because I feel like some of the deepest insights I've gotten come from somebody who has been studying an area for the last 10 or 20 years of their life, and then writes a book, and that book is usually amazing. Swizec Teller: Very often, you notice those authors write a hit bestseller with amazing insights, and then fast follow with a new book in a year or two, and that book is usually, "Wait, you're just saying the same things again, but in a slightly different context," and it's just way less interesting. That's what I try to focus on; a bit of the continuous flow of the latest stuff, but more on the really big things where somebody has spent the time, spent the effort, and really poured, maybe not heart and soul, but their deepest insights, their most interesting insights into something that is probably going to stand the test of time for the next several years. Kate: Awesome. Okay. I guess for the future, it's crazy to believe 2021 is almost over, but what are you looking forward to in 2022? Swizec Teller: Yeah. From a technological perspective, I think we're going to continue the inflection point in how web apps are built so that it's going to be more and more like full apps with API backends. I think the edge infrastructure approach to serverless is getting really interesting. This is the bleeding edge right now, so it's going to take the next 10 years for all of the technology companies to start switching over, which is really exciting for me. Swizec Teller: Web 3.0 looks interesting. I still think it's the same as Web 1.0 and Web 2.0, but we'll see. Maybe crypto has finally found something to be useful for, and not just a kind of scam. Those are fighting words, but we'll see. We'll see what happens there. Kate: Yeah. Awesome. Is there anything you'd like to promote or anything you're working on? Swizec Teller: Yeah. Obviously, my Serverless Handbook is at serverlesshandbook.dev. I hope everyone who is listening to this gets a million copies and spreads it around because I think it looks really cool. I think it's a great book, but I'm obviously biased. And if you're interested in more Senior Mindset stuff, seniormindset.com is where you can go and get my Senior Mindset series. And what I'm focusing on right now is, the day job startup is rocket-shipping, so that's taking more and more of my energy, but I'm also exploring this Senior Mindset stuff because I really think there is a really good book or course hiding in there, and that's probably going to be my next one or two years of exploration, and that's going to be my next big thing that comes out, but I'm still figuring it out. Kate: Awesome. Well, I look forward to seeing it when it comes out. Yeah. Everyone, go buy a million copies of [Serverless 00:41:42] and give it to your friends. Awesome. We'll include all the links to everything in the show notes. Well, thank you so much for coming on, and it's been a pleasure. We'll see you around. Swizec Teller: Yeah. Thank you for having me. Brian: Thanks for listening to PodRocket. Find us @PodRocketpod on Twitter, or you could always email me, even though that's not a popular option. It's brian@logrocket.