บทถอดความฉบับเต็มของ Episode #135: Serverless for Frontend Engineers with Swizec Teller

stuff. But for web apps on modern computers, JavaScript is amazing. And what's really nice about it is that it's approachable. It's easy. It's relatively easy to get started, especially if you avoid all of the really weird, like prototype inheritance and all of the stuff that as an ecosystem I feel like we've kind of decided to wink, wink at each other and just not use any of that stuff anymore. So if you write, if you stick to the good parts of jobs, It's a really reasonable language. That's fairly easy to use, quick to understand. I think it's become kind of the lingua franca of the web. Like I've seen people who write a lot of articles say, 'Yeah, even if I'm writing about computer science topics or I'm writing some high-level software engineering stuff, I just use JavaScript for my examples because that way everyone can understand it. And I don't have to explain this weird Haskell syntax, even though I'm actually talking about something I would have implemented in Haskell. It's easier to just present it as JavaScript, because it works and it's fine. All of these advances, I feel like we have a lot of engineers coming into the field. They start with JavaScript and a lot of the times, they can feel stuck because they hear all of these gray beards talk about, 'Ah, JavaScript is no good. It's a weird scripting language. This sucks.' And it's like, 'Yeah, sure. But to do it, you last looked at it 10 years ago.' It was a very different language back then and what I want to like, if somebody is listening to this and if there's one thing they want to take away from it is that: JavaScript is a great language and anyone who can code JavaScript can pick up any other language and probably doesn't even have to pick up another language because JavaScript will get them there anyway. And you know, if you feel like computers, aren't fast enough, just wait another two or three years and they'll get there. Jeremy: Yeah, no, I mean, I totally agree. And actually that's one of the things where, the ability, I mean, JavaScript has come so far. I mean, I started writing JavaScript, like right after it came out, I think like 1996 or 5 or something like that, whenever it was. And so it was, and again, it was very much so focused on the front end and it was a lot about interacting with the Dom and things like that. And as things have progressed and certainly with node.js coming out, you know, the basic of what you can do with any programming language you can do with JavaScript now. And as you said, with ES6 and things like, you know, even things like spread operators and de-structuring variables and things like that. If you, if you look at them, they're pretty intuitive. I mean, it's not overly complex. And I remember my first programming class, which was for Java, and it was, you know, public static void main. And everything you do, everything has to be within classes and you'v got to do all this kind of stuff. And then I came across JavaScript. I'm like, wait

