Season 9 Episode 1 May 11, 2022

Using Design Patterns To Improve How You Architect Web Apps

Pitch

"Good code is a love letter from yourself to the next programmer you're handing that code off to."

Description

In this episode, we talk about using design patterns to improve how you architect web apps, with authors of the book, Learning Patterns, Lydia Hallie, Staff Developer Advocate at Vercel, and Addy Osmani, engineering manager at Google working on Chrome.

Hosts

Ben Halpern

Forem - Co-founder

Ben Halpern is co-founder and webmaster of DEV/Forem.

Ridhwana Khan

Ridhwana Khan is a senior software engineer at DEV

Guests

Addy Osmani

Google - Engineering Manager

Addy Osmani considers himself to be an occasional JavaScript Janitor, who cares about improving user-experiences on the web. He is also an engineering manager working on Google Chrome at Google, focused on web performance and tooling.

Lydia Hallie

Vercel - Staff Developer Advocate

Lydia Hallie is a software consultant (JavaScript, TypeScript, GraphQL, Serverless, AWS, Docker, Golang), international speaker, course instructor, and tech influencer with a great passion for coding.

Show Notes

Audio file size

31064126

Duration

00:32:21

Transcript

[00:00:00] AO: In many ways, they allow you to improve readability. So fundamentally good code is a love letter from yourself to the next programmer you’re handing that code off to or the next person you’re working with your team on that code.

 

[00:00:23] BH: Welcome to DevDiscuss, the show where we cover the burning topics that impact all of our lives as developers. I’m Ben Halpern, a co-founder of Forem.

 

[00:00:31] RK: And I'm Ridhwana Khan, Lead Engineer at Forem. And today, we’re talking about using design patterns to improve how you architect web apps with the authors of the new book, Learning Patterns, Lydia Hallie, Staff Developer Advocate at Vercel, and Addy Osmani, Engineering Manager at Google working on Chrome. Thank you so much for being here.

 

[00:00:50] LH: Yeah. Thank you so much for having us.

 

[00:00:52] AO: Excited to be here.

 

[00:00:53] BH: We both had you on the show in the past, but let’s get a little refresher on your developer backgrounds and sort of catch up with what you both have been up to lately. Lydia, why don’t we start with you?

 

[00:01:04] LH: So I recently joined Vercel as a staff developer advocate. After five or six years in engineering, I felt like it was so fun to also use my visualizations in which I was actually on the last podcast that I was with you guys. I was talking about that to teach like advanced developers that already have a lot of experience with React, how to improve their applications, improve what performance and build even better applications.

 

[00:01:29] RK: And Addy, can you give us some cliff notes on your background?

 

[00:01:32] AO: I’ve been working on performance and developer tooling over on the Chrome Team at Google for about 10 years. Before that, I was working at some agencies and Fortune 500 companies. A lot of my focus has been trying to improve user experience on the web and get pages loading as quickly as possible. But a big part of that is also how we go about architecting things and designing things so that the final output is as good as possible. Especially over the last couple of years, it’s been really interesting seeing how the JavaScript ecosystem has been evolving. I was really happy that I got a chance to work with Lydia on this book and take note of the old perspective of how we should be approaching these things in a more modern perspective, kind of jell them together.

 

[00:02:16] SY: So you both came together to write this book about design patterns and their importance. I think Addy, you sort of just spoke to this, but do you want to elaborate on the impetus for writing this particular book right now?

 

[00:02:30] AO: Sure. About 10 years ago, I wrote a design patterns book because I noticed a lot of people were trying to start building these slightly more complex web apps and there wasn’t a whole ton of guidance around how you should be designing your components or how you should be structuring your code. And I remembered that when I was getting deeper into programming, the Gang of Four book was really popular kind of in the ’90s and design patterns have existed for decades, but people have been trying to interpret them in more modern programming languages, every time a new language comes up, and they don’t always translate one-to-one. And so back then, we had a number of different things people were using. It was still the spaghetti JavaScript code days. And so you saw people trying to build lightweight patterns using jQuery and then we had things like Backbone.js and Angular and Dojo and all these other solutions start to come up. But the impetus for this book was it’s been quite some time JavaScript as a language has evolved a lot in the last 10 years too. We now have ES modules. We have classes. We have weeks. We’ve got all sorts of features. And the way that people build apps these days, you’re very often using either a templating library or a framework. And so there may be patterns even within those that you should be thinking about. I guess Lydia, I’ll hand it over to you. I feel like you have the story about how we ended up connecting on this.

 

