if someone says atomic design, and even if it's something totally at odds with what I've put out, and I've been at those places and stuff. So long as it works for you, there's not an issue. So long as you're able to collectively establish sort of shared value, shared language and stuff, you're able to do good work as a result, you could call things like crazy names. Yeah, sure. Why not? Yeah. So I don't know. Call it nesting dolls or something. Yeah, exactly. Exactly. So it is fascinating though to see it all play out. And like there was sort of another one that sort of pre-atomic design sort of without I'll spare you the story, but the concept of being future friendly was sort of like another buzzword that I was partially involved with. But again, it was like- Progressive enhancement. Yeah, exactly. It's like to be able to say a couple words and encapsulate like a whole lot of other words I think is really powerful and important. Welcome to the second part of the interview with Brad Frost. My name is Jonathan Cutrell. If you missed out on the first part of the interview, make sure you go back and listen to that before you jump into this part. Otherwise you might be a little bit confused. This is Developer Tea. My goal on this show is to help you level up in your career. The idea is to provide you with the same type of coaching service that I would provide you in person if I was your personal mentor just through the lens of a podcast. So if you have questions for me, if you have feedback for this, for these coaching sessions, if you want to call on that, then you can send that feedback to developert.gmail.com. I'd love to hear it. I'd also love to hear who you would like to be on this show. People you would like to learn from on the topics that we talk about on this show. Thank you so much for listening to today's episode of Developer Tea. Once again, don't forget if you didn't listen to the first part of this interview, then go back and listen to it first. Now, let's jump into this interview with Brad Frost. From the traditional business perspective, if you're doing consulting or if you've ever spent time with a business consultant, there is a lot of eye rolling that happens in the general tech community to this stuff. But there is something to be said, for example, for a mission statement at the top of your company and for company values and this stuff. Once you've actually been in a position of leadership at a company, you will probably feel the pain of not having those things if you don't have them. It's really quite interesting to see all these things that I previously wrote off because I don't know, pride or something. It caused me to think that I knew better. It's interesting to see when I'm working with people how often we go back to needing common ground, for example. It's very simple, but we need common ground on how we make decisions. How do we arbitrate between two potential clients? It's going to go back to values. This is ultimately the softer concepts that we're as developers are kind of reticent to give credit to. They're really important. They really are. Absolutely. I have a funny example. I just finished up work with a client who, as part of their core industry, safety was absolutely paramount to the point of being paranoid or whatever. It's like having that principle in place as a company. They literally would have, they had videos where they're like, remember to hold the handrail as you walk down the flight of stairs. That's how aggressive, how bullish they were on safety, but how that plays out in code and safety, by ways of defensive practices, things like accessibility, becoming really important and things like performance and getting things out to people in the field very quickly and stuff contributes to that sort of safety principle that they have as a company. That stuff we do, we tend to rule our eyes at corporate culture or company culture, like mission statements or other sort of sooty sort of stuff. But like, anymore, I find myself like whenever I work with different clients and stuff, I'm like, oh, thank God you actually have a lot of this stuff spelled out. That stuff gets defined just by way of the collective, everyone at the company will collectively define the culture, whether you explicitly say it or not. And I've worked at tons of places where, you know, that stuff isn't written down, that stuff isn't explicit. And as a result, of course, all sorts of terrible practices, you know, sort of come up and bubble up. Yeah, another good example. We at Whiteboard, we work with a lot of event type things like we'll create a site for an event or we'll create an app for an event. And it is very interesting to know like they are incredibly interested in the reliability of this thing to the point that they don't really care if they have to scale up to like 500 dinos on Heroku because it's for one day or it's for like 10 seconds, you know, they just can't let it die. Like it can't crash in that critical, critical hour that the CEO is speaking. So like it doesn't matter. They don't care about optimization. They care about it not dying. Right. And they're very interesting thing because it's, you know, so we end up way overscaling and they're totally happy with it, which is totally antithetical for me as a developer. I'm like, man, this feels wrong. You know, like, I don't want to scale this up. I know I can make it better. I can optimize the code, but that's not the business case right now in this moment. Right. And coming back to those people that tend to be dogmatic or, you know, very sort of arrogant about sort of, it's like, well, this is how it is. And it's like, you know, your best practice might be an anti, you know, anti-pattern at the next organization. And there's actually really good rationale for why it's an anti-pattern. Absolutely. So I do, I love that stuff. I, you know, again, it's sort of back to what you're saying about like, you know, reading people's stuff and like there's stuff to pick up from people's productivity schedule and their morning routine and stuff. It's like, you can, you know, again, you can sort of, you should be exposed to all that stuff, but it's ultimately up to your own, you know, sort of like your own thought process, your own sort of, you know, you need to make decisions like don't just sort of like blindly like accept things. Like you need to apply what you're reading in the outside world to what works for client A versus client B versus client C or whatever. So yeah. This is a very personal thing too, I mean, my wife, for example, she has, she has celiac. And so the like average health advice might include, you know, I don't know if it does not, but it may include grains, right? Yeah. You whole, holy is, is healthy or at least the pyramid. Yeah. Yeah. So, but for her, it would be terrible, right? So this, this idea that, hey, you know, we, we're, we are different. We have different priorities. We have different values. We have different struggles. We have different weaknesses. So yeah, absolutely important to understand the realities of that. Yeah. And I do think that there's, and it, all that's to say, it's like there's, there is something to be said. There's a sweet spot. It's not like total relativism. Like it's not, you know, it's not like, well, nobody, nobody can be right. So therefore, like, anything goes, it's like there, there is something. There's like general trends that it's like, oh, this is typically a good idea. It's like, again, if you have a good reason, whether it's celiac disease or you're designing something for, you know, an event that's going to be live for one hour, you know, you're going to have good reasons to override that. But like generally speaking, there's some, some good things that, things that you'd be wise to listen to or whatever. So yeah, like don't eat a ton of sugar just because you can't have wheat. That's not logical. A metric ton of sugar. Yeah, that's good. So I'm going to ask probably, I don't want to ask all the questions you've been asked before. There's a lot of content online. You've obviously done a lot of talks. So I don't want to rehash stuff that you've already talked about. And I couldn't find necessarily a place where you talked about this. I'd be really interested to know kind of this, we talked about sweet spots. And applicability and all that of certain practices and habits. When it comes to you, atomic design and pattern libraries and these design system concepts, what projects have you encountered or what projects could you imagine this stuff just absolutely does not apply to? Yeah. But it's an interesting concept just because it does tend to come up. I'll get sort of challenges at sort of confidence question and answer and stuff like that or whatever. And back to sort of your line of work or with clients where it's like, oh, this event is going to be live for an hour or something. A lot of people work on like splash pages for QR codes that are going to be used. They'll be printed out in a grocery store and this campaign is live for a month. So we're going to make this this micro site and burn it down in a month or whatever. And then we're going to do that again. And that's where as I talk to more and more places, it's like I struggle to see where these concepts don't apply because even in that sort of whenever I talk to those people where I'm like, okay, so we're making a splash page, no doubt like visually. Let's just say it's for like a consumer goods like, you know, candy bars, like different candy bars, like have totally different branding, have totally different colors, have totally different vibes to them or whatever. And you're making these throw away websites. Well, you're still going, if you're doing that like more than once, you should be thinking about reusing things so that you're not having to reinvent the wheel from scratch. So that every time you need to make a new splash page, it doesn't take you exactly two weeks to design and build or something. You know, it's like you should be getting gains every time you have to do that. And it's funny because I've worked with these places that are like, oh, we have a super big challenge for you because like this, you know, this one is totally, you know, this thing is a square peg and, you know, we can't fit this in a round hole. And it's like when it comes down to it, it's like sure, maybe like the marketing site and like all the applications that happen after a login might feel pretty differently or whatever. But as it turns out, you know, there's still a lot of the same DNA shared between them and stuff. So I do, I really struggle even for these people that are like, I build email templates and they're like totally bespoke every time or I build, yeah, these sites that are meant to be thrown away or whatever. It's like, cool, but like, do you do that more than once? Like, you know, and if the answer is yes, then yeah, you can actually make a lot of you set of these things. So I do want to, I'm really genuinely struggling to find areas where like, it just doesn't make sense. I mean, like obviously, like if you're like a small like mom, pa shop and whatever, it's like, you know, maybe you don't need to invest in like this huge like mission statement and design principles and all of that stuff. Like maybe it definitely becomes more attractive, the bigger the organization, I think. Sure. But at the same time, again, even those small, small shops and stuff, it's like, you know, you should have a point of view on how things get done at your company that's probably makes sense. Sure. And not enough people, I think spend the time to sort of define that stuff. So I've been having a lot of fun in that world because it's taking me way outside of my comfort zone, which is like front end code and stuff. And now I'm like helping talk about, you know, like, let's take a look at this branding deck. Or like, let's talk to the person. Yeah, let's talk about mission statements and stuff. And I love it. Because I do, I think that that irrespective of the industry or size or whatever, it's like, you know, actually articulating what it is you do and why you care about the things you care about is healthy. Yeah, yeah, it is. And really, so I kind of formulated my thoughts on this same topic because I agree with you. So many things that it's very unlikely that the actual conception of a style guide is going to be prohibitively costly. I think a lot of people that the problem that they face is that their perspective on what it will take to create a style guide or what it will take to create a pattern library or to actually implement something like atomic. I think they think that the detail oriented and like hyper, you know, it's going to be a four week process or it's going to be, you know, half a year before we actually get this thing in place. And I think the important message here is like the smallest version of this is better than no version at all. So if you have like a landing page and you really only have two or three components on that landing page, just do a small style guide guide. Style guide for the two or three components. There's nothing that prohibits like there's not a minimum size where this starts becoming valuable. It's valuable on step one. Yeah. You're absolutely right. And there's a conversation I had with Chris Quair a while ago where we are sort of talking about this. And just because there have been like a few really prominent, really super well done examples that material design sort of being the most famous will say, but then also Salesforce's lightning design system are these like fantastic, really thorough, just like beautiful, you know, comprehensive sort of examples there, the sort of like high water mark for all of this thinking. And yeah, you're right. Like people will look at that and they're like, you know, I can't do this. Like I don't have, you know, a team of 15 people and, you know, I can't hire all these people and dedicate all this time to this kind of thinking. And that becomes, you know, a deterrent to ever start down the path. But I think to your point and sort of what I ended up talking about with Chris and I think I talk about it in the book a little bit where it's like, do that thing. Like spend rather than writing the same email for the third time, put it somewhere and share that thing and that that might be the only thing. But I talk about it as sort of like the formation of like a star, right? Like you have all these like dust particles, like these things that are just sort of floating around out there. But just even with those, yeah, like you said, two or three components that provides that little center of gravity. And then, you know, with the fourth and the fifth, like, you know, suddenly the thing starts to get traction and suddenly people start looking to that for answers. And then you can sort of say, oh, yeah, let's build this out a little more comprehensively as time goes on. And, you know, by the way, you know, what's our perspective on performance or what's our perspective on accessibility? Maybe we should add those sort of guidelines in there as well. How do we write Ruby code? How do we write node code? Like what does commenting look like? Like as time goes on, like this is not something that you have to do all at once. It really does serve as like a foundation for what you can grow for years and years. It's knowledge base. Yeah, it is. It is. It's a way of doing things, right? Right. Right. But yeah, like, but it can start small. And again, like this is, it does. It comes back to like, do you want to write that email for the third time? Like that should be like alarm bells going off in your head. Like anytime you find yourself repeating yourself, the answer to that, you should be like, oh, that's my trigger, whatever. Like I should put it somewhere. Put it somewhere. And so that way, like of course, if you leave the company or whatever, the new hire comes, they don't have to come bother you and keep bothering you. It's like, it's lots of developers I know would rather spend their time doing work than explaining the same concepts for the umpteen time. I think so we're going through some of this at whiteboard, especially when it comes to code style and, you know, how do we do GitHub? Yeah. And everybody has a different opinion. Everybody has a different way of doing things. You know, we have differing opinions about should we alphabetize our CSS or should we do it based on responsibility or the type of rule that it is, you know, put your positioning stuff in one place and your dimensions in another. And everybody has differing opinions on this stuff, right? And yeah. And so we've started, you know, creating these boundaries and what it does, the interesting thing that it does is it brings out new knowledge in our workers, right? It brings out new knowledge in people and the opinions become it basically, it's going to make you a better developer and it's going to make you a better designer because you start to recognize, okay, if this is our way, then why is it our way? Really answering the why is where the value is generated. It's not just a, you know, it's not a place to go and copy paste code from only, right? Certainly you can do that. The reuse is there. But the value in that discussion shouldn't be forgotten. There's so much value in arbitration with your, with your coer, so much value in talking about, okay, you know, do we want to do spaces or tabs, just the common one, right? But then it's also, hey, maybe we don't need to keep on changing tools. We found the thing that does that thing and we don't have to, you know, deliberate over what slider we're going to use on the next project. We want to deliberate over which gym we're going to use for authentication on the next project, which just goes straight to the one we know and then we move on to more valuable things that we can spend our time on. Yeah. That's extremely well said and you're totally right, like by, I guess I was sort of built upon that by just saying rather than every, each individual developer head down, focusing on the mechanics of writing that same CSS code that, you know, for the 15th time or it might be their first time, but each of the other people are doing the exact same thing. That is this wasted time. And by having sort of conventions in place, you're freeing more people up to have those higher level conversations. You're elevating everyone on the team. And the same goes in the design world and stuff too. You know, I'm working with a sort of a healthcare client now and did a bunch of like sort of interviews with a bunch of their team members and every single one of them are so frustrated. They're like, I would rather be figuring out this really tough thorny problem rather than going, should my border radius be eight pixels or six pixels or should it have this gradient or should it be flatter, whatever. It's like that, you know, solid, there's no doubt that there are some people that are more skilled in those areas and care more about that stuff than others. But at the same time, like, you know, we want to be operating at a higher level. We want to be doing, you know, focusing our time on nuance and on, like you're saying, like the wise and stuff like that and actually caring about that stuff rather than spaces or tabs or BAM or SMACS or whatever. It's like, it's pick something, go with it, you know, don't just blindly copy and paste it, but you know, do have a good understanding of sort of like why these conventions are in place and that opens the door to having more sort of constructive conversations. And if something is sort of philosophically wrong or something, you know, you'll have more people that are able to sort of, you know, address that in a, in sort of a cohere and smart way. We're going to take a quick break. We'll be right back to the interview with Brad Frost. But I want to talk about today's sponsor, Pusher. You know, Brad and I are talking about solving higher level organizational problems and we're talking about, you know, learning about your business at a high level. And Pusher helps you solve a problem that you shouldn't be solving every time you start to build a new application. If you are looking to add real-time features to your application and really you probably should be, real-time features are things like chat, for example, or adaptive UI. If you, if you want your UI to respond in real time to A-B tests that you're running, or maybe you want to send out real-time stats, these are just a few examples. Pusher's endless possibilities when it comes to real-time. Pusher will help you do exactly that. Pusher has a hosted API and it makes it incredibly simple to add these kinds of real-time features. Pusher works on top of WebSocket connections and it creates that connection from your server to all of your connected clients. It doesn't really matter what language or framework you are used to. Pusher has a library that you can use to give you an idea every single language that we use at Whiteboard, Pusher already supports. Now, if you're thinking, well, we can roll our own solution. We're big enough to roll our own solution. Pusher isn't just made for the 150,000 Developer That are using it. It's also made for larger companies. For example, GitHub and Intercom, MailChimp and even the New York Times, they all use Pusher to build their real-time features. So go and check it out. If you've picked out of them, slash Pusher, you can get started with a free plan today. Spekt out of them, slash Pusher. Thank you again to Pusher for sponsoring today's episode of Developer Tea. Now, let's get back into this interview with Brad Frost. Care wants, right? So you send people care about it a whole lot. Well, capture the value of that caring and then just hold on. I think so there's a bias. I can't remember the name of it. But something along the lines of old code is bad, basically, right? So the idea that as code becomes older, it becomes less reliable or it becomes less relevant or otherwise is bad. And I think some of this is trained in us from food goes bad. So therefore, our code must also degrade over time. And some of this can be true, certainly in design, for example, if you rely on trends for your design to be relevant, then that trend is going to change. And the average developer kind of bucks against using trends in design as much as possible, partially because of this. But if you find something that works, especially when it comes to development, if you find something that is a solid pattern and you realize that it's well maintained or it's maintainable, and people understand it well. And all of these things are going right, then capture that and then just do it again. It's a short circuit. It's very similar to what we were talking about earlier with the language that we use, the buzzwords that we use. If we find something that is really good at communicating and point, for example, atomic design, it's a great metaphor to communicate a point. There's no reason for you to go and write another book that's about the same thing, but renaming the book. Right? And just care once. Yeah. I do think that there's a lot to that. And my frustration, especially as a developer, is one of the most common questions I get asked by people that are starting off in the field or studying, or people that have been working in it for the last decade or whatever. People are struggling with keeping up with the latest and greatest. And it's just, I like to joke that GitHub repositories multiply like rabbits. It's like, it is, and there's something very appealing to people who have been doing this for a long time that know the basics that know they might have started in PHP or whatever. And it's like, okay, but yeah, like, but I know that. And so I'm bored now. And so I'm something new. And I do think that that drives like a lot of that sort of, you know, I need to, yeah, find this GitHub repository that was just published two days ago and it's the new coolest thing ever. And you know, whenever, you know, finally got around to learning grunt, you know, years ago and as soon as I did that, it was like, oh, there's golf. There's golf. And then there's broccoli. And then it's like, now it's web-packed. And then it's like, there's no doubt that, that, you know, some things might have, you know, inherent benefits over others. And again, it comes down to having the discernment to judge when and where those things are appropriate or where golf would be more appropriate over, overgrown or something like that. But this, this sort of fetishism or like this sort of prejudice against like things that are old, things that actually work really quite well in our solid and are well supported and are not going to, you know, blow up in three months. It's strange to me. It's strange to sort of witness that stuff. And like, I see that a lot, like, I'm not a good back-end programmer, but like I've, I learned by working on a lot of sort of WordPress sites and stuff and hacking them to pieces and a magento, which is a e-commerce PHP-based, like sort of e-commerce platform and stuff. So I'd like Frankenstein together, these like e-commerce slash blog sort of experiences. So like that's where like my back-end knowledge comes from is that. And again, there's no doubt that there are other languages and stuff out there that I can, you know, sink my teeth into and probably should. But like I do get weirded out whenever people are so dogmatic or like, oh, but that's old and let's all laugh at it. It's like, well, hang on a sec. You know, like, are we talking about, you know, things like, things like asking for asphalt work really well for roadways, you know? Like, there are no doubt more amazing new or technologies out there. Like, are we going to go, you know, pave, you know, 500 miles a road with like this new Styrofoam? I don't know. Like, I think about like longevity. I think about, you know, sort of things like, you know, like, how much are you going to have to like look out of the corner of your eye and keep an eye on this thing? Like, are you sure that this like brand new spanking new thing that's fun to play with? I get it. And you know, it keeps your developer mind active and keeps those neurons firing and stuff like that. But like, is this actually worth it? Like, has it been solved elsewhere? Has it been solved years ago? Like, can you do what you're trying to do with less or are you just wanting to play with new shiny toys? And there's no one right answer again back to like this notion of relativism. It's like sometimes it is inappropriate time to play around with this new stuff or to push the envelope or to really experiment. And then there's other times where you're trying to build something that's meant to stand the test of time or something or meant to be reliable or meant to be, you know, to work on Opera Mini or 2G networks and the development world or whatever. There's, you know, there's there's appropriate times and places for all of these things. But again, it comes back to that sort of attitude of I get really sour whenever I start hearing people talk about PHP is bad. Oh, wow. Can you hear my dog snoring really loudly? Say me. Yeah. That's good. It's a true story. My wife and I will travel quite a bit and sometimes she can't sleep because we're used to hearing our dog Ziggy snore. And so I made a little white noise app that's just recording our dog snoring and from side to time. She'll be like, can you put on the Ziggy white noise app and I say sure. That's great. Oh, yeah. Yeah. Yeah. So where were we? To prejudice against things that work. Yeah, yeah. So old things that work and it's like that. Like, for example, a white noise app with your dog snoring sounds, it works great. Why go with the bathroom fan when you can have the white noise dog snore app? That's it. No, so I think this concept of having bias against old code, it's rooted in something good, right? And the anxiety of trying to stay up to date is also probably rooted in, when I say it's rooted in something good, I mean, it's more, it's rooted in fear, most likely, that we're going to become obsolete or something's going to break or something is going to go horribly wrong if we don't update, if we don't stay on the cutting edge. And yeah, it's fun. Also, as a developer, we find a lot of joy and tweaking, a lot of us do at least, and changing our workflow. But we have to understand like, what are the ways that we're spending and what is the resource spend that is happening with these decisions? And really, is there something more that we can focus at same energy and tweaking on? And I believe it's ThoughtWorks company that does effectively, they do like a, they look at their current technology portfolio, very similar to the way that they would look at stock portfolio. And they map out all of the technologies that they use based on, you know, how successful is it? What is the market share of this particular technology? Is it a bet? Is it something that we think is going to have a lot of growth in the upcoming years that could be risky and it could just totally tank? Is it something that we already have a lot of competency in? Is it something that's going to make another technology we use that much more valuable? I've talked about that on the show before of stacking technology. So if you know HTML, then learning CSS is extra valuable, right? And then learning JavaScript is even more valuable. So it's this stacking concept. So a lot of developers, I think, are extremely haphazard, unfortunately, about this picking process. What am I going to use? Well, I'm just going to try my best to find something that I like and that's new, right? And that's like our only heuristics for picking this stuff. And it turns out that we like a lot of things and a lot of things are new. And so it's really hard to pick between a pool of 1,000 options when those are our only criteria. Yep. Yep. And that's where, again, back to design systems and front end code guidelines and stuff like that. That's where that stuff becomes exponentially harder whenever you have more and more people on your team, right? It's like a one developer with one opinion whose tastes change with time. Well, multiply that by the number of people on your team. And if everyone's given sort of like full rain or whatever, or free rain to sort of like espouse their opinion or like, I'm just going to be over here playing with react because this is attractive to me. And then like, you know, developer too is like, well, cool. In my corner of the universe, I'm going to play around with view or whatever. And I'm going to play around with angular over here because like, you know, because whatever, I've just made these decisions. Does Google does it or something? Yeah. So suddenly you have this, you know, cornucopia of like chaos and crap. Right, right. And so it does become really interesting to, I love how you're saying, like, to think about it as like as sort of like a portfolio of stuff to like, to evaluate it in a very sort of like, in a very thoughtful way so that you're, right, you're making calculated decisions on sort of what you adopt and what. And it's not to say that you can't play or you can't poke around. Right. Yeah. It's about sort of being very thoughtful and deliberate with like what year, what year betting the farm on? Yeah. I mean, spending a ton of time to move to one system and then turning around and moving it to another system, unless, you know, in very extenuating circumstances as opposed, but generally speaking, that's probably not going to be very valuable for anyone involved. Right. Right. And we've faced this before, right? We've seen, you know, for example, bootstrap used to be on make and then moved to, I don't know, gulp or, or grudge or something. And now the whole world is using web pack and, you know, it's, it's extremely easy because you see so many benefits in the new thing. It's extremely easy to just say, yep, let's do it. Let's throw a bunch of time, throw a bunch of resources at it and just make it happen. But what you forget in that process is, you know, developers on your team, for example, they have to acclimate to that new thing. You forget that, hey, some of the stuff you were using before, they, there may not be a stable version of that for this new thing. Right. And you have to change everything because you decided to change one thing. Right. Right. And that is like that, especially in the sort of like node world and stuff where it's like every, you know, it's like, it does have like such a huge ripple effect. One of the other things that I think is really fascinating about this notion of like sort of let's like blindly adopt new stuff or let's do the next cool thing or whatever, there's there's this really fascinating sentiment that gets said to me a lot of times whenever I talk about patterns and talk about atomic design and design systems and stuff. And this whole notion of, you know, what we are talking about earlier is like, you know, solving something once and sort of codifying that as like a pattern or a reusable pattern. There's so many people that are so terrified that their jobs are going to be mundane, just sort of like plugging in, like, you know, kicking around though the same old code or copying and pasting this thing or like, you know, why do you even need me on staff anymore because like, you know, if we already have patterns and stuff like, you know, I don't have anything to do. And I think that it's such like a terrible mentality to have about like your life's work. Your career's work is like, I want to open up Photoshop and create the same homepage template, you know, again and again and again and again and again and again. But it's, you know, what we find is, is, you know, as I talked to, it's especially designers again, people who love that, that sort of like, I'm going to open up a blank Photoshop canvas and, you know, just sort of go to town, like, you know, total blue sky I could do whatever I want. I guess the developer equivalent of that is you could choose whatever text that you want and frame or whatever and just go to town and have fun. But this notion that like, you're going to be out of a job if like you sort of patternize parts to your workflow and stuff is just absolutely like ridiculous, I think. Right. And what you find is that as time goes on, all those things that you couldn't do before because there's never enough time or enough budget to allocate for that, you're able to concentrate on things like, you know, performance optimization or accessibility or, you know, better responsive, you know, better responsiveness, I guess, or from a design side of thing, you're able to focus on like micro interactions or animation or, you know, motion, you know, all these things that we've sort of treated as like nice to have, we've never gotten around to actually being able to play with those things because we're too busy, you know, recoding the card pattern for, you know, the time. Right. Yeah. So, so again, there's a lot of back to sort of, you know, older technology and like, even it was stable or technology and why not chasing every trend that comes out is, it's, there is this fear again that yeah, we're going to be obsolete. We need to keep moving forward. It's better. It's, it's cool or whatever, but it's like, is it like if you're just burning everything down and rebuilding it in a new technology to get a couple marginal gains like, would that time be better spent working on, you know, a cool new feature or, you know, refactoring this other thing that's been causing you a headache for years or something like that. So, I feel like sort of building on sort of stable technology allows you to explore more things. Yeah. Yeah. Then, then again, building that the core of your app or whatever again, again and again, using just like different frameworks or different whatever's. And I actually wrote down kind of a theme for this episode in my mind based on the questions that I had, which we've strayed from pretty largely, but ultimately it was about abstraction. So we've covered everything I wrote down just in a kind of a backhanded way or not backhanded. But abstraction or being abstracted from one thing to another, that's really a lot of what we're talking about. We encourage Developer To continue connecting with the parts of our jobs that are impossible to replace and to start thinking of ways following this abstract, abstracting theme, start thinking of ways of abstracting themselves out of particular processes, right? And so this concept is totally applicable to that because we have ourselves totally wrapped up. It's like when the industrial revolution occurred and you had people who were, you know, they were afraid that their sewing job was going to be replaced and so they started protesting against these what effectively was going to replace them, right? It's like a revolution against artificial intelligence today, maybe. But the same concept is, okay, we've got this way of freeing up new energy that you can use on something else. And if you view it as an opportunity rather than as a threat, then you start realizing, hey, wait a second. I can work on, you know, innovative design of textiles rather than actually having to sew it. Or, you know, I can actually take some time and think proactively on behalf of the client about new technology that they can implement rather than, hey, how are we going to do this card design again? Yeah. Yeah. Awesome. Well, this has gone incredibly well. I've enjoyed this discussion and I think, you know, a lot of the people who are listening to this show, they're, they're hoping to add value to their careers. And I think this concept of, you know, focusing on the truly valuable, that's what we're really talking about here, right? Focusing on the things that are really valuable and capturing that value and forwarding it and really taking the investment and maximizing the investment of your time, that's what this is all about. Oh, it's very well said. I think applies to life in general too. But those things that, again, you know, that we've found helpful in some, like one of the sort of piece of advice I always have is, you know, share what you know, you know? Share what you know. And the more we can do that and sort of pass that value for, you know, something we found valuable to us, something as trivial as, I really like the Netflix show. Yeah. Yeah. And you should watch it too or whatever. It's like that is how things, that is how we transfer knowledge. Yeah. This is how culture is made. This is how we make progress is by putting things out there and sort of, you know, try things out, see what works, see what doesn't work and whatever, learn from each other and lather rinse repeat, keep doing that. Yeah. And actually, answers, I believe it probably answers the final question that I ask all of the guests that come in the show, which is if you could give every developer 30 seconds of advice, you know, what would you tell them? And I believe that that's probably true. Yeah. There's other parts to it. And I say, I tend to say, work hard, don't be an asshole and share what you know. And that's sort of how I live, try to live my life. And I think that that's sound advice for other people as well. So I'm not too quick to give out advice, but I do think that those are some good, good tidbits. Well, the challenge is humility and I am challenged by your humility. I appreciate the time so much and I appreciate you, you know, being authentic in your career for creating so much value for people through things like atomic design your book and also just the concept of atomic design. The book is online, for example, you know, you can go and learn everything that we've been talking about if you're listening to this show and you're interested in you don't want to spend the money to support Brad, which seems crazy. But you know, if you don't feel like spending the money, Brad's sharing his knowledge with you and sharing the experience. So thank you so much for making really this industry a more, I hate doing the Silicon Valley thing and saying making the world a better place. Thank you for making the industry more authentic and for challenging people with humility. Thank you very much. Yeah, thanks Jonathan. This is great, great chatting with you. Thank you so much for listening to today's episode of Developer Tea. Thank you again, of course, to Brad Frost. Make sure you go and check out all the things that Brad is doing. You can find out most of the stuff at BradFrost.com. And of course, we'll include links in the show notes to relevant things that we've mentioned here. Before we go, I have two pieces of homework for you. The first piece is something you can do today and the second one is something that you're going to be thinking about for the next month or two months or three months. So the first piece is to think about one area where your language, wherever you're working today, if you're working as a developer, where the language that you and your co-workers are using is not totally clear, right? Not 100% clear. And what you think about an area, send this episode to the one or two people that you think would be able to help you solve that clarity issue, right? So you're going to figure out an area where your language is unclear. And then you're going to send this episode to those people and ask that they listen to it and then sit down and talk with them for 10 or 15 minutes to help clarify some of this language. And perhaps the most important kind of work you can do to create a better communication system on your team. Okay, once again, it's very simple. Figure out an area where your communication is unclear. It doesn't have to be bad necessarily. It doesn't have to be difficult. It just is unclear. It's not 100% clear. Send one or two people the episode who work with you in that area and then sit down and talk about that. 10 to 15 minutes. It's not a specified structure, but the goal of that meeting should be to clarify some of the language you're using around your practices. Now the second thing I want you to do, the second piece of homework is I want you to be actively aware of buzzwords. It's pretty easy as a developer to almost have an instinctual rejection of those buzzwords. But I want you to be actively aware of them. What that means is whenever you hear a buzzword, whenever you have that feeling of rejection of that buzzword, whenever you want to just write it off, I want you to remind yourself of the conversation that was had in this episode, the conversation about the value of buzzwords, how much weight they can carry, how much meaning they can carry. Instead of rejecting them, I want you to learn to embrace them. This is going to help your communication out massively. Now, this doesn't mean that those buzzwords are going to be absolutely clear, but it does mean that your communication moving forward is going to increase in quality. Thank you so much for listening to today's episode of Developer Tea. Thank you again to Pusher for sponsoring today's episode. No matter the size of your organization, your application can almost certainly benefit from real-time features, and Pusher makes it absolutely simple to implement these real-time features. Get started with a free plan today at spec.fm slash pusher. Thank you again for listening to today's episode of Developer Tea. Until next time, enjoy your tea.