a minute, you can just write a line of code that does something and it doesn't have to be wrapped in classes and all this inheritance and prototypes and all like it'll just work? I mean, that was one of the things where it really made it very, very fast, I think for me to pick up a lot of what you could do with JavaScript. And then over the years, of course you apply computer science and the knowledge of other things and data structures and all that kind of stuff. And of course it can get more complex as you go down that path. But I think that's an interesting thing where if you're writing react, maybe your favorite, you know, maybe your favorite was Ember JS, which luckily went out of favor. Um, maybe you're a, you know, a prototype JS or a, you know, what's the other one? The J query, right? I mean, I think that's still around. But if you're writing something like eact or view or you're using next JS or any of those things, you're writing a lot of JavaScript. And if you can do that, those skills translate really, really well to node.js. And actually, this is funny. We were talking with, we talked to Tomasz Lakomy and he was saying that he thinks front end development is actually harder than backend development now. Swizec: Yeah, I mean, I love that you mentioned react and the Dom, because a lot of what used to make JavaScript really ugly was interacting with the Dom. And now with these modern frameworks, you're literally just writing JavaScript and letting somebody else handle the Dom. And, the other thing is that modern web apps writing the front end is a lot more like building a desktop app or a mobile app than it is like it used to be building a website. Because a website used to just be you render some HTML. Then maybe you use JavaScript to add a little bit of interaction. Nowadays the front end is more like a full fledged app. It all renders in the browser or with even more modern frameworks, you get all of these weird complications where you have the backend for the front end, where there's a small server, that's just doing the first pass of rendering so that you get instant, static, HTML without the loading spinners. And then you rehydrate that and turn it into a full full-fledged web app. And then you have all of the state management and all of the complicated stuff on the front end, and there's a lot of the business logic and all of the business logic and state management that's now happening on the front is actually super complicated. And that's the hard part, of all of this, especially when we're talking about line of business, software engineering. The hardest part, in my opinion, is domain modeling and data management and deciding what to do with state and where it goes and where it doesn't go, which is like somebody who's building a framework to talk to the Dom. framework They have to do some of that, but honestly, every time I talk to real customers or real world business people, I'm like, wow, this is so much harder and more complicated than anything I've ever seen in a tutorial or a textbook. Like a funny example from earlier in my career, there was somebody who was posting on a forum. Something like, 'Yeah, we need engineers. We have this app that has 2 or 300 database tables.' And I was like 'What the hell? What are you talking about? You don't need 300 database tables. You are surely doing something wrong.' And they were like, 'Okay, well, if you're so sure we're going to hire you.' And they did hire me for a gig. And I was like, oh my God, you need all of these 300 tables. How's this possible? The real world is so complicated. And that's the hard part of software engineering is How do you take a fuzzy business domain? and turn it into something strictly defined that a computer can understand. And we can't get away from that complexity. We're going to have that complexity. Either on the front end or the back-end, maybe both. And you can model it in your API. You can use graph qL to kind of say the problem doesn't actually exist. So like graph QL is kind of an escape for backend engineers, from doing data modeling and clean abstractions. And like we don't care. We're just going to give the front end people access to everything. And they can handle it on their own. And then people working on the front end have to deal with all of that complexity and being like, 'Okay. If I want to render this widget, I need to talk to these five different tables and APIs. And I have to fetch that and all of the things.' but with the rest API. it's more with the rest API. With like, I think, I feel like both rest and graph ql, are kind of going the wrong way there. Cause neither of them really encourages doing proper abstractions. But I feel like I've, yeah, I've walked myself into a corner because I don't want to go on the internet and say 'Rest is actually really bad and create terrible APIs that are hard to work with.' Rebecca: It's probably more like reality and business, fuzzy business, needs create complex structures and REST API is one thing that you can use in which to interact with that complex structure. I mean, both pure REST. Not the way most people use REST, but pure REST and graph ql are very similar in that they give you full direct access to objects on the database. So like, if you have our articles and authors, you fetch articles. and then you fetch authors. With graph QL you've just smooshed that into one request so that it's technically more performant and you get articles and authors together in one request. But as a front end engineer, or as somebody building the client, what you really want is something that says 'hey, give me all of the data. I need to render an article. I don't care if it's an author. I don't care if it's a list of categories. I just want to render an article.' And those kinds of abstractions are really hard to build and usually end up growing very organically, which leads to the kind of APIs we're all used to working with where

nothing makes sense. Everything is hard. And we all think, like front-end engineers think, wow, you back end engineers really gave me terrible abstractions here. And the back end engineers are telling front end engineers. 'Dude, you're really asking me for weird stuff here. That's very hard to get. Why don't you get it yourself?' So that's where I think full stack engineers shine because we can, we get to do both parts of that. So we only get to be angry at ourselves. Rebecca: yeah. So let's, let's take this thread. So, if you can JavaScript, you can backend in the future, belongs to this full stack front end engineer. So now let's bring serverless into that mix. How should a full stack or how should a front end engineer approach serverless? Like what does that transition look like? And I think there are a lot of moments hewhere like tools and frameworks, where like, do you get overwhelmed? You're like, do we even approach this? How, how do I even start to walk into this? What are my responsibilities going to be when I start to take this on? Do I even, should I even design architecture? I think there are all those little questions that float around in your mind. And so I'd love to. If you were listening to my inner dialogue, as I am a front end engineer, thinking about approaching serverless, what might you say to me? Swizec: What I would say is that the nicest thing about serverless is that it abstracts away a lot of the gnarly parts of the backend, or at least the parts that I personally think aren't interesting. A lot of backend code used to be about setting up servers, managing those servers, wiring up routing. I've worked on projects that are using old school, monolithic frameworks running on a container, somewhere on AWS. And it's like to add one new field to your API you have to go into 10 different files, wire up all of the routes, then make sure that the data gets spelunked from one side to the other. Probably in the meantime, you have to translate between camel case and snake case and kebab case about five different times for absolutely no reason. It's just databases are snake case, javaScript is in camel case, something else is in kebab case and because we want to follow all of those perfect, I guess traditions would be a word, I can think of the other word, perfect traditions of each different parts of the stack. We then have to keep translating between them. And I personally don't think there's much value in that. I don't, I feel like some people don't realize this, but your database will work just fine if column names are in camel case. It's going to look weird and you might shriek in horror when you see that. But the database doesn't care. the database it's just a string. Same with JavaScript. If you do some snake case in JavaScript, it's just, it's fine. It's just a string. It doesn't care what you call your variables. But the nice thing with serverless is that it abstracts away all of the dev ops stuff. And all of the