[00:03:58] LH: Yeah. It was pre pandemic, so good times, but I wrote an article. It was like a visualized article. I enjoyed writing about the internals of JavaScript just to get a better understanding of how everything works under the hood. And people seem to enjoy that. And later, Addy sent me a message on Twitter, asking if I would be interested in kind of modernizing this book that he wrote I believe in like 2009. And I had heard of the book, but personally I’d always had the idea, like, “I want to read it. I feel like it’s useful, but I think it’s outdated. Would it really be worth my time?” At the same time, I didn’t go to college for software engineering or web development. So I always felt like there were just some knowledge gaps that I couldn’t really be more of myself. Like what is it really that I’m missing? So I felt like rewriting this book in a modern way, in a way that I’m used to, I mean, I started with ES4, ES5, but I was still mainly used to ES6, would help me a lot to like gain understanding of how JavaScript evolved and why there are certain patterns nowadays and why we don’t use certain patterns anymore.

 

[00:05:00] RK: What would you say is the audience for this book?

 

[00:05:03] AO: I think the audience for this book, I would say, are intermediate developers, all the way through to advanced developers. I think beginners would get a lot out of it too, but I generally recommend having a little bit of a foundation in JavaScript, ideally a little bit of modern JavaScript, just so that you can follow along. When we say, “Hey, you can use these particular ES6 features to build this pattern up,” ideally you kind of know what features we’re talking about. We walk you through kind of three categories of different kinds of patterns. There are design patterns as frames all the way through time. We then have performance patterns and we have rendering patterns. One of the things that we discovered while writing this book is that there is a little bit of an intersection across all of these topics. And so being able to cover them and give you a bit of breath, I think, is important. So even advanced people will hopefully get something out of it.

 

[00:05:53] LH: Yeah. I think it’s useful for beginners to at least understand the problems that sometimes we’re still facing or used to face and not to try and reinvent the wheel because there is such a big flow of beginner developers right now, which is amazing. But at the same time, they might not have that background of like, “Okay, this is how we got here. These are the problems that used to exist and this tool or framework or built in JavaScript future is solving this.” So even though you don’t have to memorize everything as a beginner, it is definitely very useful to kind of build your foundational knowledge from JavaScript and the web in general.

 

[00:06:30] BH: How did you two go about dividing and conquering and ultimately creating the content of the book?

 

[00:06:37] AO: I would say that the good content in the book is by Lydia and everything else is by me.

 

[00:06:43] LH: We definitely disagree. Most of the good content definitely comes from Addy. No, I read through his book that he wrote in 2009 and I kind of tried to identify the patterns that I felt were still useful. Now from like a modern perspective, is it worth translating this into a modern implementation? And as I was reading it, I tried to create the visualizations for it to make sure that I understood the patterns correctly. And then Addy reviewed it and he rewrote most of the texts to fit the modern ES6 implementations.

 

[00:07:13] AO: We also had help from a few other folks who’ve been great at contributing technical editing and so on. I would say that one of the really exciting things about getting to work on this together was even having side conversations about like, “Is this thing actually still relevant? And if you happen to be using React or you happen to be using something else, what would it actually mean to use this pattern in that context?” So that was kind of cool.

 

[00:07:35] RK: So I noticed that there are some React patterns that you cover in the book. Do you feel like the audience needs to know any React before reading that portion of like design patterns that are applicable to React?

 

