What was the last time that you skipped the framework and went straight for using the language itself? Not really relying on a library or something like that. This is probably something that a lot of us kind of take for granted, but in today's episode I'm talking to Chris Ferdinandi and Chris is an excellent developer. He has created quite a few of those libraries, but he is a big proponent of writing for him at Straviskode, but writing code that isn't reliant on an external dependency. We're going to be talking about that in today's episode. My name is Jonathan Cutrell. You're listening to Developer Tea. My goal on the show is to help you become a better developer and the way that we're going to do that today is through an interview by listening to someone who's been doing this successfully for quite a while and has created a lot of projects, some of which you may actually know about. Let's jump straight into the interview with Chris Ferdinandi. Welcome to the show, Chris. Thanks for having me. It's great to be here. I'm excited to talk to you. As I am with all of my guests, I'm excited to talk to you, specifically you reached out to me. You mentioned that you want to talk about JavaScript and more specifically you sent me a couple of these topics that you're really particularly interested in. First, I want to open up with a question that sometimes I leave till the end of the podcast. It's a question I like to ask all of my guests. I think it's a really important question. Really, if you're a developer, just a side note here, developer, and you're wondering a good question to ask a potential employer, this may be a good one and a one-on-one interview. This question is one that I caught from a really close friend of mine at work. It's very simple. What do you wish more people would ask you about? That is a really good question. It's probably my favorite question of all time. I've literally never been asked that before, so I don't even really have a canned answer. For me, just generally, there's two things. The first is Pixar movies because I absolutely love them. I can talk about them for days. Favorite is Wally, least favorite is a good dinosaur. I feel like you're probably in line with a lot of people on that. Yeah, not the only one. It's not to get too far off topic, but the good dinosaur is for me one of the biggest disappointments. I actually haven't seen it, by the way. Oh, yeah. It's one of those. It's on its own. It's probably an OK movie, but under the umbrella of Pixar, it's a disappointment, just because it's definitely about their normal, awesome. But specifically to my work and that sort of thing, some variation of why I'm not going to be a part of it. I shouldn't use a JavaScript framework because right now, JS frameworks are all the rage. People act like you can't even build a basic website if you're not loading in React or Angular or something like that. You can do so much without any of those things. I feel like that's particularly relevant when I start thinking about beginning developers, or beginners, new developers. If I were trying to just get into this now, I would feel so incredibly overwhelmed. When I learned it was relatively easy to just open up a text editor and a browser and start coding. You can totally do that today too, but all of the tutorials out there make it sound like that's an impossibility. It's the kind of thing where I feel people are really focused on tooling. I'd love to have more conversations about anti-tooling or untooling or just doing things without tools. It's interesting you mentioned this. I started learning web development in the earliest days of jQuery. When jQuery and prototype and MewTools were all still running a race together. They were all equal partners in the JavaScript library world. They weren't frameworks. We didn't use the term framework for JavaScript libraries back then because most of the stuff that you did was going to be, first of all, relatively specific to the site that you were building at the time. Secondly, it's going to be like you want infinite scroll or you want this one particular type of thing. You go find a good jQuery plugin and pop it in and basically you're done. There wasn't a lot of this. This was obviously before one page applications. That was still on the horizon. There were people who were making one page applications using jQuery. I remember the same very similar discussions then. It was very early when this started that do you need jQuery discussion. That has continued right up until today. There are people who are still asking this question and you're one of those people. You and I were going to talk about this because I think this is really important for web developers and a large number of people who are listening to Developer Tea.R. in fact, web developers, not just not other types of software. Front-end developers, for example. We're going to talk about some of that stuff today. That's the thing that you want to talk about the most. This is good. Yeah, absolutely. JavaScript frameworks, we can very easily write that off as not a big deal. With all of this stuff that's going on in our lives, this is still something that comes to the front of your mind when someone asks you a question like, what do you want to talk about? Why does it matter so much to you that people think about JavaScript this way or a better way of asking that question? Why is it so important that a new developer coming in that they don't join what you call the JavaScript rat race? Why is this so important? Yeah, well, it's one of those, I don't, there's a couple of reasons. I don't necessarily hate these tools. I dislike the overuse of them for a couple of reasons. The first is that it's super alienating because most or a lot of tutorials you read these days start with some variation of open up terminal in command line, run mpm install these eight packages and then make sure you install Babel and run your compiler to transpile JSX into real JavaScript. It's just like it's really alienating and overwhelming. I guess the second reason for me is you've got a whole generation of, and I'm going to sound like kind of old man yells at the clouds right now, but this generation of developers who came up with the notion of the web as an application platform, whereas I and I think you too, Jonathan, kind of came up with the idea of the web as a document sharing tool. It's obviously way more than that. But if that's kind of your mental model, the way you think about the web is fundamentally different. You think about it as this thing that gives everybody in the world access to every kind of piece of knowledge you can possibly amass. If you think about it as an application, you just kind of fundamentally approach the way you develop things differently. You don't necessarily care about older browsers. You don't care about people on underperforming devices. I've heard a lot of people kind of make this argument around like, oh, your browser doesn't support this feature. Just upgrade. Browsers are free. It completely dismisses people who are in developing areas and are stuck on really bad hardware or corporate users who can't upgrade their browser for some reason. Low income people, not necessarily in developing nations, who are stuck on old computers that are running some archaic version of Windows that they can't afford to upgrade. It's a little bit tangential, but I feel like kind of the framework mindset feeds into this. The web is an application and the way you approach development is just totally different around that. I guess for me, it's also partially a moral thing. I don't think there's anything wrong with learning frameworks. I learned on jQuery before I moved over to the vanilla stuff. It sounds like you did too. I think these days, a lot of the stuff that people are like, oh, you need a framework for that. You don't need a framework for that. In a lot of cases, it's just as easy to do it without a framework or easier. Those are the kind of conversations I guess I like to have, particularly with beginners, just because I get a lot of the, I don't know what to learn next, or I don't know how to get started, or I feel overwhelmed by all this stuff. There is a more sane way to do things. This is a, man, this is such an important thing that I want Developer Tealisteners to capture. A lot of people who listen to this show are new developers, which is the type of people that you've mentioned this being important to. The developers who are listening to this show, a lot of people have exactly what you identified as this fear of missing out, beyond that, even as a relatively seasoned developer, when I try to get Webpack set up, sometimes I want to pull my hair out, right? There's so many tools, and there's so many new tools, and the tools that you were using even last year are probably being replaced. There's so many of these things moving forward, and it's not just Web development. I want to be very clear, every single platform is going to go through some kind of revolutionary change. For example, you may have started developing for iOS using Objective-C, and then now that's pretty much out the door, and you have to move to Swift at some point in the future, or I don't know, maybe they've deprecated it officially. I don't know. There's this idea that we have all of these tools, and that keeping up is so important, and that everyone else who is doing this understands these tools. Sometimes, quite honestly, the tool is really hard to understand. Just because you feel like you're the only one that doesn't understand it, you're probably not. Probably not the only one that doesn't, and by the way, you're probably not by a long shot. There's probably seasoned developers who don't understand that tool very well. There's probably people who could write the documentation for that tool in a way that others would understand it better. These are things that are really important to capture. There's moments of the light bulb going on. I'm actually taking a course in machine learning on Coursera right now. Really, really interesting stuff. Putting it very lightly. Very interesting, obviously, a big part of our future is developers. But there's this moment that I've had multiple times while taking this course, and it's a light bulb moment, where I realize that's what that is doing. It's wrapped in a lot of language or a lot of documentation or formal notation. There's all this stuff that's wrapping around it. Getting down to the core of it, that's what that thing is doing. For example, you probably had this moment with Gulp just like I did. Gulp is basically a way to run JavaScript to do some stuff on demand, like at least that's the way that my light bulb moment was that happened in my brain. I realized one day that I could use Gulp and I could access a bunch of JavaScript, MPM packages, and I could run it from the command line, and I could do that on a project by project basis, I could create these configs and stuff like that. Have you had some of these similar light bulb moments that you feel like even as a season developer, these tools that we're discussing right now, that the light bulb moment clarified what that tool is for? That's question number one. Question number two is, how does this extra layer, this kind of indirection, this kind of difficult to understand? How does that impede the learning process for say a young developer? Yeah, no, so it's too old. The reason I think I know I'm getting old is I tend to when new kind of stuff comes out now, instead of just being like, oh yeah, that's awesome, and embracing it. I very immediately kind of viscerally reject it for quite a while before eventually coming around. Gulp was absolutely one of those things for me. It was a code kit user for a long time. I was too. And I code kit was excellent. Code kit is still an amazing tool. But the thing that kind of turned the tide for me was working on a lot of open source projects. I very much wanted to be able to offer folks both minified and non-minified version of a file. So people who wanted something that was production ready had it. And people who kind of wanted to see the un obscured code, so to speak, had that option. And along with a handful of other things, like automating kind of like my little copyright injection and that sort of thing. And stuff that was either difficult or impossible to do in code kit was pretty easy in gulp. But the documentation was terrible. And I had also suffered from, I think the thing that added to it, and this is true of not just gulp, but like all front end tools is some new hotness comes along to replace the current hot thing very quickly. So you go from static sites to WordPress is the best to, oh no, actually we're using static site generators again. And you know, Yoman is the one, oh no, not Yoman now it's, I actually forget what all the cool kids are using these days. We're like two or three iterations. I just heard like another one the other day that like everybody is like bailing to jump ship to. And you know, and then it was like do you remember grunt, like grunt, oh yeah, I'm talking about three months, I actually worked at a company that went like all in on it. And then gulp just kind of completely took it over. And for not really insanely like there wasn't a huge reason why. No, it's just surprising about that right? Our culture is kind of obsessed with new, you know, so like, I guess on the front inside, you know, like you said like the moutools, J query and prototype, like they they fought out for a long time before J query kind of won that battle. But now you see these frameworks come and go like rapid fire, you know, so like angular was super hot for a hot minute before everybody's like no, forget that react is way better. Now, um, react actually hung on for quite a while, but I'm starting to see more mumblings around like view JS and not that these old things ever go away. But it feels like they do. And I think for me that's that's kind of part of the problem too. It's it, you know, feeds into that that FOMO or that fear of missing out because like, like WordPress power is more than a quarter of the web, not just like the CMS market, but like the entire internet. Yeah. Not be the cool kid anymore, but but they are here forever. Yeah. Angular as much as I kind of personally detest the way Angular works, they have deep roots in enterprise and they're going to be around for a long time. So if you learned Angular and all of a sudden everybody's like, ah, forget that. It's, you know, it's all about react. Like you shouldn't feel bad about that. You have a very marketable skill that you can build a very nice career on top of. Yeah. You know, and you had some questions in there that somewhere along the line of my ramp, like I am. Oh, no, that's fine. I forgot. But, um, no problem. But yeah, I just, um, I don't know, like for me, that's that's kind of the, I think one of the reasons I'm so into like anti tooling is I'm just, I've grown tired of chasing the new hot thing because a lot of like I named the popular things that stuck around, but there's a ton of other things that had a lot of buzz and then fizzled and just never went anywhere. Yeah. And, and you know, for me, like when you know the, when you know the fundamentals, like knowing, knowing vanilla JavaScript, knowing really good CSS, like you can carry those over into learning new things, learning new frameworks, learning SAS. Um, I know a lot of people are into like post CSS now instead of SAS. Um, you know, less was like a big thing before SAS kind of dominated, um, you know, like if you know kind of those, those core skills, um, like they just, they carry you through the ebb and flow of, of these tooling popularity cycles and, um, and you're absolutely right that this is not unique to us. But it feels like on the front end, these things come and go way more quickly and our culture has become obsessed with, with tools more than methodologies and approaches. Um, yeah, all about the tooling and, um, and it's just, it's a little bit insane. Today's episode is sponsored by Linode. Of course, if you've been listening to Developer Tea for very long, you know that we love Linode around here, not only because they are a long time sponsor of the show, but also because they help developers create things. How do they do that? Well, they provide incredibly priced Linux servers. You can get these things up and running in just a few minutes and they have really fantastic plans. Uh, their plans actually are the best price, uh, per dollar in terms of memory, in terms of RAM. So this is really, really important for, uh, performance. They also have SSD servers that the Linux is sitting on top of. So it's going to be super fast, uh, on the single server, but it's also super fast between servers. If you were to spin up multiple servers for your site, you know, and have some kind of load balancing, which by the way, they support that, uh, that would be really fast. They have a 40 gigabit internal network to support that. So go and check out what Linode has to offer. You can have a Linode server for as low as $5 a month. That gets you onto a one gigabyte of RAM server, uh, $5 a month. That's so cheap. And if you don't have a server somewhere, then $5 a month can get you one. And that's really cheap. $60 a year. And by the way, just to give you an idea, Linode is providing you with $20 worth of credit. So if it's $60 per year to host this one gigabyte server. So if you do the math, that's a third of the year that you don't have to pay anything for that server. So if you want to pay $20 worth of credit, go and check it out, spec.fm slash Linode. Make sure you use the code Developer Tea2017 to check out if you want that $20 worth of credit. Thank you again to Linode for continuing to sponsor Developer Tea. So on the flip side, because I don't want Developer Tealisteners or anybody else who hears the show, I don't want you to think that, you know, there's always a good reason to question. And I was just thinking about this today, I'm probably going to do a full episode on the idea, but there's always a good reason to find your limits, find the thing that you say, oh, I'm not going to go past that. And then ask yourself why, right? So for example, if you're a web developer, you may, you know, you may start every project by default, you're including J query. And you know that you have J query under your skill set, like in your skill set tool belt, whatever you want to call it, and you're familiar with it. So it's an easy go to and it's a reasonable default to you. And if somebody were to ask you, hey, you know, do you want to start a project without J query? By default, you've answered that over and over. No, I don't want to start it without J query. It is a reasonable idea to ask yourself why, right? Why are you doing things the way that you've done them? Or, you know, why aren't you reconsidering portions of your strategy, portions of your skill set? You know, what is keeping you for me for many years, J query was default because the browser APIs were so various, you know, they were so broken apart that it was difficult to do anything, you know, with a reasonable speed. And so the code ended up being really difficult. And I wasn't familiar with it. You know, I was one of those people who learned J query before I learned JavaScript, you know, however bad that may be. And you know, what it came down to was, you know, it's before a query selector all was really supported, for example. And so, you know, getting a collection of elements was tedious. It was really kind of difficult. And so, you know, now all those things have changed. And so it does make sense to start asking those. And it actually made sense back then when I could have a reason to say no, I will start with J query as a default. But now it's, it continues to make more sense to ask these questions. You know, when we have these tools though, what I don't want you to walk away thinking is, all right, well, I'm going to throw away, I'm going to uninstall and pm all together. And everything that I install is going to be a zip that I, you know, drop into a folder. That's not at all what I'm saying. There are so many valuable projects, so many valuable tools that are worth your time. And they are worth, you know, considering and then integrating into whatever project you're doing. But just pulling those in wholesale because somebody, you know, online said that it was a good idea, that is not worth. That's not worth the bites quite honestly that your users would spend to download it. And it's not worth the brain power necessary for you to stay current with all of the new stuff that's coming out. Yeah, no, and that's a really good point. Like I always, I sound like I'm down on tooling, but I actually use a lot of kind of tools in my development. Can you make them too, right? You've got a whole list of open source tools that you've made. I do. So I'm like all in on golf, I love SAS. Although the, as CSS variables become like variables are one of the big things I use. I use golf for and as native CSS is able to handle that better. I may see my reliance on SAS start to disappear. But yeah, no, I love tools. I just hate our culture's obsession with new ones for the sake of new. So tools are great. Anything that I shouldn't say anything, but things that make you more productive or allow you to do more faster, easier, better are great. I just, a lot of our tools are either just tools for the sake of tools or they're like openly hostile to the people who consume the things you make. You know, like a lot of times people will add some of these hot new frameworks or libraries to their site. But just the amount of bloat and weight they add to your page, you know, to do things that frankly you could very easily do without those tools or libraries. You know, I think that for me is kind of where I get a little hung up. That and just kind of that overwhelming fomo that everybody in our industry seems to suffer from these days. Well, and it is, you know, going all the way one direction or all the way at the other direction, neither of those is a good idea, right? It doesn't, you know, there's a reason why Google is one of the companies that's putting out some of these tools. And they're very successful. They have very successful projects. You know, obviously some of the smartest engineers in the world and they're using these tools. So I do think that, you know, the key, there's a bunch of things to think about here. Something that developers are not well trained on is managing their portfolio of tools. This is something that we just kind of do. We fly by the hand, you know, whatever the words are to say that we don't really do this right. We're kind of blindly picking as we go rather than approaching this like, you know, any other industry really. Because time invested, it's, you know, there are implications down the road. There's things to think about in terms of collaboration. There's, you know, there's so many things to think about when you are picking your tools. And, you know, a very important one of those things is how long am I actually going to be able to benefit from picking this tool up and learning it, right? Like how long is this knowledge going to be valuable? There's a lot of other, there's actually a couple of really good podcast episodes and I can't remember the name of the podcast. It may have been Ruby Rogues, but they talk about this exact concept and it was a guest from ThoughtWorks, I think software development firm, major, major firm. But they were talking about managing your learning portfolio effectively is what they were discussing. And they talk about, you know, how you can kind of manage it very similar to a stock portfolio where you have, you know, a few things that you're learning that are kind of way out, you know, out of left field. They're a little bit more risky in terms of, am I actually going to be able to benefit from this? And then the stuff that you really rely on is, for example, vanilla JavaScript, right? You're not going to go wrong learning vanilla JavaScript. That's going to be applicable. Does that make sense? Yeah, absolutely. Absolutely. How did you finally decide that you wanted to really invest in learning Gulp and using it for these projects that you have? Yeah. So I, by the time I decided I wanted to dig into Gulp, Grunt had already started to kind of fade from popularity. And I had also heard that, you know, whereas Grunt was really focused on kind of configuration files, Gulp seemed to be a lot more about just kind of running JavaScript, which kind of resonated with me a little bit. But for me, the motivation was almost exclusively around making it easier to kind of push my open source work. So there was a handful of things I wanted to do that were just not either didn't like the way they kind of worked in CodeKit or they were difficult to do in CodeKit. And as I was thinking about this, a couple of folks who were, that I respect, who were just themselves starting to get into Gulp kind of open sourced their like their boiler plates for getting started with it. So I just, I took those and kind of ripped them apart and learned by doing, I guess. But yeah, it was, it was 100% pragmatic. And Sarah Swadon talks about this quite a bit. So those of you who are familiar, she's a really, really talented front end developer out of Lebanon. And she's best known for her work with SVG, although she does a lot of other stuff too. But one of the things she always talks about for kind of maintaining your sanity as a front end developer is really like holding off on learning new things until you absolutely like need it for a project. So like it's good to be aware that things are happening. So like I, for example, am aware of CSS grid, though I don't know how to actually use it myself because I haven't had a need for it on a project yet. Same thing goes with Flexbox actually. I've been getting by on like old school CSS grids for a long time. But like the thinking there is so be aware, like casually aware of developments in the industry. But until you actually like really need something on a project, like you could burn yourself out chasing every new, never mind framework and library, just all the new features that come out in any given year, the browsers support these days. So you know, like really just kind of like waiting until you absolutely need something is a great way to kind of maintain your calm. But I can remember, you know, so Jonathan, I think you're about the same age as I am. I don't know if you remember, do you remember the show Beakman's World? It was kind of like a, that does sound familiar. A sciencey analog to Bill Nye, the science guy, but it was like way more kind of like edgy than Bill Nye. Yeah, yeah. It sounds familiar, but I can't remember any specific episode or anything. Yeah, it was just, it was really weird. It was like in this basement, there was this man who was like dressed up as a dog. I was just really bizarre. But like, I remember one of the things they always talked about on the show was that like being a scientist wasn't about having all the answers, it was knowing the process to find them out. And I really like to think that that carries over quite well into kind of the life of a front end developer. Like if you're, if you're earlier in your career, you can get really intimidated looking at like job descriptions of being like, oh, they want all this stuff. And I don't know any of those things. The reality is most people who apply for those jobs don't know all of those things either. And the more important thing is not knowing all the things. It's knowing how to learn the things when you need them. Yes. And for me, that is such a much more valuable skill than actually knowing all this stuff. So it's one of the reasons I harp on fundamentals all the time. Like if you know really good CSS or you know kind of that fundamental JavaScript, you can pick up a framework, maybe not super quickly the first time you go to do it. But you can learn new frameworks when you need to use them for a particular job. You can learn new tools when they come out more easily. And there's a documentation issue too. I mean, you kind of alluded to this that the documentation for a lot of open source projects is absolutely terrible. Yeah. Like, you know, like that aside, you know, like just kind of developing your approach to picking up stuff when you need it is important. The other thing for me too is I am very consistent with my tool chain. So I don't, I know some people love to kind of try a new tool every project they work on. Like I've talked to people who are like, oh, you know, like I'm starting a new project and I'm super excited about it because there's this new tool that just came out that I'm dying to use. Like if you really genuinely enjoy that, that's great. But you just like you can blow so much time learning the new thing that could be spent like actually making stuff. And yeah. And like if you're just doing it for yourself, like that, that's awesome. But like if you're, if you're doing client work or you're working, you know, for an employer or anything like that, you know, even if you're working for yourself, you know, but you're making money on the thing you're building, like your, your time is so valuable. And I don't know, like wasting it, trying to learn the latest new tool that came out just just for the sake of learning the tool. Not because it gives you any benefit over the tool you were using previously. Yeah. Yeah. Seems a little odd. Like I know tons of people who still use grunt because they invested in it. They've got all their stuff set up and it still works. You know, sure. There's no reason to stop. There's no particular reason to stop. No, I mean, it's one of those like it's not cool anymore, but it, it does the thing you need it to do. So like, right. Yeah. There's tons of great plugins for it and, and packages and modules and, you know, like it's just it's not, you know, it's anyways, I'm sorry. That was a really long rant. It's good. It's good. Yeah. No, I am, I am very, very kind of consistent and almost like a reluctant about my, my tool setup. I have a very small kind of set of, of tiny modular things I like to use and I, I don't really like to, to deviate from it much. Like even with gulp, like I've now got my latest version of my gulp build up at the top of my gulp file.js has a, like a settings variable that has a whole bunch of like, like things that I can turn on or off. Like sure. Yeah. Scripts processing CSS SVGs copying static files, minifying images, things like that. And, you know, so like if I don't need one of those things on a particular project, I just change the variable under settings, but I don't in any other way have to touch my tool chain. Right. Yeah. I'm using the same gulp build for every project. Right. I think there's, there's something really interesting in what you've done there though. And that is that you've, you've found opportunities where tooling can help without, you know, seeking tooling for the sake of tooling. I think that's, you know, that's, this is something that a lot of developers, they get wrong in one direction or the other because the culture is that there's so many tools and things we've already discussed. So this is, but the, but the idea here is, and you mentioned it already that knowing things are out there so that when the need arises or when, you know, at some point, there will be this moment where you say, okay, now it makes sense to look into that thing that I heard about, right? Now it makes sense to investigate whether or not this will actually match that, that this thing is actually going to solve a problem that I have better than what I was doing before. And I think the, I think the word that we need to use more often as developers is literacy. We want to become experts in everything that we touch rather than literate in a bunch of things and experts and a few things. And this is something that is so important because if I'm literate, for example, I don't do a lot of SysAven work. We use a lot of services and whiteboard, we use a lot of services that are, that are kind of offloaded from us because we had too many headaches from trying to be Linux SysAven's basically. So there are some really good services out there, you know, for example, Linode is a sponsor of Developer Tea. So there's plenty of reason to go and learn enough about Linux so that you can be literate with it. You don't have to become an expert in BASH. There's no reason to go and, you know, work for, you know, 30 hours trying to memorize everything that you need to memorize for BASH to be a BASH programmer. Like that's probably going to be irrelevant to your career. Could you gain something from it? Sure. But really what you're talking about becoming is literate enough so that you can maneuver in that arena, right? So you know, I've taken a couple of days to learn Haskell, for example, right? I've taken a couple of days to learn a little bit of elixir. And I know I'm literate enough with these things that if somebody mentioned something about them, I can translate that information in a way that's meaningful. I can actually have a conversation. And so when a meat arises, that there's tools that I have at least a surface level literacy of, when that need arises, I have a better way of saying, you know what? I think I know something that could solve this. And this is also something, you know, as you're working on a, for example, a front end project or something. If you find yourself doing the same thing over and over and over, for example, right? Or if you find yourself writing very similar code over and over and over, or if you find yourself wishing that something were different, it's possible that there is a tool to make it better, right? You don't have to go and find that tool ahead of time. You can be on the lookout as you're going through a pro, like a project and exactly what you're saying, Chris, that moment you experience a need and you have to be like in tune to what a need is. And that's kind of what I'm saying. Maybe that's what I'm circling around with all of this. Knowing what a need is is really kind of the key. If we're trying to solve problems we don't have, that's wasteful. That's going to be that rat race you're talking about. But if we can clearly identify when we have a need, now we have a reason to pick up a tool. We're using to seek out a plug-in or a new framework or whatever. But until we experience that, we're really just trying to fill a need or solve a problem that doesn't even exist. Yeah, absolutely. Thanks so much for listening to today's episode. The first part of my interview with Chris Ferdinandi. There is another part of this interview coming up in the next episode of Developer Tea. Make sure you subscribe and whatever podcasting app you use if you don't want to miss out on future episodes, including that episode. Thank you again to Linode for sponsoring today's episode of Developer Tea. Remember, you can get started on Linode for as low as $5 a month. They have high memory plans, tons of great Linux server options for you to choose from. Go and check it out, spec.fm slash. Linode used the code Developer Tea 2017 to check out for $20 worth of credit. Thank you again for listening to today's episode. Until next time, enjoy your tea.