wiring just happens on,, essentially automatically on the infrastructure of AWS or whatever provider you're using. And you can focus on writing the business logic. So my ideal Serverless server is basically a JavaScript function written in node.js that accepts some arguments. That Usually the request object or just the body. The body gets those, get some arguments and returns a JavaScript object. and then there's all this machinery around that function that makes sure that when I make a request to a specific URL, it wakes up. It finds the right data center. If you're using something like edge workers that are becoming more and more popular, it will find the nearest server, the nearest data center to the user, wakes up, a server runs all of the wiring sets up all of the frameworky stuff. Calls your function with a parsed object that just has the arguments that you want. Let your function do its stuff. Returns, gets the result parse, renders it back or munches it back, into JSON, adds all of the HTP headers and stuff, pushes it back out to the API layer and the various things that are in between and gets it to your server, gets it to your website. So like on your web app, you're just making a fetch call to a URL. And on your backend, you're writing a single JavaScript function that takes your payload and returns back a response. And everything else in between is handled by the serverless, either by the serverless environment during either AWS, Azure, or, I think even more popular these days are things like Netlify cloud functions or Gatsby cloud functions. I think next.js got something like that as well, where they've taken this approach even further and said, 'Hey, you know, if this is so easy, like with next .js, it's really nice because next.js, when you're deploying on Versal is able to take bits of your react code, you're writing it in your react component. But if it actually gets extracted and is running as a serverless function and that's just amazing. You're literally putting serverless code and react front-end code in the same file these days. And the framework around it' can figure it out and say, oh, this is actually a backend piece. And I'm going to run it on a function on a cloud function or Lambda. And this is the front end that's going to talk to it.' I just think that's amazing. We've come so far. And just in the last four or five years. Jeremy: Yeah. And I think that, you know, you make a good point about there's an integration or there's a part where it's like you write front-end code, you write some backend code and then Versal, Netlify, we're doing this now with serverless cloud where like, you can just kind of write these things in one spot and it will extract it and it will know that it'll deploy what you need to deploy. But for more complex serverless applications, certainly beyond what Versal and Netlify are doing, you know, you're using something like the serverless framework or you're using Sam, or maybe you're using the CDK or maybe, you know, you're writing raw cloud formation because you're a masochist, I guess. But like, you know, so there are a lot of other tools besides those. And I think that as you get deeper into serverless, you got to start looking at some of those other tools. So I'm curious. You know, it's not as easy as just saying, 'Oh, I'm just going to write this backend function.' Cause there is still a lot of wiring that needs to be done in between there, right? And a lot of this comes as infrastructure as code. Again, serverless framework, Sam, cloud formation, so forth. So I'm just curious, like what your thoughts are on that and how that mental model shifts. Now, when you are writing, you know, you're not doing the dev ops stuff, but you still have to sort of describe what it is that you want to happen on the back end. Swizec: Yeah. I feel like the biggest thing that, especially front-end engineers coming to serverless don't realize is that you can get huge latencies and slowness if you get it wrong. And by get it wrong I mean, the biggest, like the Achilles heel of something like Versal or Netlify functions or even Gatsby functions is when, as soon ,as you have to talk to a database, because you can't configure the database in the same environment. And because you can't, it's then not running in the same, on the same data centers. So the problem there is that something like a Versal cloud function, at least until they add native database support, is running on Versal. Even if it's running in the same AWS cluster, it's essentially making a request to your database over the open internet. And that immediately takes you from like a 50 millisecond response time to 300 millisecond response time, just because of all of the networking and latency stuff. So it feels like, 'Oh, if I add Postgres to my thing, or if I add Mongo, it's suddenly it's slow. It's not actually slow. It's just the connection takes awhile. So, at that point, you suddenly have to switch to something like serverless framework, or like you said, if you're, if you really like pain to raw cloud formation. And I say that with a lot of confidence because we use raw cloud formation at my company. And I wish I was there when these decisions were made, but I wasn't. And we now don't have time to change them. Whatever. It works. It's nice. It's much better than what we had before. There's a, so like one of my coworkers has been with the company for many, many years, and he says how they used to run SSH commands and they just had copy pasta documentation on I think JIRA or even just in a git hub. And it was like, 'Oh, if you want to deploy the server, here are 50 commands that you have to run through an SSH tunnel while you're connected to a VPN and if you copy paste them in the wrong sequence, congratulations, you brought down the entire website and the web app. Nobody can do anything and it's going to be Jeremy: There's no way to recover. Swizec: And there's