[00:07:51] AO: If we’re talking about anything React specific or Next.js specific, there’s a good intro chapter to the topic. So yes, it always helps if you have a little bit of background in the library or framework we’re talking about, but you should also be able to catch up if you don’t.

 

[00:08:08] RK: And why do you feel that design patterns are sort of a vital part of building any applications?

 

[00:08:15] AO: My perspective on this is that design patterns give us a common vocabulary to talk about software design, and that’s always been like one of their biggest values. I think that the analogy that I always like going back to is one by Mario Cervera, but he asks, “Can you imagine an architect is discussing a house only in terms of bricks, walls, doors, and other kinds of low-level terms?” It will take forever to describe a basic house. And so architects use this idea of room patterns, like a bedroom or a bathroom or a kitchen. And that allows us to convey an awful lot of information with very simple sentences, like a two-bedroom, one-bathroom house. I should also say that one thing we’ve tried to stress a lot in the site is patterns are valuable for solving specific problems and they are descriptive, not prescriptive. So if you don’t have the problems we talked about, you shouldn’t use them. They’re not like a blunt tool.

 

[00:09:10] BH: So you are describing a lot of patterns for general maintainability, success, user experience, all the goals of creating effective web apps. But of course the website says a focus on performance, it’s right up there, but it’s not the first thing. You’re known for that. Wondering what the approach and the thought was about maintaining the importance of performance and then the context of a book that doesn’t have it as the title or the top line and that sort of thing.

 

[00:09:43] AO: So the impetus was sometimes the patterns that you ended up choosing for composing your application can have effects that aren’t necessarily obvious at the very start. And so if you end up producing something that you're going through a tool and it’s going to generate some output, if the DX of your overall experience and the maintainability of ability of your code is good, the outcomes are actually not so good for the user, that’s not great. And so we wanted to emphasize that while maintainability is really important, so is everything else that’s involved in getting pixels down to the user at the very end. And so the book is kind of, as I mentioned, like separated out into these three sections. Design patterns are at the very start because that’s kind of the offering time experience. Right? You’re like writing your components, you’re writing your app, and then we take you through the other areas of performance and rendering because those are concerns that you can think about later and then try to figure out, “Okay, well, how do these connect back to the maintainability side of things?” But we did feel like strongly, there’s more to it than just the offering.

 

[00:10:45] LH: I also think that once you read the actual patterns, you’ll quickly figure out that it is about performance. We do mention the effects that they have on your web performance pretty frequently.

 

[MUSIC BREAK]

 

[00:11:15] BH: Lydia, when it came to achieving some of the visualizations, what was the process when it came to performance stuff? What did you try to hit in terms of effectively describing performance concerns through your visualization style?

 

[00:11:32] LH: I try to visualize the steps that even like the script it goes through or just a network request in general, like those very basic things in performance, but that might be pretty hard to grasp if you don’t have a clear kind of mental image of what it really means under the hood. Like why is a large bundle affecting my performance negatively? What’s time to first byte mean? How can I even improve time to first byte? Like all those core web vitals that I feel like it was useful for me to visualize that, “Okay, time to first byte, that’s just the initial request to the server.” And when you split that up into smaller chunks, you just see that bar moving more towards the start. And of course, it was pretty difficult to visualize this in a way where I feel like everyone would understand it, even people that might not have this experience or this background and performance. But for me, personally, I try to make it in a way that when I just started coding, it would have made sense to me. I tried to create the visualization that I personally missed or about stuff that confused me until I wrote the book. So I mainly just created it for myself, but in a way that I felt would benefit everyone.

 

[00:12:39] AO: One of Lydia’s superpowers is being able to take really complex nuanced topics and break them down in a way that everybody can understand really well. That’s one of the things that drew me to her work in the first place. It’s like, “Wow! I would normally be writing a very long article about this topic and I don’t think most people are going to actually read through the end.” She’s able to convey concepts in less than 20 seconds in a video and get that across really, really well. I think that that’s also a super power she’s brought to the book.

 

