In today's episode, I interview Brad Frost, known for coining the term "Atomic Design." Brad literally wrote the book on this subject, and now consults with companies on how to express their brand from language all the way down to the smallest piece of their UI. Today's episode is sponsored by Pusher. Build awesome realtime features faster with Pusher. Focus on the application, not the infrastructure! Get started today at [spec.fm/pusher](https://spec.fm/pusher)
In today's episode, I interview Brad Frost, known for coining the term "Atomic Design." Brad literally wrote the book on this subject, and now consults with companies on how to express their brand from language all the way down to the smallest piece of their UI.
Today's episode is sponsored by Pusher. Build awesome realtime features faster with Pusher. Focus on the application, not the infrastructure! Get started today at spec.fm/pusher
if someone says atomic design, and even if it's something totally at odds with what I've put out and I've, I've been at those places and stuff, so long as it works for you, like there's not an issue, you know what I mean? It's like, so long as you're able to collectively establish, you know, sort of shared value, shared language and stuff, you're in, and are able to do good work as a result. Um, you know, you could call things like crazy names and yeah, sure. So why not? Yeah. So I don't know. Nesting dolls or something. Yeah, exactly. Exactly. So, uh, it is fascinating though, to see it all play out. And like, uh, there was a sort of another one that sort of pre atomic design, um, sort of without, I'll spare you the story, but the, the, the concept of being future friendly, uh, was sort of like another buzzword that I was partially, partially involved with. But again, it was like aggressive enhancement. Yeah, exactly. It's like to be able to say a couple words and encapsulate like a, 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 Cottrell. 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, uh, just through the lens of a podcast. So if you have questions for me, if you have feedback for this, uh, for these coaching sessions, if you want to call them that, then you can send that feedback to developer tea at gmail.com. I'd love to hear it. I'd also love to hear who, who you would like to be on the show. Uh, people you would like to learn from, uh, on the topics that we talk about on the 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. You know, from the traditional business perspective, if you're, 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. Um, and, and for, you know, 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, you know, all of these things that I previously wrote off because, um, I don't know, pride or something, uh, caused me to think that I knew better. Um, it's interesting to see, you know, when I'm working with people, how, 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? You know, it's, it's going to go back to values. It's, it's ultimately, uh, you know, these softer concepts that we're as developers are kind of reticent to, to give credit to, uh, and, and, and they're really important. They really are. Yeah, absolutely. Like I, I, so a funny example. So I just finished up work where, um, uh, with a client who, where as part of like their sort of core industry, like safety was absolutely paramount, like, you know, to the point of being like paranoid or whatever, but it's like having that principle in place, like as a company, like they, they literally would have, they had like videos where they're like, remember to hold, uh, the handrail as you walk down the flight of stairs. Like that's like, that's like how aggressive, you know, like they were like how bullish they were on safety, but like how that plays out in code and stuff like, you know, safety, like through by ways of, um, you know, sort of like defensive, uh, sort of, you know, practices, things like accessibility, like becoming like really important and, you know, things like, things like performance and like getting things out to people, in the field very quickly and stuff like contributes to that, you know, sort of safety principle that they have as a, as a company. So it was like, yeah, that's stuff we do. We tend to like roll our eyes at like corporate culture or company culture, like mission statements or like other sort of suity 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, you actually have a lot of this stuff spelled out. Like, cause that stuff gets defined. Just by way of, you know, the, the collective, you know, everyone at the company will collectively define the culture, whether you explicitly say it or not. Yeah. And I've worked at tons of places where, you know, that stuff isn't written down there. That stuff isn't explicit. And as a result, of course, all sorts of terrible practices, uh, you know, sort of come up and bubble up. Yeah. Another good example. We at whiteboard, we work with a lot of event, uh, type things like we'll create a site for an event or we'll create an app for an event. And it's, it is very interesting to know, like they're, they are incredibly interested in, uh, 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, it can't crash in that critical, critical hour that the CEO is speaking. So like it doesn't matter. They don't, they don't care about optimization. Right. They care about it not dying. Right. Right. It's, it's a very interesting thing because it's, you know, so we end up way over scaling and they're totally happy with it. Right. Uh, 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 make it, I can optimize the code, but that's not the business case right now. In this moment. Right. And, and coming back to those, those people that tend to be dogmatic or, you know, very sort of arrogant about, so it's like, well, this is how it is. And it's like, right. You know, your, your best practice might be an anti, you know, anti-pattern at, at the next organization. And there's actually a really good rationale for why it's an anti-pattern. Absolutely. So, so I, I do, I love, I love that stuff. I, you know, again, it's, it's sort of back to what you're saying about like, you know, reading people's stuff and like there, there's stuff, 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, your own sort of, you know, you need to make decisions. Like, don't just sort of like blindly like accept, uh, things like you need to apply what you're reading in the outside world to what works for clients, client a versus client B versus client C or whatever. So, yeah, this is a very personal thing too. I mean, my, my wife, for example, she has, uh, she has celiac. And so, uh, the like average health advice might include, you know, I don't know if it does or not, but it may include grains, right? Yeah. You whole, whole wheat is, is healthy. Yeah. It's the base of the pyramid. Yeah. Yeah. So, so, uh, but for her it would be terrible, right? So, uh, this, this idea that, Hey, you know, we, we're, we are different. We have different priorities. We have different values. We have different, uh, struggles. We have different weaknesses. So yeah, absolutely important to understand the realities of that. Yeah. And I, I do think that there's, and all that's to say, it's like, there's a, 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, uh, you know, you're going to have good reasons to override that. But like, generally speaking, there are some, some good things that things that you'd be wise to, 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, that's not logical. A metric ton of sugar. Yes. Yeah, that's good. Uh, so, so I'm going to ask probably, uh, I, 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. Uh, and I, I couldn't find necessarily a place where you talked about this. Uh, I'd be really interested to know, um, kind of this, we talked about sweet spots, and applicability and all that, uh, of, of certain practices and habits. Uh, when it comes to atomic design and, 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. So it's an interesting concept just because it, it does tend to come up, uh, I'll get sort of challenges at, at sort of conference, like question and answers and stuff like that or whatever. And back to sort of your line of work or, or, you know, 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, you know, for QR codes that are going to be printed out in a grocery store. And, uh, you know, and, and this campaign is live for a month and, you know, so we're going to make this, this month, you know, a little bit more of a, a little bit more of a, a little bit more of a, a little bit more of a, a little bit more of a, live for a month. And, you know, so we're going to make this, this microsite, uh, and, and burn it down in a month or whatever. Uh, and then we're going to, you know, do that again. And that's where, as I talked to more and more places, it's like, uh, I, I'm struck, I struggled to see where these, these concepts don't apply because even in that sort of, you know, whenever I, whenever I talked to those people where I'm like, okay, sorry, making a splash page, no doubt, let's just say it's for consumer goods like candy bars have totally different branding have totally different colors have totally different vibes to them and you're making these throwaway websites if you're doing that 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 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 this one is totally this thing is a square peg and we can't fit this in a round hole and when it comes down to it it's like sure, maybe the marketing site and all the applications that happen after a login might feel pretty differently or whatever but as it turns out there's still a lot of the same DNA shared between them so I do, I really struggle even for these people that are like I build email templates and they're totally bespoke every time or I build these templates and they're like, oh, I build this and I build these sites that are meant to be thrown away or whatever and it's like, cool, but do you do that more than once? and if the answer is yes then yeah, you can actually make a lot of use out of these things so I do want to I'm really genuinely struggling to find areas where it just doesn't make sense I mean, obviously if you're a small mom-and-pop shop and whatever, it's like maybe you don't need to invest in this huge mission statement and design principles and all of that stuff it definitely becomes more attractive the bigger the organization, I think but at the same time, again even those small shops and stuff you should have a point of view on how things get done at your company that's probably that probably makes sense and not enough people I think spend the time to 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 front-end code and stuff, and now I'm helping talk about let's take a look at this branding deck let's talk to let's talk to the person let's talk about mission statements and stuff and I love it because I do I think 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 there's so many things that that are not that are not that are not that are not that are not that are not it's very unlikely that the actual conception of a style guide is going to be prohibitively costly I think a lot of people 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 hyper it's going to be a four-dimensional four-dimensional four-dimensional process or it's going to be you know half a year before we actually get this thing in place and I think we 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 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 stuff like in step one yeah you're absolutely right and there's a conversation I had with Chris Coyer a while ago where we were sort of talking about this and just because there have been like a few really prominent really super well done examples of material design sort of being the most famous we'll say but then also Salesforce's lightning design system are these like fantastic really thorough just like beautiful you know comprehensive sort of examples they're the sort of like high watermark 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 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 it's like as time goes on like this is not something that you have to do all at once it's it really does serve as like a foundation for which 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 you know the answer to that you should be like oh that's that's my trigger or whatever like I should put it somewhere put it somewhere and so that way like of course like you know 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 concept for the umpteenth 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 like 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 you know 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 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 and 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 coworkers 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 don't have to deliberate over which gem we're going to use for authentication on the next project we just go 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'll sort of build upon that by just saying rather than every each individual developer head down focusing on the mechanics of writing that same CSS code that the 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 are 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 sort of a healthcare client now and did a bunch of like sort of you know 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 8 pixels or 6 pixels or should it have this gradient or should it be flat or whatever it's like that you know solid there's no doubt that there's some people that are more skilled in those areas and you know care more about that stuff than others but at the same time like you know we want 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 whys and stuff like that and actually caring about that stuff rather than spaces or tabs or BEM 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 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 coherent 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 there'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 developers 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 spec.fm slash Pusher you can get started with a free plan today spec.fm 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 once right so you said like people care they care about it a whole lot well capture that the value of that caring and then just hold on like I think so there's a there's a bias I can't remember the name of it it's 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 is trained in us from you know 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 you know the average developer kind of bucks against using trends and design as much as possible partially because of this but if you 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 you know like 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 a 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 it's done just care once yeah yeah I do think that there's there's a lot to that and I my frustration especially you know as a developer as a developer is like one of the most common questions I get asked by people that are starting off in the field or you know or studying or people that have been working in it for the last decade or whatever like people are struggling with keeping up with the latest and greatest and you know it's just I like to joke that you know GitHub repositories multiply like rabbits you know it's like it is and there's there's something very appealing that to to people! It's like things that are old things that actually work really quite well and are 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 backend programmer but like I've I've learned by working on a lot of sort of WordPress sites and stuff and hacking them to pieces and 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 that's where like my my backend knowledge comes from is that and again there's no doubt that there's 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 are 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 asphalt work really well for roadways you know like there are no doubt more amazing newer technologies out there like are we going to go you know pave you know 500 miles a road with like this new styrofoam something like 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 is this actually worth it like is has this been solved elsewhere has this 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 you know notion of relativism it's like sometimes it is an appropriate time to play around with this new stuff or to push the envelope or to you know 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 on opera mini or 2G networks in the developing world or whatever like 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 I get really sour whenever I start hearing people talk about PHP is bad oh wow can you hear my dog snoring really loudly yeah it's good it is 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 a recording a recording of our dog snoring and from time to time she'll be like can you put on the Ziggy white noise app and I say sure oh yeah that's great oh yeah yeah so where were we prejudice against things that work yeah yeah so old things that work and it's like for example a white noise app with 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 I think you know this this concept of of having bias against old code like it's rooted in something good right and the the anxiety of trying to stay up to date is is also probably rooted in you know when I say it's rooted in something good I mean it's it's more it's rooted in fear most likely that we're going to become obsolete or that something's going to break or you know something is going to go horribly wrong if we don't update if we don't stay on the cutting edge and you know yeah it's fun also as a developer we find a lot of joy in in tweaking a lot of us do at least in changing our workflow but we have to understand like what are the ways that we're spending and what is the resource spend that that is happening with these decisions and in really is there something more that we can that we can focus that same energy and tweaking on and I believe it's ThoughtWorks a 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 a stock portfolio and they they map out all of the technologies that they use based on you know how 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 this picking process what am I going to use well I'm just gonna like try my best to find something that's that I like and and that's new right and that's like our only heuristics for picking this stuff right 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 a thousand options when those are our only criteria yep yep and and that's where sort of again back to this sort of design systems and and front end code guidelines and stuff like that that's where you know that stuff becomes exponentially harder whenever you have you know more and more people on your team right it's like one developer with one opinion whose 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 reign or whatever or free reign to sort of like espouse their opinion or like I'm just going to be over here playing with with react because this is attractive to me and then like you know developer two 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 google does it or something now yeah now suddenly you have this you know cornucopia of like chaos and crap right right and so so it 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 you're and it's not to say that you can't play or you can't poke around or whatever it's about sort of being being very thoughtful and deliberate with like what you're what you're 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 I suppose but but generally speaking that's probably not going to be very valuable for anyone involved right it's and we faced this before right we've seen you know for example bootstrap used to be on make and then it moved to I don't know gulp or grunt 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 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 there may not be a stable version of that for this new thing and you have to change everything because you decided to change one thing right right that is like especially in the sort of! world and stuff it does have such a huge ripple effect one of the other things that I think is really fascinating about this notion of let's blindly adopt new stuff or let's do the next cool thing or whatever there's this really fascinating sentiment that gets said to me a lot of times whenever I talk about patterns and atomic design and design systems and stuff and this whole notion of what we were talking about earlier is solving something once and codifying that as a pattern or 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 kicking around the same old code or copying and pasting this thing or why do you even need me on staff anymore because if we already have a terrible mentality about your life's work or your career's work I want to open up Photoshop and create the same homepage template again and again and again and again and again but what we find is as I talk to especially designers again people who love that 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 tech stack you want and framework you want or whatever and just go to town and have fun but this notion that you're going to be out of a job if you sort of patternize parts of your workflow is absolutely ridiculous I think 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 performance optimization or accessibility or better responsiveness I guess or from a design side of things you're able to focus on micro interactions or animation or motion and things all these things that we've treated as nice to have we've never gotten around to actually being able to play with those things because we're too busy recoding the card pattern for the 20th time so again there's a lot of back to older technology or stable technology and why not chasing every trend that comes out is it's it's 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 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 than again building the core of your app or whatever again and again using different frameworks or different whatevers and I actually wrote down a theme for this episode in my mind based on the questions that I had which we straight from pretty largely but ultimately it was about abstraction so we've covered everything I wrote down just in a kind of a back handed way or not back handed but abstraction or being abstracted from one thing to another that's really a lot of what we're talking about I want to encourage developers to continue connecting with the parts of our jobs that are impossible to replace and to start thinking of ways following 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 the what effectively was going to replace them right it's like a revolution against artificial intelligence today maybe 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 innovative design of textiles rather than actually having to sew it or 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 the show they're hoping to add value to their careers and I think this concept of focusing on the truly valuable that's what we're really talking about here 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 yeah very well said I think applies to life in general you know like you! those things that again that we've found helpful one of the piece of advice I always have is share what you know and the more we can do that and pass that value something we found valuable something as trivial as I really like this Netflix show and you should watch it too or whatever it's like that is how things that is how we transfer knowledge this is how culture is made this is how we make progress is by putting things out there and 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 that actually answers I believe it probably answers the final question that I ask all of the guests that come to the show which is if you could give every developer 30 seconds of advice what would you tell them and I believe that that's probably true yeah there's other parts to it and I tend to say work hard don't be an asshole and share what you know and that's sort of how I live my life and I think that's sound advice for other people as well so I'm not too quick to give good tidbits well the challenge is humility and I'm challenged by your humility I appreciate the time so much and I appreciate you 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 can go and learn everything that we've been talking about if you're listening to the show 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 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 brad frost dot 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 two pieces of homework for you to 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 this is 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 there'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 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