no way to recover. We have to start from scratch. It's kind of like when in high school I was installing a Linux and I got it wrong. And because I was just following a tutorial, I didn't know what I was doing. So two days into compiling, gentu, on my very slow computer back then. I got it wrong and I had to start from scratch. And yes, it actually took me three days to install a new operating system. Those were the days. And I'm happy we're not there anymore. That's kind of what this company, it's almost what it was like to manage servers for this company before they switched to infrastructure as code. And the nice thing with infrastructure as code, I personally really liked the serverless framework because it's a really good middle ground between all of the pain of cloud formation and all of the abstraction of something like Netlify or Versal or Gatsby or whatever. Because it gives you all of the power, but it makes the simple things easy. So like, or when we said 'you just, you don't have to think about wiring up on AWS Lambda to a URL. The nice thing with serverless framework is you literally say, this is my URL. Call this function in this file when that URL is hit. And they handled the rest. But when it comes to setting up a database, you can drop into raw cloud formation inside the same yml file for serverless framework and configure all of that. And the importthing about the reason why you want to do that and why you kind of have to jump in complexity from a fully, fully done for you cloud functions to something like serverless framework cloud formation is because then you have more control and you can actually put those things next to each other in the same data center, in the same AWS region. Potentially in the same virtual private network, which security people are very interested in. Something about you don't want your database exposed to everyone on the internet who wants to run a script against it? I dunno. sounds like a good idea. You can put all of those things together, they end up working faster and you have more control over exactly what's happening, which then lets you fine tune. But it also comes with the problem with that. It lets you find tune and now you're in charge of fine tuning it. Jeremy: Well, that's, that's what I was gonna say. I was gonna say with more control also comes more responsibility, right? So, as you start making more decisions and say, 'well, I'm going to use this database and so forth.' Then a lot of that control getsout of your hands. And even if you're using managed services, like using dynamoDB, or even like, Aurora serverless or MongoDB serverless now, and some of these, you might not have to manage the infrastructure, but you are still responsible for quite a bit of that. So from a front end perspective, like taking on that extra responsibility. I mean, I know you've worked with a lot of front ends. You teach a lot of front end developers. I'm curious, like what you've seen in terms of their