[00:13:06] RK: You just answered my next question. I was just going to ask, because I found the book like exceptionally clear. It explains concepts really well. It shows them really well. How do you get from a point where some things are like difficult to wrap your head around, but then you get to this clear guide for patterns?

 

[00:13:25] LH: I mean, it’s certainly very difficult to explain something in a very simple way. Initially, you might think like, “Oh, to explain something in a simple way, you just need the basic knowledge,” but it’s actually the opposite. You need to know pretty much everything in order to explain something to a five-year-old, but then really understanding like, “Okay, but what are the real problems here? What are we really trying to solve?” You often end up with just like a bullet list of maybe three items and just trying to tackle these ones is usually the way that I work. And it’s also very relatable, like trying to create a relatable article, like, “Okay, but why does this affect performance?” Like, “Why is this the output when I do this?” Just questions that I personally have as a developer that a lot of the time when I’m reading a technical blog post, I feel like the author doesn’t always mention those things, or they just explain it from a very kind of technical viewpoint, which doesn’t always make sense as a reader. I don’t want you to assume things. I don’t want to fill in the gaps or the blanks. I want to have a very clear article that explains everything in a very simplified way or simple way, but not simplified.

 

[00:14:29] RK: So it sounds like you do a ton of in-depth research to understand everything and then just summarize it in a minute trade, two-minute trade. It’s amazing.

 

[00:14:41] LH: Yeah.

 

[00:14:42] RK: So talk about how learning to implement traditional as well as brand new patterns in a modern way can help you improve your applications on many different levels. Can you talk a little bit about why and how that is?

 

[00:14:55] AO: My perspective on why it’s valuable to get a little bit of a background in patterns is that in many ways they allow you to improve readability. So fundamentally good code is a love letter from yourself to the next programmer you’re handing that code off to or the next person you’re working with your team on that code. And the more you think about writing your code is if a human has to execute it, the better your code is going to get. I think patterns are one of those places where we can lean into a lot of prior experience in trying to make things readable and maintainable rather than necessarily like reinventing the wheel. You always have to approach these things with pragmatism, but I think that trying to take advantage of all the lessons other people have learned over the years is just really valuable. And I guess on top of that, patterns are also useful when you have a specific problem, like you’re trying to refactor your code. They give you in many ways like a refactoring target. So you might detect problems that could be solvable using particular patterns. In that way, they can give you kind of guidance and direction about roughly where you might want to land.

 

[00:16:01] RK: It’s going to stick with me that good code is a love letter to a team member. I really like that.

 

[00:16:06] BH: Can we get into a few design patterns described in the book, ones that stand out as most important for listeners who might want to get a gist of something so that they know what to expect in the book?

 

[00:16:19] AO: One that I think is a good example is like, “Why is there an intersection between design patterns and performance or things like the module pattern?” So in the beginning, JavaScript didn’t really have a way to tackle importing and exporting modules or structuring your components as modules. And so people would do things, like they’d write all of their code in a single file, and that would very often get unmaintainable. And then that led to people trying to squeeze modularity into JavaScript. And so we saw the birth of things like CommonJS, AMD, UMD, and we were finally able to get ECMAScript modules. And that was great. They’re not without their problems, but I think that understanding how you can take advantage of modern primitives and how modern tools work for those primitives to compose and generate better applications is really good. And that allows us, like once we give you that base of like, “Hey, ECMAScript modules are a thing,” we can then talk about things that are adjacent to it, like dynamic import. And why is dynamic import important? Well, it allows us to reduce page load time because we can lazy load the modules we need by default. And that happens to work well with things like Webpack and Rollup and all of these other tools that you might be using. And so I think that just making sure that folks understand, like, “Where did we come from? Where are we going? What should you be using?” I think that’s really powerful.

 

