In today's episode, I talk with Chris Ferdinandi! Check out his stuff at gomakethings.com Today's episode is brought to you by Linode. Linode Provides superfast SSD based Linux servers in the cloud starting at $5 a month. Linode is offering Developer Tea listeners $20 worth of credit if you use the code DEVELOPERTEA2017 at checkout. Head over to spec.fm/linode to learn more about what Linode has to offer to Developer Tea listeners .
In today's episode, I talk with Chris Ferdinandi! Check out his stuff at gomakethings.com
Today's episode is brought to you by Linode. Linode Provides superfast SSD based Linux servers in the cloud starting at $5 a month. Linode is offering Developer Tea listeners $20 worth of credit if you use the code DEVELOPERTEA2017 at checkout. Head over to spec.fm/linode to learn more about what Linode has to offer to Developer Tea listeners !
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, it's JavaScript, but writing code that isn't reliant on an external dependency. And we're going to be talking about that in today's episode. My name is Jonathan Cottrell. 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 he's created a lot of projects, some of which you may actually know about. So 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 and 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. But first, I want to open up with a question that sometimes I leave till the end of the podcast. And it's a question I like to ask all of my guests. I think it's a really important question. And one that really, if you're a developer, just a side note, if you're a developer and you're wondering a good question to ask a potential employer, this may be a good one in a one-on-one interview. But this question is one that I got from a really close friend of mine at work. And it's very simple. What do you wish more people would ask you about? Ooh, that is a really good question. And it's probably my favorite question of all time. And I've literally never been asked that before. So I don't even really have like a canned answer. So yeah, I guess for me, just kind of generally, well, I guess there's two things. The first is Pixar. I love Pixar. I love Pixar. I love Pixar. I love Pixar. I absolutely love them. I could talk about them for days. Favorite is WALL-E. Least favorite is The Good Dinosaur. I feel like you're probably in line with a lot of people on that. You're not the only one. Yeah. And 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. No, it's one of those. It just like in it. On its own, it's probably an OK movie, but like under the umbrella of Pixar, it's a disappointment just because it doesn't live up to their normal. Awesome. But, you know, specifically to kind of like my work and that sort of thing, some variation of why shouldn't I use a JavaScript framework? Because like right now, JS frameworks are all the rage and people act like you can't even build a basic website if you're not loading. You're just going to be living in React or Angular or something like that. And you can do so much without any of those things. And I feel like that's particularly relevant when I start thinking about beginning developers or, you know, beginners, new developers. If I were trying to just get into this now, I would feel so incredibly overwhelmed. You know, when I learned, it was relatively easy to just open up a text editor in a browser and start coding. you can totally do that today too, but all of the tutorials out there make it sound like, um, like that's an impossibility. Um, so I just, I don't know. It's the kind of thing where, um, I feel people are really focused on tooling and, um, I'd love to have more conversations about anti-tooling or untooling or just like doing things without, without tools. Yeah. Yeah. So, uh, it's interesting you mentioned this. I started learning web development, um, in the earliest days of jQuery when jQuery and prototype and MooTools were all kind of still running a race together. Um, they were all kind of equal, equal partners in the JavaScript library worlds that they weren't frameworks. We didn't use the term framework, uh, for, for JavaScript libraries back then, because most of the stuff that you did was, uh, was going to be, first of all, relatively specific to the site that you were, uh, running. So, um, I, I, I, I, building at the time, right? Uh, secondly, it's going to be like, you know, you want infinite scroll or you want, you know, this one particular type of thing and you go find a good jQuery plugin and pop it in and basically you're done. Right. And so there wasn't a lot of this, and this was obviously before one page applications and, but that was, that was still kind of on the horizon. There were people who were making one page applications using jQuery and I remember the same, like very similar discussions then of do you, it was very early when this, this kind of started the, do you need jQuery kind of discussion, right? And that has continued, uh, right up until today. I mean, there's, there are people who still ask, who are still asking this question and you're one of those people and you and I were going to talk about this because I think this is really important, uh, uh, for web developers and a large number of people who are listening to developer T are in fact, web developers, not just, uh, uh, not, not other types of software, but front end developers, for example. So we're going to talk about, we're going to talk about some of that stuff today. Uh, so, so that's the thing that you want to talk about the most, right? This is, you know, JavaScript frameworks, we can very easily write that off as not a big deal, but with all of this stuff that's going on in our, in our lives, this is still something that, that comes to the front of your mind. Uh, when, when someone asks you a question like, what do you, what do you want to talk about? What do you wish more people would ask you about? Why does it matter so much to you that people, uh, think about JavaScript this way, or, or I guess a better way of, of asking that question is why, why is it so important that, um, a new developer coming in, uh, that they don't join this job, what you call the JavaScript rat race? Why is this, this so important? Yeah. Well, and you know, it's one of those, I don't, um, well, there's a couple of reasons. Um, so I don't, um, I don't necessarily hate these tools. Um, I, um, I, I dislike the overuse of them for a couple of reasons. Um, the first is that it's super alienating because most, or a lot of tutorials you read these days start with, um, some variation of, open up terminal in command line, run NPM, install these eight packages, and then, um, make sure you install Babel and run your compiler to transpile JSX into, you know, real JavaScript. And it's just like, it's really kind of alienating and overwhelming. Um, uh, I guess the second reason for me is, um, uh, you've got a whole generation of, um, and I'm, God, I'm going to sound like kind of a, you know, I'm going to sound like a, you know, a, you know, old man yells at the clouds right now, but, um, you've got this, this, this generation of developers who came up with, um, the notion of the web as an application platform. Um, whereas, you know, I, and I think you too, Jonathan kind of came up, um, with the idea of the web as a document sharing tool. Um, you know, it's obviously way more than that. And, but like, if that's kind of your mental model, the way you think about the web is fundamentally different. Um, you know, you, you think about as this, this thing that gives everybody in the world access to every kind of piece of knowledge you can possibly amass. And, you know, if you think about it as an application, you, 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. Um, I've heard a lot of people, um, kind of make this argument around like, oh, your browser doesn't support this feature. Just upgrade browsers are free. You know, it completely dismisses people who are in developing areas and are stuck on really bad hardware or, you know, corporate users who can't upgrade their browser for some reason. Um, or, you know, uh, low income people, um, not necessarily in developing nations who are stuck on old computers that are running, running some archaic version of windows that they can't afford to upgrade. Um, you know, and, uh, it's, it's a little bit tangential, but I feel like kind of the, the, the frame. framework mindset feeds into this, this, the web as an application and the way you approach development is, is just totally different around that. Um, so I guess, I guess for me, it's also partially a moral thing. Um, but, uh, but yeah, you know, like I, I don't think there's anything wrong with learning frameworks. Um, I, I learned on jQuery before I moved over to the vanilla stuff. It sounds like you did too. Um, but, um, I just, I, I think these days, a lot of the stuff that people are like, Oh, you need a framework for that. Like you, you don't need a framework for that. And in a lot of cases, it's just as easy to do it without a framework or easier. Um, and, uh, and you know, those, those are the kinds of conversations, I guess, I guess I like to have, um, uh, yeah, particularly with beginners, just cause I get a lot of like 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. Um, and, uh, and there is a more sane way to do things. And, and this is, this is a man, this is such a important thing that I want developer T listeners to, to capture. Um, a lot of people who listen to the show are new developers, which is the type of people that you've, you've mentioned, uh, this being important to, but the, the developers who are listening to the show, a lot of people have exactly what you identified as this fear of missing out, uh, beyond that, um, you know, even as a relatively seasoned developer, when I try to get web packs set up, sometimes I want to pull my hair out, right? Like it's, there's so many tools, uh, and there's so many new tools and the tools that you were using even last year are probably being, replaced. Uh, 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. You know, for example, uh, you, you may have started, uh, developing, uh, for iOS using objective C and then now, you know, that's pretty much out the door and you have to move to Swift at some point in the future, or, or I don't know, maybe they've deprecated it officially. I don't know. Um, so, so there's this, this idea that we have all of these tools and that keeping up is so important and you know, that everyone else who's doing this understands these tools. And sometimes, uh, quite honestly, the tool is really hard to understand. Um, and, and just because, you know, you feel like you're the only one that doesn't understand it. You're probably not, you're probably not the only one that doesn't. And by the way, uh, you're probably not by a long shot. There's probably seasoned developers who don't understand that tool very well. Um, there's probably people who, uh, 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, to capture those moments of, uh, of the light bulb going on. Um, I'm actually taking a course in machine learning on Coursera right now. Uh, really, really interesting stuff. Um, that's, that's saying, putting it very lightly, uh, very interesting, obviously, you know, a big part of our future as developers. Um, but there's, 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. And it's wrapped in a lot of language or a lot of, you know, documentation or, or, uh, you know, formal notation and, uh, there's all this stuff that's wrapping around it, but getting down to the core of it, you know, it's, that's what that thing is doing, right? For example, you, 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, right? Like that's at least that's the way that my light bulb moment was that that happened in my brain, right? I realized one day that I could, use gulp and I could access a bunch of JavaScript NPM packages and I could run it from the command line and I could do that, you know, on a project by project basis, I could create these configs and stuff like that. Right. Have you had some of these similar kind of light bulb moments that you feel like, you know, even, even as a seasoned developer, these tools, uh, that, that we're kind of discussing right now, that the, the, the light bulb moment is a way to run it from the command line and I could do that, you know, on a project by moment kind of clarified what that tool is for. Uh, that's question number one. And then question number two is, um, how does this extra layer, this kind of indirection is kind of difficult to understand. How does that impede the learning process for say a young developer? Yeah, no. So it's, um, it's twofold. And the, the reason I, I think I know I'm getting old is I tend to, um, when new kind of stuff comes out now, instead of just being like, oh yeah, that's awesome. And embracing it. I, um, I very immediately kind of viscerally reject it, um, for, for quite a while before eventually coming around and gulp was, was absolutely one of those things for me. Um, yeah, I was a code kit user for a long time and I was too. And I, it was awesome. Code kit is still an amazing tool, but, um, 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 unobscured 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 CodeKit 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, you know, like, static sites to WordPress is the best to, oh, no, actually, we're using static site generators again. And you know, Yeoman is the one Oh, no, not Yeoman. 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's like bailing to jump ship to. And, you know, and then it was like, do you remember grunt? Like grunt? Oh, yeah, absolutely. 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 end side, you know, it was like you said, like the new tools, jQuery and prototype, like they, they fought out for a long time before jQuery 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. And now, 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, they may not be the cool kid anymore. But but they are here forever. Yeah, yeah, Angular, as much as I kind of personally detest the way Angular works. 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, 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, you know, and you had some questions in there that somewhere along the line of my rambling, I am, Oh, no, that's, that's fine. I forgot, but Not a problem. But yeah, I just, I don't know, like, for me, that's, that's kind of, 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. And, you know, for me, like when you know the fundamentals, like knowing vanilla JavaScript, knowing really good CSS, like you can carry those over into learning new things, learning new frameworks, learning SaaS. I know a lot of people are into like post CSS now instead of SaaS. You know, less was like a big thing before SaaS kind of dominated. You know, like if you know kind of those core skills. Like they just, they carry you through the ebb and flow of these tooling popularity cycles. 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 tools more than methodologies and approaches. All about the tooling. 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 longtime 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. Their plans actually are the best. Are the best price per dollar in terms of memory, in terms of RAM. So this is really, really important for performance. They also have SSD servers that the Linux is sitting on top of. So it's going to be super fast 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, 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 Linux server for as low as $5 a month that gets you onto a one gigabyte of RAM server. $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. That's $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 of RAM, you're going to get $50 a month. So if you do the math, that's a third of the year that you don't have to pay anything for that server. That's $20 worth of credit. Go and check it out. Spec.fm slash Linode. Make sure you use the code developer T 2017 at checkout if you want that $20 worth of credit. Thank you again to Linode for continuing to sponsor developer T. So on the flip side, because I don't want developer T listeners or anybody else who hears this show. I don't want you to think that. You know, there's always a good reason to question. 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 jQuery. And you know that. You have jQuery 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 jQuery? By default, you've answered that over and over. No, I don't want to start without jQuery. It is a reasonable idea to ask yourself why. Right. Why? Why are you doing things the way? 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, jQuery was the 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 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 jQuery before I learned JavaScript, you know, however bad that may be. And, you know, what it came down to was, you know, it was before 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 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 jQuery as a default. But now 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 NPM altogether. 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 bytes, quite honestly, that your users would spend to download it. And it's not worth the brainpower 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 a genius. I sound like I'm down on tooling, but I actually use a lot of kind of tools in my development. And you make them too, right? You've got a whole list of open source tools that you've made. I do. And like, so I'm like all in on Gulp. I love SAS. Just can't. Although the as CSS variables become like variables are one of the big things I use. I use Gulp for and as native CSS is able to handle that better. I may see my relationship. I may see my clients 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 and 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 those tools or libraries. You know that I think that for me is kind of where I 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. Neither of those is a good idea. Right. It doesn't. You know, there is a reason why, you know, Google is one of the companies that's putting out some of these tools. And they're they're very successful. They have very successful projects. You know, obviously some of the smartest engineers in the world. And and they're 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. As time invested. It's you know, it's 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. It was a guest from ThoughtWorks, I think, a 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. Yeah. 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 am 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. Yeah. But for me, the motivation was almost exclusively around Gulp. Yeah. And kind of making it easier to kind of push my open source work. So, you know, there was a handful of things I wanted to do that were just not I 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 boilerplate. Yeah. For getting started with it. So I just, I took those and kind of ripped them apart, and, and, and learned by doing, I guess, but, but, yeah, it was, it was 100% pragmatic, and Sarah Swadon talks about this quite a bit. For those of you who aren't 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, she does a lot of other stuff, too. front end developer out of, um, Lebanon. And, uh, um, she's best known for her work with SVG, although she, uh, 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, um, 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. Um, you know, so like I, for example, I'm aware of CSS grid, um, though I, I don't know how to actually use it myself because I haven't had a need for it on a project yet. Um, same thing goes with Flexbox. Actually, I've been getting by on like old school CSS grids for a long time. Um, but you know, like the, the thinking there is, so, you know, be aware, like casually aware of developments in the industry, but, um, you know, until you actually like really need something on a project, like you could burn yourself out chasing every new, nevermind framework and library, just all the new features that come out in any given year that browsers support these days. Um, 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. Um, and I, I can remember, um, you know, so Jonathan, I think you're about the same age as I am. I don't know if you remember, um, do you remember the show Beakman's world? Um, it was kind of like, uh, that does sound familiar, a science-y analog to Bill Nye, the science guy, but it was like way more, um, kind of like edgy than Bill Nye. Um, 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 don't know. It was just really bizarre. But like, I remember one of the things they always talked about on the show is that like being a scientist wasn't about having all the answers. It was knowing the process. It was like, I don't know, I don't know. I don't know. Knowing the process to find them out. And I, I really like to think that that carries over quite well into kind of the, 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 and being like, oh, they want all this stuff. And I don't know any of those things. Um, 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, it's knowing how to learn the things when you need them. Um, yes. And, uh, and for me, that is such a much more valuable skill than actually knowing all this stuff. So, um, 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, that fundamental JavaScript, you can pick up a framework. Um, 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. Um, you can learn new tools when they come out more easily. Um, 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. Um, but you know, like that aside, um, you know, like just kind of developing your approach to picking up stuff when you need it is important. Um, the other, I guess the other thing for me too, is I am, I'm very consistent with my tool chain. So I don't, um, I know some people, I love to kind of try a new tool, every project they work on. Like I've, 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. Cause there's this new tool that just came out that I'm dying to use. And like, if you really genuinely enjoy that, that's that's like, that's great. But, um, you just like, you can blow so much time learning the new thing that could be spent, like actually making stuff. And, um, 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, um, or you're working, you know, for an employer or anything like that, um, you know, even if you're working for yourself, um, you know, but you're making money on the thing you're building, like your, your time is so valuable. And, um, 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. Um, yeah, yeah. Seems a little odd. Like I know tons of people who still use grunt because they invested in it. They've, they've got all their stuff set up and it still works, you know, it's not, 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. Who cares? 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, so anyways, I'm sorry, that was a really long rant. It's good. It's good. Yeah. No, I am, I am very, um, very kind of consistent. And I'm almost like, uh, reluctant about my, my tool setup. Um, I have a very small kind of set of, of tiny modular things I like to use. And I, uh, I, I don't really like to deviate from it much. Um, like even with gulp, like I've now got, um, my latest version of my gulp build, um, up at the top of my gulp file.js has a, like a settings variable that has a whole bunch of like, um, like, um, like, um, like, um, like, um, like, um, like, um, like, um, like, um, like, um, like, um, 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, uh, you know, so like, if I don't need one of those things on a particular project, I just changed the variable under settings, but I don't in any other way have to touch my tool chain. Um, right. 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, is, 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, uh, they get wrong in one direction or the other, um, because the, the culture is that there's so many tools and things we've already discussed. Um, so this is, but the, but the idea here is, uh, 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. Uh, now it makes sense to, uh, 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 words that we need to use more is literacy. Um, we, we want to become experts in everything that we touch rather than literate in a bunch of things and experts in a few things. And this is something that is so important because if I'm literate, um, for example, I, I don't do a lot of sysadmin work. We use a lot of services and whiteboard. We use a lot of services that are, that are kind of, uh, offloaded from us because we had too many headaches from trying to be Linux, sysadmin. Basically. So, um, uh, there, there are some really good services out there. You know, for example, uh, Linode is a sponsor of developer T. 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, uh, to be a bash programmer. Like that's, that's probably going to be irrelevant to your career. Uh, 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 now I've taken a couple of days to learn, uh, a little bit of elixir. Um, and I know I'm literate enough with these things that if somebody mentioned something about them, I can, I can, you know, translate that information in a way that's meaningful. I can actually have a conversation. And so when a need arises that those tools that I have at least a, you know, like a surface level literacy of when that need arises, I, 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, you know, 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 progress, like a project and exactly what you're saying, Chris, that moment you experience a need and you have to be too 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. Now we have a reason to seek out a plugin or a new framework or whatever. You know, but until we experienced that, we're really just trying to figure out how to do that. And that's kind of what I'm saying. And that's kind of what I'm saying. And that's kind of what I'm saying. And that's kind of what I'm saying. And that's kind of 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 in 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 a free trial. You can get started on Linode for as low as $5 a month. They have a free trial memory plans, tons of great Linux server options for you to choose from. Go and check it out spec.fm slash Linode. Use the code developer tea 2017 at checkout for $20 worth of credit. Thank you again for listening to today's episode. And until next time, enjoy your tea.