reaction to this new sense of control, but also this new responsibility that falls on them? Swizec: Yeah, I think honestly, I think it's a little scary for everyone when they first get started with this, because, you know, unfamiliar things are always. But the good news is that with these new tools, it's a lot more like jumping into React and be like, oh my God, React is so complicated. Then it is like jumping into jQuery is like, this is super simple, but I have to do everything. This is more like, you're jumping into an environment where if you haven't been there before, it might look stupid and it might look super complicated, but it's way better than what th used to be. And I think it's just getting more and simpler and simpler. And this is something that a lot of dev ops people disagree with me, but I really, really think and believe that 10 years from now, we are going to be doing way less dev ops than we are now. Dev ops being, managing our own servers. I feel like even thinking about servers and execution environments, outside of a few very specialized roles who are building this for others, is going to be kind of like how, when you now read about programmers from the sixties who were thinking about absolute memory addressing and they had to think about which part of memory every function call is going to. And they have to manage that manually. When we got compilers, a lot of them were like, 'well, this is weird. Why would you waste computer resources on managing memory for you?' And now when you talk to us, Why would you waste brain power on thinking about managing memory? That's what libraries are for. They just do it for you. So I think something similar is happening on the server space and the dev ops space. We're getting more and more of these tools, which two gray beards who know what's happening you know, instead of running all of the serverless stuff, I could just put up one raspberry pi in my garage and it would be cheaper and it would do everything, everything that this is doing, It's like, yes, but then you have a raspberry pi in your garage that you have to manage yourself and think about. Wouldn't it be nicer to just work on business logic?' And I don't know if that's actually answering your question. I feel like I kind of dodged there, but I think it is, there is a lot of complexity. It's scary when you're starting out at first, but the good thing is that it's getting easier and easier. And if you just get started, I think one of the really nice things is that so many of these companies have discovered DevRel as a role and as a marketing strategy. So you have really high quality tutorials and documentation for all of this stuff, which makes it a lot easier. So, as a piece of advice, I would start with picking one of the companies that's focusing on making this easy. And just do what they say. And get things built, focus on having a problem that you're trying to solve, solve it, build cool stuff. And then as you bump into the edges of that, start exploring and looking beyond what the company itself is providing. and maybe don't jump into raw AWS as your first attempt. Rebecca: I don't know, y'all keep, talking about, you know, raw CloudFormation and equivocating it with pain, but maybe people just want to feel alive. You know, maybe instead of drinking coffee in the morning, they're like, 'Give me some of that raw cloud formation and I am here. I am ready.' Jeremy: Why go base jumping when you can write raw CloudFormation Rebecca: Exactly. They're just, maybe people are like, ''Oh, this is the feeling I need right now.' Swizec: Yeah. Rebecca: Well, another resource that people might be able to use is The Serverless Handbook for Front End Engineers. Certainly tutorials extremely helpful. You have a lot of talks and discussions and presentations online as well, but you also wrote The Serverless Handbook for Front End Engineers. And I first want to ask you what inspired it. I can imagine from some of the conversation we've had, I can imagine in my head what your answers might be, but then I also want to talk about a few specific chapters and you can choose your own adventure, but the ones that I think are pretty, so you talk about, you know, robust backend design, where to store data, Lambda, pipeline, serverless performance, you cover all of it. Then you also talk about architecture principles and how to create good serverless developer experience. And so there's certainly that, you know, developer relations piece that is trying to educate folks, but there's also that developer experience, which like is that layer. Hopefully across, and experienced from end to end, starting at the beginning so that the education piece on the backend is not as hard to just try to be like, 'we know that that doesn't actually make sense by the time you're experiencing it. But like, do this thing over here and pull this over here and then put that camel case over here and then retranslate to this. If you can just make it simple or simpler from the beginning, that developer experience leads to better developer relations, like educational material outcomes, I think. I would love if you would touch on those chapters, but again, choose your own adventure. What you think people would love to hear about. Swizec: Yeah. The Serverless Handbook kind of came out of me jumping into the backend. I was doing backends before, so it's kind of, The Serverless Handbook is basically, it takes all of the almost 20 years of experience now of. Yeah. Wow. I'm old, damn. Almost 20 years of experience of building web apps Rebecca: You heard it here everyone. Jeremy: I was gonna say 'I have gray in my beard as well.' So. Rebecca: Swizec just said he's old. You heard it here first. Swizec: Yeah, no, it's like, I see these numbers. I'm like, whoa, that is a big number. And you don't realize that day-to-day but yeah, so I kind of rolled a lot of my experience of. I had the pleasure of seeing