[00:17:42] LH: Yeah. I think I go all the way to the other side of the spectrum. I think the patterns that cover still like the current limitations of the web and JavaScripts and where like the web is going, like Progressive Rehydration, Streaming SSR, React Server Components may also give a lot of people not just hope, but also a better idea of like, “Okay, where are we headed?” For example, the Streaming SSR, currently or nowadays you often see people mention edge rendering, edge SSR. Why is progressive rehydration even necessary? And you won’t understand that. Once you’ve kind of read through most patterns like, “Oh, when I’m server-side rendering something, there are actually a lot of things that, as a user, I may not always be in control of.” We have to look at the entire bundle. The entire component tree needs to be rendered on the server. And seeing how current frameworks are trying to solve that and improve the current patterns that we still see as modern is also very interesting. And I think it’s good for a lot of developers, no matter the level that you are, like where the web is going and how we can improve performance beyond anything that we’ve seen so far.

 

[00:18:50] AO: I guess another aspect of this that’s interesting, a lot of the abstractions people are using to write web applications today have got their own design patterns now. That wasn’t something that you had to think about too much back in the day. And so if you’re using React these days, you probably need to think about hooks or higher order components or other ways of structuring your code. And we wanted to make sure that the book was still not ignoring that. That was the thing. So we tried to touch on some of those topics as well.

 

[00:19:20] BH: What new functionality in JavaScript or API on the browser had the biggest impact on anything that was sort of new to this book, maybe since the last edition of the old book? What were the most high impact things that just changed about the language, the environment, and everything like that?

 

[00:19:39] AO: I would say that on the language side of things, it was really interesting to see how much the need to solve a problem and kind of user land on your own, disappeared with modules, classes are contentious, like some people are really into them, some people are not. And so you see a little bit of discussion around that topic. Patterns like the observer pattern, which were something people heavily used even 10 years ago, you now might be implementing it yourself. You might be using our RxJS. And so just trying to map patterns to the modern landscape I think was an interesting exercise for us. You also asked about, “What are other things that have changed in the browser or in the platform?” I would say, and this is my own biased perspective, but I would say that one of the biggest challenges for delivering a good user experience these days is resource prioritization. So making sure that you’re getting files down the wire and execute it in the browser in the order that you, the developer, intended. This is something that there’s still a big education gap around, like very often we’ll like structure a page. If it renders okay and kind of feels it’s done, we just ship it. But that can mean that really key resources. So if your branding is really important, if your logo is really important, that’s your probably load early on. If people are going to interact with your page, the scripts for that should probably be loading early on, the same for your hero images and things like that. So on the platform side, over the years, we’ve gotten features like link REL preload, more recently priority hints. Effectively, just like levers that allow you to change how the browser is considering the importance of resources, I think that was important. And so getting that kind of base and how should we load and render things. I think that’s going to be useful to folks if they haven’t read too much on this topic before.

 

[MUSIC BREAK]

 

[00:21:45] RK: For both of you, I’m curious to know which was the most complex pattern that you needed to implement into a more simplified description or even an animation.

 

[00:21:57] AO: My high-level answer is there was a whole class of patterns these days that tool chains like Next.js try to simplify, and I know there are lots of other frameworks who try to do a good job of this too, but everything to do with rendering. This has been like a big contentious space for the last 10 years. We’ve gone kind of from, “Hey, you should be static rendering to server rendering, to client-side rendering,” to then a mix. And now we have like four or five ways of approaching that problem, depending on what you’re building. But then you also have people saying like, “Hey, actually, maybe we should be trying to make things look more static and only load the JavaScript needed when it should be used on the page and those types of things.” I would say that this is one of those topics where there was, when we were writing this book, enough change that we ourselves had to keep going back and say, “Okay, well, what’s the status of this pattern where React is concerned and so on?” That for me was one of the most challenging ones.

 

[00:22:49] LH: Yeah, I think I would agree, especially now that I work at Vercel, I work with a lot of Next.js developers. I’ve worked with Next pretty much my entire dev career almost. There were so many rendering patterns of way of rendering. And of course, they started or back then started as just SSR and they slowly moved to SSG. And I still see a lot of frameworks nowadays. Also, just use one singular pattern initially and then they usually figure out that that doesn’t really make sense as an app scaler as they grow. So writing about the current limitations of even very popular and performant patterns was sometimes pretty difficult.

 