how this modern experience with building on the web evolved. And I think that gives me a perspective on a lot of the things like the problems that I know, the solved that somebody who's just starting now might be like 'This makes no sense. Why is it done this way?' And it's like, 'it's done that way because we've done all of this before. And you know, it's an evolving process.' It might be better in the next 10 years and probably will. So Serverless Handbook came out knowing how backends work and knowing the principles of this stuff, but then jumping into serverless as a huge, like paradigm shift, on how backends work and how backends work with the front end. And there wasn't really a lot of resources for someone like me, who isn't a Java developer or something that's been working fully on the backend at huge enterprises for the last 10 years. 'At least a few years ago, a lot of serverless stuff out there was specifically serverless is good because you can take your Walmart infrastructure and change it into' like I'm not working at Walmart. I don't have the resources that Walmart does. How does this apply to like my pet side project? Or how does this apply to a beginning startup that just needs to do something on the backend that doesn't have a lot of, you know, we need to build this for a hundred users, not for 10,000 users per second. Cuz how you approach that is very different. So I started the writing from that perspective, and then I realized that one of the big surprises for a lot of, if you're coming at this from the front end is just realizing how flaky distributed systems can be. So that's where a lot of the architecture stuff came from because on the front end, or when you're working on a small self-contained system, a front-end JavaScript function or an iOS app, or even a very complicated thing. Everything works. You call a function, it's going to execute. It's going to return a result. You click a button, it's going to get clicked. Whereas with a distributed system, which is kind of like what serverless always pushes you into, suddenly you have to deal with what if 5% of my API calls fail? How can I make the rest of the system keep working? Or how will I even know if something has failed and fix it? There's a lot of those principles on the backend that kind of get lost in tutorials because tutorials are necessarily simplified and nobody tells you. This is how you build an API. Oh, but by the way, you have to take all of this stuff into account because it might fail five out of 10 times on a bad day. And even on a good day, it's going to fail half a percent of the time, but it should still work. So, that's where the architecture chapters come in and the developer experience chapters, honestly, I think are the area that has aged the fastest. And this is the problem with writing technical stuff. I wanted to write Serverless Handbook in a way that will stand the test of time as much as possible. So the architecture chapters and the ideas behind serverless and the goal of how you want your developer experience to feel, which is like, get pushed to deploy, very easy management, infrastructure as code. Having that one-to-one mapping between your project and what's currently running in production, making it easy to test, stuff like that, all of that is has aged well. The parts that haven't aged well is exactly how to achieve that, because the ecosystem is moving so fast that there's a bunch of better tools out there now then the specifics that I wrote about in the book. But the idea is still the idea I think is still important. One of the things, I learned from reading about dev ops, and there's a really good book about this two books, actually: The Phoenix Project and The Unicorn Project. Really great books on how to make your development process better. And one of the course things they teach is: you should go from a deploy, being a huge event where you put something in production and it's like whiskey time and champagne time. And it takes a team of engineers a week to put everyone's code together and put it out there and make it work. The ideal these days, and that's actually possible is, you can deploy multiple times per day. It's not something anyone even notices it's all behind like feature flags and you just push something out, test it in production, and see if it works. And if it doesn't work, you turn it off, you fix it, you put it out there for like, so like Canary deploys are really fun. You build a new feature. You push it straight out to production as soon as it's ready or even before it's fully ready, you make it available to half a percent of your users or to 1% of your users. If it hurts metrics, you turn it off. If it looks good, you bump it up to 5%, 10%, everyone. And you can see that a lot in like how Twitter or Facebook or those big companies roll out features. And with modern tooling, that's coming to smaller companies as well, where every startup now can have that ability to literally test in production. Like if you talk to somebody from five years ago, would you test your code in production? Obviously write some unit tests and integration tests to make sure of the baseline, but would you test your code in production? It would be a very scary word for a lot of. Nowadays, it's like, 'yeah, you can't actually test anywhere other than production because only production is like production.' And that's kind of where I think we're moving as an ecosystem. And what the ideal developer experience, to meet the ideal of developer experience would be, you write some code or you talk with your team, how something is going to work. You write some code, you make a pull request. That pull request automatically springs up an entire copy of your whole infrastructure with that code running. So you can give it to your product owner. They click around, they say, 'Okay. this looks good.' The rest of your team looks at the code, says, this is great. You click merge.