[00:23:28] RK: So you answered what was like one of the more complex patterns that you needed to implement. Tell me about the pattern that you feel is the most used pattern in everyday code. Which one do you use the most in your everyday coding?

 

[00:23:43] LH: I mean for me, besides like the module pattern, which isn’t necessarily a pattern that most people have to think about nowadays, since it’s just an ES6 feature, there’s also like the hooks pattern, which a lot of React developers nowadays either move to from class components, or like new React developers, they usually only use the hooks pattern and it’s also useful for them to see like, “Okay, but why were hooks introduced? What was the problem that hooks or what is the problem that hooks are solving in most cases? And why are there still some people against the hooks pattern?” That definitely gives a lot of developers, whether you’re new or advanced, a lot of background information.

 

[00:24:20] AO: I would agree with what Lydia said, but I also want to call out that one of the great things about having a primitive-like modules baked into JavaScript, baked into Node.js is that they’re now the default way that many people write components and that kind of mental shift, being able to standardize on a component format, that’s kind of really powerful and cool. So I’m very excited about, like, what are the next sets of things that would allow people to use them by default and improve that developer experience? On the other side, so we talked about design patterns on the other side, like for performance patterns. I see a lot of people talking about code splitting a little bit more these days and talking about dynamically important, “How should I be structuring my code, so I’m loading a little bit less and improving my performance?” I’m glad to see that conversation continue. I feel like there’s still a big challenge we have around effectively loading pages and JavaScript very often ends up being a big part of that.

 

[00:25:14] BH: Can you speak to any criticisms of modern JavaScript patterns at all, maybe from folks who are less bought in on certain approaches, folks are taking? What do they hate us saying about some of these approaches?

 

[00:25:30] AO: I think that a valid criticism is that very often if you’re jumping for a design pattern without understanding the context where it’s trying to help solve a particular kind of problem, you can needlessly add complexity. Nobody should be going into like, “Hey, I’m going to go build an e-commerce app tomorrow. I’ve got to use the hooks pattern, the container pattern, and the proxy pattern. Otherwise, I’m not going to get funding.” That’s not how to think about patterns. Identify what problems you’re trying to solve. One of the things that we tried hard with this book to do was capture the pros and cons. Like, “What are the good places where this pattern makes sense and what are the places where it doesn’t?” And so hopefully, we’ve done an okay job of that, but I think we could probably continue building on that base. As a general rule, keep code simple. Try to make it easy to read and maintain by other people. Design patterns can be really powerful, but use them when it’s clear that they have value.

 

[00:26:22] RK: Can you talk about some of the tips and tricks or patterns that you have in the book that you think would be the most useful to help folks improve on how they architect their apps? So if they had to read like just a couple of sections in the book, what would be the most go-to patterns that you would encourage them to read first?

 

[00:26:45] LH: Personally, I would say read the rendering pattern section. I think the way that people render their data, whether you’re using a framework or you’re just using React like standalone, it affects not only the user experience, but also to developer experience. It can highly affect how your business is going to work out as your project grows. Or if it goes viral, can you handle all the bandwidth, all that stuff? Especially when you do a Google search or you’re in Tech Twitter, you’ll often see terms like CSR, SSR, ISG, ISR. You get thrown with all these abbreviations and it might not always make sense and then people’s opinion on it as well. So I think just reading those patterns and then identifying like, “Okay, these are the use cases for my project. Am I currently implementing that?” Can already improve both, yeah, like I said, your own experience as a developer, as well as your user experience almost instantly.

 

[00:27:34] BH: Can you talk about the decision to make the book totally free and available or no money?

 