And 10 minutes later, it's in production, live to a certain percentage of your users. So you can immediately see, 'oops, this is hurting conversions' or 'those users aren't happy' or, 'Hey, we just made a million dollars more money because this feature is out. Great. Let's roll it out to everyone.' One of the things with software that's really nice is that you can iterate fast, but then we're putting all of these roadblocks in our way that makes it hard to iterate fast. And it's only that fast iteration that really makes it possible to build something that people want. Because I feel like in most companies or in most environments, it's much more likely that you're going to build the wrong thing than it is that you're going to build the right thing wrong. Because if it's the right thing, you can always fix it later. But if it's the wrong thing, it needs to die as soon as possible. You don't want to spend. Jeremy: And you want to figure out it's the wrong thing as quickly as possible. Swizec: Exactly. So like, that's where like these fast deploys and quick iteration cycles come in, that you can do with modern tooling. You can immediately see if it's the right thing. If it breaks anything and then iterate from there. Jeremy: Yeah, I totally agree. And I think, I mean, we had this conversation with Charity Majors too, about essentially you have to test in production cause you're not going to find the edges unless you can observe what's actually happening with the systems and distributed systems tend to work really well when they're small, but then once they start getting a lot of traffic and you start getting those failure rates and things like that. So anyways, The Serverless Handbook for Front End Engineers is a great resource and certainly a nice way to get people sort of onboarded into the idea of serverless, but we're running out of time. And I did want to ask you one question, because I think almost in every answer you touched on tutorials, And tutorials are one of those things where I read a lot of them. I mean, a ton of tutorials because I include them in my newsletter and things like that. And some of them are better than others, but you mentioned something in the last one or in your last, answer there where you said, 'You know, they don't tell you that five out of a hundred times or whatever that was, that something might go wrong and you have to deal with that.' So, you kind of have this again, another ethos, I guess. Or something that you like to kind of say is that, your average tutorial actually can make you a mediocre engineer. So what, what do you mean by that? And maybe how do we break out of that cycle? Swizec: Yeah. So this is really tricky because tutorials are fantastic for getting started when you don't know how to do something, find a tutorial, follow the recipe. Amazing. But at some point in your career, hopefully as early as possible, you have to go beyond tutorials towards actually understanding what you're doing

and understanding the 'why' behind those tutorials, because tutorials necessarily are very, very dumbed down and they have to be simplified because otherwise nobody would understand. Like if I try to explain how something works in our production system, I would first have to write something like 5,000 words to give you enough of a background for you to understand the hundred word lesson that comes at the end. So obviously nobody's going to read that tutorial. So what happens with tutorials is you simplify it and you say 'you have articles, authors and categories.' Well, like we said earlier, domain modeling in reality is a lot more complicated than that. But nobody's going to listen to that. Nobody's going to actually read that. So we don't really talk about. so I like to think of tutorials as a really good starting point. Sometimes they can be really good case studies to evaluate how to do, how to approach something, but you really need to have that understanding behind the why and the how of how the tutorial works, because first of all, that's going to make it easier to apply that tutorial to your specific situation. Like you see a lot of, hopefully beginners, online where if they don't find a tutorial for their specific thing, that they're building, they are stuck and they can't build it. And it's like, 'you realize that if you look at this tutorial, And at your problem, the only difference is that? they're calling it tags and you're calling it categories. Everything else is the same.' But if you don't have that understanding behind what you're building, you just don't realize it. I hate to riff on this guy, cause I don't even remember who it was exactly. But what really broke me in terms of building tutorials was a comment on one of my YouTube videos. Somebody was like, 'Hey dude, like I love your tutorials. Can you show us how to build a website with next JS instead of this stupid old React stuff?' Like .So far away from understanding what's going on when somebody knows next JS and doesn't even realize that all of it is built in React. That everything they're doing is a React or, like in the olden days, when I was starting, there was popular questions on stack overflow were like, 'Hey, how do you add two numbers with jQuery'? jQuery is for talking to the Dom. JavaScript is for adding numbers. Like those are things where, and I get it, like when you're completely new, I ask stupid questions like that all the time. Like when I started serverless, I would ask someone who's really good with backend systems. And I would ask a stupid question and they were like, that question doesn't even make sense. You don't understand enough of what's going on here to even ask me a question that I can help with. So I think tutorials are really good for starting with, but if we think the cooking analogy. B being at the tutorial phase is like the being a line cook at a restaurant, you can follow a recipe, you can go really fast. You can make amazing bacon and