[00:27:41] AO: With the first book, it actually started out as an open source project. And by the way, I’ve never intentionally written a book. I’m just really bad at keeping articles short enough. So they start off as an article and then just keep getting longer and longer and longer. I started off with an open source book on GitHub, and then this was for like the version 10 years ago. And then O’Reilly reached out to me and were like, “Hey, do you want to turn this into a real thing?” And an important part of the deal I had with them was, “Sure, but we have to keep this open. We need to make sure that everybody can access this.” And this idea of open access to books is I think really important. It expands our ability to include a lot more people who are on this journey of trying to improve their programming skills. And I have myself a lot of critiques of the original book that was written, but keeping it open allowed, I think based on the analytics, like 5 million people to read it over the years and that was just mind blowing to me. It was like, “Oh my gosh! This is really, really cool.” And we wanted to make sure that if we were doing a more modern version of this book, that we were being just as inclusive. We want everybody to be able to access it and take advantage of the content. Another benefit of that is we’ve seen lots of people filing feedback and ideas and helping us improve it. And so I think that open model has a lot of value to it.

 

[00:28:55] LH: I would completely agree. And as an author of the book, I am still getting so many other opportunities or just positive feedback from it that I value a lot more than just having that money.

 

[00:29:08] RK: I really loved that and I really loved the book. And so my follow-up question here is what do you see is the next project for the both of you if there is one?

 

[00:29:20] AO: I think a big piece of feedback we’ve had is, “This is cool. Are you all going to do a version for other frameworks or other parts of the ecosystem?” And so I would say the top of that list in terms of feedback has been Vue.js. There’s been a lot of evolution in the Vue community over the last couple of years from the shift from Vue 2 to Vue 3. And so we’re really excited about that the next part of this project being focused on Vue. So what are Vue design patterns and how do we interpret all these patterns through that lens? No dates just yet on when that’s going to be available, but that’s the next big thing we’re hoping for.

 

[00:29:56] LH: We might also already have to rewrite or at least update some of the articles as they’re already outdated, some of them, or at least there is a simpler way of implementing them. So there’s probably just going to be a lot of maintenance as well.

 

[00:30:10] RK: Oh, we're super excited about whatever’s next and I’m pretty sure the audience is as well.

 

[00:30:16] LH: Thank you.

 

[00:30:17] BH: How do you get over any possible paralysis from the notion that these are going to get out of date and like trying to future-proof? Where do you land on that? How do you go about doing that knowing that things get out of date so quickly in this world?

 

[00:30:33] AO: We have a weekly call where we just cry into our terminals and console each other. To some extent, it’s very difficult to keep any technical, like educational content as up to date as possible. So we’re always trying to do our best job. I think one of the benefits of especially Lydia at Vercel, being relatively plugged into the ecosystem and how trends are going, we’re usually just a little bit ahead of the curve, I guess, in terms of knowing what direction the winds are changing. And so that allows us to make sure that the content is updated or we’re at least talking about, “Hey, there’s a big change coming. Maybe we should just make sure our guidance isn’t way out of date.” I guess being proactive about that is an important part.

 

[00:31:15] BH: And is there anything else we haven’t covered that you two would like to speak to?

 

[00:31:20] AO: Check out the book. Please feel free to leave us feedback. It’s also available on all of the various app stores for free. So Google Play, Apple Books, all those places. Reviews, always welcome, also free. So feel free to give them.

 

[00:31:36] RK: Awesome. Thank you so much, Addy and Lydia for joining us today. It was great to have you on the show.

 

[00:31:42] LH: Thank you.

 

[00:31:42] AO: Thanks for having us.

 

[00:31:52] BH: Thank you for listening to DevDiscuss. This show is produced by Gabe Segura. Our senior producer is Levi Sharpe. Editorial oversight by Jess Lee, Peter Frank, and Saron Yitbarek. Our theme song is by Slow Biz. If you have any questions or comments, email [email protected] and make sure to join our DevDiscuss Twitter chats on Tuesdays at 9:00 PM Eastern Time. Or if you want to start your own discussion, write a post on DEV using the tag “discuss”. Please rate and subscribe to this show on Apple Podcasts.