eggs or whatever. And it's awesome. You're a great cook. Perfect. We need a lot of those in the world. Right? But if you want to become a chef, you need to understand what goes into those fried eggs. And like to, how to adjust, how to adapt in real time, how to know that's where you can go. And then I feel like this analogy is breaking down, but the difference between a cook and a chef is that a cook can follow a recipe. A chef can create a recipe. And a chef can like, just whip something up from, from scratch. And like, you can see this a lot when people are talking about cooking at home, actually. There's a lot of people who go online and say 'cooking for two people is stupid because all of the recipes are written for four people.'. It's like, okay, but you can just divide the recipe by two and you have the same thing. And it just works. And you might have to adjust your cooking time because frying two eggs takes a little less time. Like it doesn't scale linearly to frying eight eggs. So you just adapt, or people will say, 'Yeah, but you buy stuff for a recipe. And then you have the spices where you have half of a spice leftover and you can never use it again. Or you have half a broccoli leftover because you used half a broccoli.' And then what do you do with half a broccoli versus someone who does a lot of home cooking. Who's gone beyond the tutorial phase. Who like reads the recipe and is like, 'oh yeah, we don't need that spice. We can replace it with that other spice because that's more in season four where we are, or we can just buy a bunch of ingredients. And then every night you look into the fridge and you say, oh, I have half a broccoli. I have a quarter of a steak over there. I have these two spices. Yeah. I can, I can whip something out up from that.' And I think it's similar in software engineering when you're starting out, you're very strictly following tutorials. I feel like you have to push in that direction where you can kind of just take bits and pieces of different recipes, put them together and make something new. And then hopefully with enough practice and with enough trying, you get to the point where somebody can come with a problem that nobody has ever solved before. And that's where I think the really fun software engineering begins. Is when you take a business problem a raw business problem, and you say, 'okay, here's what we're going to do to solve this based on all of this, based on this experience.' And like, there is no tutorial. You're building something from scratch or inventing something new. And those to me are the fun engineering problems to solve. Where suddenly you find yourself in this position where you're the sole leading expert in the world, in that particular, tiny part of your niche. Jeremy: Yeah, I do like bacon and eggs, by the way. But I think you're talking about, you know, it's also about, patterns, right? Like understanding patterns and where you can, putting multiple patterns together. Swizec: Yeah. Rebecca: So if you're ready to go from knowing the ingredients to understanding ingredients in context of meal creation and other analogies such as this, that I imagine he delivers quite often. So it was that you, yourself will write and deliver thoughtfully written emails every week about React to JavaScript and careers. And I took that directly as a quote, uh, because I wanted to quote you rightly. Will you tell some other folks as we wrap up where they can connect with you more, where they can learn more about you and then where they can sign up to get those emails? Swizec: Yeah, you can talk to me on Twitter @swizec, I have swizec.com is where my main newsletter and mailing list lives. If you want to learn more about serverless, you can go to serverlesshandbook.dev, and a new thing I have is senior mindset.com, where I talk more about that path from the tutorial stage to the chef's stage. Rebecca: And for those of you, who are American English speaking listeners as well. So with that is at S W I Z E C. We will put it all in the show notes, but just in case you're only listening. I know myself, I would have heard that and have thought a different letter. So just putting it out there for anyone to make sure you can find Swizec appropriately where he's at. Thank you so much for joining us. Swizec: Yeah, Yeah, thank you for having me. This was awesome. Jeremy: Thanks for being here.