Have you ever been burned out to the point of wanting to quit? I don't mean wanting to quit your job. I mean wanting to stop working on a project. You burn out physically, you burn out mentally, and perhaps most importantly, you can burn out emotionally. And that's what we're talking about in the second part of my interview today with Chris Ferdinandi. We're talking about burnout. We're talking about open source projects. We're continuing to talk a little bit about writing code without relying on external resources, relying on other libraries. That's what we're talking about in today's episode. Hopefully you didn't miss the last episode, part one of this interview. Go and check it out if you missed it. You can find it at spec.fm. My name is Jonathan Cottrell. You're listening to Developer Tea. By the way, we used to talk a lot about our Slack community, which is still running. And it's always going to be free for those of you who want to join that. But we actually have moved our community over to Spectrum. This is a brand new product that brings in some of the things that we like about Slack, but it actually helps us have better conversations. Go and check it out. You can sign up for free at spectrum.chat. And you can find the Developer Tea frequency over there. And you can find tons of other great content. It's not just the spec community. It's a bunch of other people who are using Spectrum. Go and check it out. Thank you again for listening to today's show. I'm going to get straight into the second part of the interview with Chris Ferdinandi. Okay, so we're going to switch gears here. And another thing that you've discussed and something that you like talking about that you sent me ahead of time is this discussion on open source sanity. You have quite a few projects that you have contributed to, things that you've created for yourself, things that you're the sole creator of. So how many? I mean, quite a... I'm just scrolling down this page. Lots of projects here. For example, JavaScript Validate, Smooth Scroll, Gumshoe, Atomic. If you're listening to this podcast and you know of these things, then Chris is your guy. He's the one who started some of these projects. So I'd love to talk to you about this. First of all, how do you manage to have this... How... How... How... How... How can you keep this many projects going? And, you know, how does it contribute to your career? But also, I'd love to know the stuff that you've mentioned before to me, and that is, you know, dealing with the ongoing feature requests. I mean, I can only imagine you have multiple feature requests, bugs, and trolls that are hitting your inbox every single day with this many projects. Yeah. So it's... There's a few things. So the first is... It was... It was never... I never intended to have this many open source projects. I, in a previous life, was an HR guy. And... Wow. Yeah. In the process of making a career change, I just started kind of throwing stuff up on GitHub as a way to kind of, I guess, store it and get it out in the wild. And it has, without a doubt, probably been one of the most important things I've done. I always feel bad saying that because I know that open sourcing stuff tends to be primarily a white male thing. And there's all sorts of arguments to be made around kind of the types of people who have the time to engage in these kinds of projects, et cetera. And so I always feel a little kind of sensitive to recommending open sourcing stuff as advice to kind of grow your career. And I get a little defensive when companies require open source projects before they'll consider hiring people. But for me personally, the honest truth is it's just had a tremendous impact on my career. So I've, for a long time, felt comfortable with CSS and HTML, but JavaScript was always kind of an area of unfamiliarity for me. And that's where the open sourcing really started. I kind of... I threw together these really simple jQuery... I'm going to call them plugins. They were just like these little like scripty component things to do things like show and then... Or hide and then show again some sort of like content when you click a link or, you know, like really simple kind of like toggle tab type thing. And, you know, it grew from there. I did like five or six of those. And then over time, I started like converting them from jQuery into vanilla JavaScript. That became a thing I wanted to learn more about. And then it turned into this... This thing where like every time I would do something new for like a client project, I would just open source it because I benefit tremendously from the open source community. And it makes my life so much easier that I'm like, oh, I'll just... I'll start throwing this stuff. You know, it's kind of like a like pay it forward, give back to the community kind of thing for me. Sure. Yeah. What started to happen, though, is being so active in open source started opening up new career opportunities for me because recruiters kind of troll GitHub looking for stuff. And then when you apply for jobs, even if it's not kind of someone found you. And to be honest, most of the recruiters who reach out, you know, it's the... They're not the kind of... They're usually jobs that people are having a tough time filling for a reason. But like you apply for a job and you're able to point to some stuff. And like when I worked in HR, there's no real good way to evaluate whether or not someone's going to be a good HR. Other than like, I don't know, talking to some past employers who are never going to say bad things about you unless you did something terribly egregious. And, you know, like it's not like there's like tangible work you can show to prove that you know what you're doing. But like with code, it's so much different. You can show someone something you wrote and they can kind of look at it and evaluate it. And with open source, you have this like really public recorded. Body of work that people can kind of look at and be like, oh, you know, here or she really knows what they're doing. So in that regard, it's just it's been tremendous. The other thing that's been super helpful is some of my biggest jumps in my own learning have happened because of community contributions to some of my projects. So for example, smooth scroll is a script I wrote that just kind of animates scrolling to anchor links. So instead of like you click a link and it jumps you down the page, it'll kind of... Nicely animate your way down there much in the same way that like if you're on a smartphone and you tap the top of the browser window, it like scrolls you back up to the top. And it used to just be this very linear kind of thing where like it would move at the same speed the whole way down. And then someone submitted this pull request to add a whole bunch of easing patterns, which was absolutely amazing because I had no idea how to bolt that in. It was the thing I wanted to do, but I just couldn't figure out. I didn't even ask for it. Someone just did it. And it just it made the script so much better. And then one day on a whim, I got a pull request from my friend Todd Motto, this JavaScript developer out in the UK who's really big into Angular now. And he like just kind of completely ripped my script apart, like just tore it to pieces and converted it from just kind of this very, very basic... script into something that was more akin to like a plug in where you you initialize it and pass in some settings and things like that. And that then opened up this whole new world to me because now I went from just writing these really simple scripts to writing proper, like well architected components. Just because of this one pull request, I went and updated all my other scripts to match. Very cool. And and, you know, but so. So over time, this body of work is just really swelled to something bigger than I ever really imagined or planned. And to your point, you start to get some really some interesting things. So you get you get beginners who are really struggling to to figure out how to use it, sending you, you know, either emails directly or tweets or, you know, issues on GitHub saying like, I don't know how to use this. Can you help? Yeah. You get you get the really you get some some some great bug requests, but you also get our bug reports, but you also get some really terrible ones like it's not working. That's the whole you know, that's the whole issue. You you get people who really want you to like customize it. You know, they're asking how you would customize it to do a certain thing, but they want you know, like they want you to write custom code for for free. You get the people who have a feature request. And then get really angry when you don't want to implement it. Yeah. You know, that's one of my favorites. And there's been a few times where I felt really burnt out. And I know I'm not alone. Like there's a whole kind of subset of blog posts around like. Right. Yeah. Open source burnout for a very good reason, because people can be real. And, you know, I feel free to edit this out. But like if it's, you know, like you have a language policy or something, but like people can be real asshole. They may have signed off onension and they may have signed off onension and they may off onension and they may have signed off onension and they may have signed off onension and they may have signed off onension and they may have signed off onension and they may have signed off onension and they may have signed off onension and they may have There's this feeling of entitlement that like I, as the open source developer, owe you something. And I used to feel really guilty about that. I've gotten to a place where I've realized that like I've poured on some of my like my plugins, like I've poured hundreds of hours of my personal time creating software that's tested across like a variety of different like use cases, browsers, edge cases. Tons of like bug fixes and things like that. And and I'm giving it away for free. Like if I built this for a client, you know, it would it would cost potentially thousands of dollars and you're getting it for free. And I have a very permissive license. Like I use MIT on pretty much everything because I want people to be able to use the scripts, however, makes the most sense for them. Like I've been able to with so many other people's projects. And like I now feel comfortable. Kind of internalizing this idea that I don't owe anybody anything with my projects. Now, I've seen people take this to the other extreme where like they almost become assholes about being asked for clarification on how to use it. Like I put it out there. And if you can't figure it out, like tough for you. Like, I don't think that's just for me. It's like someone who's deeply invested in the front end community. Like, I don't think that's the right approach either. That's that's kind of an asshole move to like. Like, if you're going to put. Put it out there and kind of do it in a way that makes it seem like you want people to use it, like at least enable people to be able to use it. So I've developed a set of strategies that help kind of circumvent all of these issues that I used to suffer from the beginners who don't know how to use it. The like obnoxious bug requests or like bug reports that tell you nothing. The trolly kind of feature requests. So. So, like, I could probably like just word dump them. But like. If we want to pick this apart like a little at a time, we could do it. Like, I don't know, Jonathan, what's the best way to kind of dig into this? Because there's a lot to unpack here. Well, I think there's so there's a couple of questions and we can we can kind of debate back and forth about this, because I think this is, you know, this is certainly contentious subject for for developers who, like you, have contributed a lot to the community. And then the community turns around. It doesn't really you know, first of all, understanding that people. Like Chris, while they do benefit from creating these open source projects, it's not just an easy road. Like they're just like you. They have other things going on in their life. They have a lot of difficulty sometimes fixing bugs that are actually sent in. And there there is this the sense that, you know, somewhere, somehow there's a company backing every object. At the same time, they may have taken the plunge and they may have taken the plunge and they may have taken the plunge and they may have taken the plunge and they may have taken the plunge and they may have taken the plunge and they may have taken the plunge and they may have taken the plunge and they may have taken the plunge and they may have taken the plunge and they may have taken the plunge and they may have taken the plunge and they may have taken the plunge and they may have taken the plunge and they may have taken the plunge and they may have taken the plunge and they may have taken the plunge and they may have taken the plunge and they may have taken the plunge and they may have taken the plunge and they may have taken the plunge and they may have taken the plunge and they may have taken the plunge and they may have taken the plunge and they may have taken the plunge and they may have taken the plunge and they may have taken the plunge and much normal people, right? Like, overall, you're leading a pretty normal developer, you know, a lifestyle, most likely, and you get to work on really cool stuff. And you also are contributing to the community in a meaningful way. In the same way that developer T, you know, I'm basically in my house recording this podcast, right? Some people might have this vision of me in, you know, a radio studio somewhere, but that's just not the case, right? In the same way that they might have the vision of you pushing up code every hour, like a machine, and that's just not the case either. So that's, you know, humanizing the open source developer, that's important. The other side that I want to talk about with you, that's a little bit harder to nail down, is for people who do have open source projects, you know, there is this social contract that you've kind of entered into with other developers. That if you, you know, you have this project that, for example, I saw that Apple on swift.org, they used one of your projects, right? Yeah, that was pretty rad. You have these awesome, you know, pieces of code out in the wild. And now people, whether you like it or not, are relying on that code, right? They, they have some sense of, okay, there's a tool that I'm going to reference. And, you know, maybe I'm going to pull it in automatically via Git. And then, you know, what if Chris one day, and this is not something that I'm saying you would do, but certainly this has happened in open source projects. If you just decided, okay, I'm done, I'm shutting this thing down, or I'm going to break the API, and websites all over the world are suddenly going to be broken if they bring in the new version, you have a little bit of this social contract responsibility. Obviously, you know, there's no legal binding or anything like that. But this, this idea that, hey, I've agreed to put this in the open source project, and I'm going to do it. And I'm going to do it. At the same time, you may have signed off on bringing this project up, and, you know, follow kind of some rules of the road here, where I'm not gonna, I'm not gonna break it, you know, I'm not gonna take it down without letting you know, I'm not, I'm not gonna change the, you know, a minor version number and change the entire API of a plugin, that would be insane, right? So let's talk about, first of all, how you manage to follow that social contract, without totally killing yourself with responsibilities that, you know, take you away from your entire, life, you know, for hours on end every day. Wow, that's actually so that's an interesting place to take it to. I don't know, I am. I've always felt really comfortable with the kind of the software is distributed as is without any kind of express warranties piece of the MIT license. It's for me that then that really helps me sleep at night. I it's not to say I ignore bugs or don't care about them. Because I do I actually get really like, when there's a meaningful bug in my code, I really want to fix it right away. But I you know, the minimum is I'm, I'm comfortable with the fact that like, my code is, there's a possibility that it's going to have a bug and not work properly for you. You know, so even even with Apple, like I've, I think I've made improvements since they incorporated my script on Swift. And they're still using kind of an old version or something. But, you know, you touched on, you touched on semantic versioning, which is super important. I, I feel very strongly about semantic versioning and about like, really like being dogmatic about adhering to the the major minor patch kind of approach. Let's cover that very briefly for people who are not who may not be familiar. Uh, you can cover it because you're gonna be more, more precise with your definition of semantic versioning. Sure. Yeah, no. And you know, like, I've heard people describe it different ways. But you know, you've got with semantic versioning, you've got your your three number versioning approach. So it's, you know, like, number dot number dot number. So you know, like version 1.1.2, or something like that. So kind of that that first number is the major, major version number. And I always treat that as a breaking change. So if I'm going from version one to version two, it means something about the way the script is going to work. And then I'm going to have to do a little bit of a little bit of a change. So if I'm going from version one to version two, it means something about the way the script either works, or the way you you use it, the way you initialize it or interact with it, is changing in a way that if you upgrade it to this version, any old code you have, that's like initializing it the old way or doing whatever is going to break or work in an unpredictable way. That allows you to kind of think ahead about that when you go to upgrade, you know, there's there's ways when people are kind of loading these scripts in dynamically from like NPM or something like that, they can, they can say they only want to like, they want to skip major version upgrades, like only work within kind of that that minor, minor subset there. The second number, so you know, like, let's say one dot something that, you know, that's something when that jumps up. That, that for me is where my non breaking feature improvements come in. So if I add new functionality that wasn't there before, but it doesn't in any way break the old stuff, that's a minor version increase for me. And then that last number that that tiny little number at the end there, the patch numbers, you know, like one dot one dot, whatever, those are for for me, and for most people, those are where kind of like the bug fixes and security hole patches and things like that come in. So if someone reports a bug with the existing thing, I haven't added any new functionality. I haven't broken any backwards compatibility, I'm just issuing an update that fixes something that was broke with the previous. Version or broken. And, and I know people use kind of different terms for those three numbers and might describe them a little bit differently. But that's generally the approach with most projects. So the way it's how it's supposed to be. I've seen a lot of people do breaking changes as a minor version increase. And that drives me nuts. Yeah. It doesn't happen all that often. But it happens with enough frequency that you're kind of like, why even bother with semantic versioning, if you're going to do that? Yeah, I mean, I think the biggest fix to that, in my opinion, is to provide a deprecation and a match, like a alias, basically. And so most of these things are like, you're removing a method, or, you know, somehow changing the way a method works in a really, you know, in a way that breaks code that may have been relying on the way it used to work. It makes sense to me. You can add comments here. I just wanted to interject that for anybody who is doing that right now, maybe instead, you can, alias, the methods, if you're, you know, I'm using Ruby language. If you're in JavaScript, you can create functions that basically act as wrappers around those other functions, and then provide like a console.log message that says, hey, this has changed in the next version, it's going to go away entirely. But we wanted to let you know in advance in the console, since you're probably looking here anyway, this method has changed names, right? And this is how the big libraries do it. They let you know in some way that only shows up to the developer in a development environment. Absolutely. And I am admittedly, personally, have never done that, though have seen it numerous times. I usually just issue the major version bump and call it a day. Well, I mean, for these larger things in the documentation, but I am. Yeah, exactly. You know, like, I like what's changed kind of sections and things like that. But, but yeah, so that's, you know, semantic versioning is awesome. The one of the bigger things that's really helped me a lot is, as I've started to structure my code in a way that lets users bolt in these pet features, without touching the core code. So now when I get feature requests that have an interesting use case, but it's kind of like an edge thing, it's the kind of thing that like, it's just not, it's not compatible with the code. So I'm gonna useensionensionensionensionensionensionensionensionensionensionensionension can i can just close them really quickly without um actually adding them into the code which right yeah i know some that annoys some people but like um at the cognitive overload of having a whole bunch of issues open um just drives me nuts it's tough yeah yeah it's it's almost like like having like a whole bunch of like unread email notifications like i just i can't ignore it um so i just turn off all notifications on my phone except for like texts and calls but um but yeah so and the truth is like if i have no no inclination of actually implementing the feature anyways like that's the way to go and so the way i do this is is twofold um the first is um i love callbacks so i include callbacks all over the place in my scripts and i know some people prefer like custom events that people can hook into but you know like at the end of the day the the thing you're trying to achieve is the same you're providing people with right! hooks throughout your code that they can connect into to do additional stuff basically ways of passion passing functions to to be called in uh at a particular point in time right that's really what's happening for example um one of the things i i've got gotten before from folks is like with smooth scroll people will sometimes use it for like if they have a just a single page site um their header navigation they'll you know they'll make those like you know just like a single page site and then they'll make those like you know anchor links that animate down um but sometimes they have like an expanding collapse menu for those things and they want it to collapse before the scrolling happens and i got like five requests five separate requests for that feature um and it's one of those things that i didn't really want to add into the core script because it um it just would have been really kind of like clunky and it just would have been another option and more bloat in the code and the thing was already starting to swell because of the fact that i was like oh i'm gonna click here and click here and click here and click here and click here and click here and click here and click here and click here and click here and click here and click here and click here and click here and click here and click here and click here and click here and click here and click here here and click here and click here and click here and click here and click here and click here and click here and click here and click here and click here and click here and click here and click here click here and click here and click here click here click click click click click click click click click click click click click click click click click click click click click click click click click click click click click click click click click click click click click click click click click click click click click click click click click just kind of do themselves. So like, you know, there was this thing where people were like, oh, you know, I want to be able to close that expanded navigation menu before you start scrolling. And now they can, because there's a callback. So they can just pass in a function to close it. And then the script just runs and does its thing. So that's one piece of it. And then the other is, I used to just kind of have my scripts be these self-contained things that ran. And now I expose a whole bunch of internal functions publicly. So using smooth scroll again, as an example, the function I have internally that actually powers the animation, it runs automatically. Like when you click an anchor link that you've selected, you know, as one you want smooth scroll to work on, it calls that function and does a bunch of stuff and then animates the scroll. But you can also call that function, yourself from another script if you want. So, you know, I've exposed it as a public, a public function. You can pass in the anchor you want it to scroll to, or a specific point on the page, like literally just like a number of pixels down value you want to scroll to, whatever. You can pass in some additional options and settings that overwrite the defaults if you want. And doing things like that opens up a whole nother world of kind of stuff that you can do. You wouldn't think of when you make those available and then you start getting these like feature requests and you're like, oh, I'm not going to support that. But let me show you very quickly how you could just bolt that in. And, you know, I can usually cobble together in about five minutes, like a little example that shows people how they could do it. For example, one of the things that I often get with smooth scroll. So like right now, the way it works is when you click on a link, it also updates the URL string. So you can see that it's not just a single link, you click on the title, click on the title, click on the title, click on the title, click on the title, click on the title, click on the title, click on the title, click on the title, click on the title, click on the title, click on the title, click on the title, click on the title, click on the title, click on the title, click on the title, click on the title, click on the title, click on the title, click on the title, click on the title, click on the title, click on the title, click on the title, click on the title, click on the title, click on the title, click on the title, click on the title, click on the title, click on the title, click on the title, click on the title, click on the title, click on the title, click on the title, click on the title, click on the title, click on the title, frameworks that use hashtags for their internal kind of workings. And they want to, they want it to operate without, without the hash changes. And, um, doing so would require some really fundamental rewrites of my code, but using that animate scroll function that I've made publicly available, they can effectively just bypass, like, don't use my scripts kind of internal click function stuff. They can just kind of write their own really small version of smooth scroll. Like that kind of customizes that behavior, but take advantage of all the heavy lifting I've already done. Um, sure. Yeah. Yeah. So like those, those kinds of two things, callbacks, and then making a lot of stuff public, like a lot of those internal functions public instead of private, um, just knock out, I'd say like 90% of the feature requests I get, which is great. And then you tend to get some of the same ones over and over again. And I just link people back to the old issue. So I don't even like, you know, have to like answer it twice or anything. It's just like, Oh, someone already asked for that. Here you go. Um, sure. So that makes total sense. Yeah. So that's, that's super, super helpful. Um, the, um, you know, the other piece here is, um, you know, like a lot of the, a lot of the other kind of issues you'll often get is like, I don't understand how this works kind of things, especially from people who are like you and I used to be like, you know, beginners just learning how to, how to write JavaScript and just a little unfamiliar with some of this stuff. So I've, um, I've really. Yeah. Really gone out of my way to write developer friendly documentation. Um, uh, it's like heavily prescriptive, um, rather than like, I see a lot of, a lot of scripts that are just like, um, you know, like, um, uh, you know, NPM install package name and initialize it and you're good to go. And it's like, well, that, that, you know, that's really overwhelming. Whereas I'm like, here's how you, here's how you add it to your site. And then here's how you actually go about initializing it. And here are all of the specific options you can add in. Like I treat it like, like a commercial plugin might treat it where it's very, um, just really, really detailed and specific. And if people ask questions that aren't properly covered in the readme, I'll answer them and then I'll add it to the readme. Um, and I found the more I do that, the fewer questions I get from beginners about this sort of thing. And those are kind of almost entirely gone away now, which is great. Um, that to me tells me I'm, I'm, I'm doing documentation is circling around what it should be at that point. Yeah. Yeah. Yeah. I'm getting the documentation right, which is good. Today's episode is sponsored by the fantastic Linux server provider. Linode. Linode has so many features that it's hard to list them all in an ad read. So we try to cover some new things, uh, in these, in these episodes because they've been a sponsor for a long time and we want to cover some things that are a little bit different. So. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. They have 24, seven customer support teams. They also have a powerful API and deployment stack scripts, a CLI. You can manage your servers through these APIs and CLIs. They have a 99.9% uptime guarantee and some massive companies that you may be, you already use, uh, actually rely on Linode already. For example, creative commons, a WP engine, some of these companies rely on Linode already for their services. server needs. So go and check it out. They're providing all of this stuff, by the way. You get access to this 24-7 customer support team for your server system for only $5 a month. That's an incredible deal, even if you just paid $5 a month for the 24-7 customer support. But on top of this, that's $60 a year, by the way. On top of this, they're also giving you $20 of credit just for being a Developer T listener. Head over to spec.fm slash Linode to learn more about what Linode has to offer. Of course, we've talked about other features in other episodes. All of that stuff still applies. They still have the 40 gigabit internal network. You're still going to be on SSDs. You're still going to have the availability of high memory plans. All this stuff still applies. Go and check it out, spec.fm slash Linode. Make sure you use the code DEVELOPERT2017 at checkout if you want to get that $20 worth of credit. Thank you again to Linode for continuing to sponsor Developer T. You mentioned something that I think is really important for us to do in our projects as well, and that is the idea of... This is actually good software design, right? But the idea of this dependency injection, which is really what callback provision is, you're giving this moment in your code where, hey, if this thing is here, then you're going to be able to do this. And you're going to be able to do this. And then I'll use it, right? Which basically says, okay, I'm going to put a placeholder here, kind of like a bookmark, a moment where, like a tagging, where you can come in and put your code that you want to run. And also, by the way, it will receive this stuff. And this is the idea of dependency injection as well. And I may be butchering a little bit of the actual perfect definition of dependency injection. But the spirit, the spirit of this is the same. And that is kind of this defensive coding, right? You want to defend against a future scenario that you don't yet know will happen. And that's what you've done by creating these... You could call them convenience if you want to, but really, it's expandable. It's what a plugin really is intended to do. It allows you to bring in some functionality and then expand that functionality to some kind of future scenario. And that's what you're doing. And that's what you're doing. And that's what you're doing. And that's what you're doing. And that's what you're doing. And that's what you're doing. And that's what you're doing. So the fact that you have good documentation, your documentation is kind of judged by how many times people ask how to do the most common things. That's how you can say your documentation is good or bad. Yeah, absolutely. Absolutely. And yeah, this is an area that I think a lot of developers are just not good at documenting their stuff. So I take pride in the fact that I've gotten pretty good at that. So I feel good about that. Another piece of this too, and it's something I cover in my readmes whenever possible, is really just kind of setting expectations ahead of time around support and how to ask questions, how to report bugs, so that you avoid a lot of the annoying junk that kind of comes along with this. So I am, in GitHub, they have you, like, if you include a file called contributing, they'll automatically link to it whenever someone creates a new issue. In my experience, people don't read it. But it is useful to have. So I'm pretty specific about the fact that I need a reduced test case. And that if I'm not able to do that, I'm going to have to do it. And I'm going to have to do it. And if you don't provide one, I'm probably just going to close your issue without comment. Right. Yeah. And like, the truth is, I usually do comment, but the comment is usually to just link them to that specific section of the contributing guide. And say that if they do that, I'll reopen it. Sure. And, and that's helped a lot too. I have... It's kind of like the idea that, that, you know, you, you can do customer research, and you probably will get a bunch of positive responses for almost any idea that you present. Very few people want to say that your idea is bad. That's, that's kind of a difficult thing to tell someone, especially someone that you don't know very well. Right. So if somebody comes up to you on the street and says, Hey, I've got this idea for this thing that, and they say something that's totally irrelevant to you, and then they explain it, and it's, you know, somewhat comprehensive, but, you know, ultimately, you don't really care. You're not going to tell them, that sounds like a bad idea. You probably won't even tell them, I don't care. Most likely, the average person is going to say, yep, sounds like a good idea, because that's the lowest friction way to move forward. However, the moment that you ask for money, right, the moment that you say, okay, I've got this idea, and it's ready to go. And I just need funding. So if you want to buy in now, like Kickstarter style, I'll take your money. And then the moment it's done, I'm going to give you the thing, you're going to get a much worse response, right? And so the idea here is, everybody has ideas, everybody has suggestions. Not everyone wants to invest to see those suggestions come true, right? And that's exactly that, like this principle that you're talking about. You, you point people towards the contributing document. And if they don't have enough fortitude to actually go and follow the rules, well, they probably didn't really care that much. And so that's the idea here. And so the idea here is, you point people towards the Yeah, absolutely. Yeah. And that's, I mean, every now and then you get someone who literally just doesn't know any better. And, you know, then I feel a little bit bad, because they're maybe just kind of learning or it's their first time, like GitHub can be an intimidating place. Sure. So I try not to be a jerk about it. But the only other piece here that I really did want to talk about with with the open source thing is, is trolls. So I've, it hasn't happened to me once, but there's been like, I don't know, I don't know, I don't know, I don't know, I don't know, I don't know. But there's been like, one or two situations where someone has started to get like, really abusive on a GitHub issue where like, I said, I wasn't going to support their feature. And they were trying to convince me that it was important. And I was like, Yeah, I hear what you're saying. But like, I just, I'm not going to do it. Because I have like two dozen projects. And you've already got this free code, and it's GitHub. So if you really want this, like you can fork it and add it yourself. Like, that's, that's a good thing. That's, that's totally fine. I don't care. Like, that's, my license is very permissive, you can do whatever you want. And I am, I just shut it down. Like I, I block, I close up, you know, close the issue and prevent anybody from commenting on it further. Like I just I, I have a point now where like, my my own kind of like mental health and sanity is just more important than sure, absolutely other stuff. And I just I'm very comfortable with that. I used to get a lot of like people asking questions about stuff on Twitter. And I now just I funnel everybody to GitHub issues. Like I just I have my kind of my one source, same thing with email, like when stuff comes in on email, like I, I am, I will sometimes offer like a paid if you really want like one on one help by email kind of thing. But like, you know, like, my inbox is not your personal GitHub issues directory where you can just, you know, get that back and forth one on one stuff. And I'm like, I'm polite about it. But I just, you know, I kind of tell people just, you know, like for time and sanity reasons, like I, I need you to open it up here. And surprisingly, like three quarters of the people I send that message to never open an issue on GitHub. They just disappear. Right? Yeah. Which is just strange. Yeah, I you know, I think I think this trolling discussion, it comes down to there's a couple of things that I think are really important. One, this is your own space, in the same way that, you know, if somebody were to come up to your desk, and harass you at work, you know, at work, at least they're giving you money to harass you, right? Like, if you work in that kind of scenario, I don't, by the way, let me be very clear. The people at my work do not harass me. If you do work in that kind of scenario, I recommend you get out. But, certainly, if you were just sitting, you know, if you view this, like if you were sitting at a coffee shop, and somebody came up to you, and was, you know, about to throw a coffee in your face, because you wouldn't do something they wanted you to do for free. That's insanity, right? That's, that's totally insane. And you have all of the, the, you know, personal right to avoid that scenario. So it's not about, you know, this project is mine, and I'm going to protect it. That's not even a question here. It's your personal space, your personal rights, and respect, and basic respect. I'm not talking about, you know, somebody paying you respect, because you deserve to be, you know, lifted up on a pedestal. I'm talking about basic human respect. If somebody's cursing you on the internet over and over, because you aren't going to make your, your scroll plugin work the way they want it to. You have the right, and I would say even the responsibility, quite honestly, to take care of yourself, right? To protect yourself from abuse. And you don't deserve to be abused, no matter what you've, even if you pulled down your, your code one day altogether, you still don't deserve abuse. You may, maybe that wasn't the best call, but, but you don't deserve for someone to, you know, to rake you over the coals, over something that you did online. So, for those of you who feel guilty, or you feel the weight of the world on your shoulders because of trolls, or because of these issues that are sitting on, you know, unmanaged because you're, you barely have time to eat dinner, right? Um, take a moment, step back, and imagine the world as if GitHub didn't exist. Imagine the world as if, you know, these, these various online platforms didn't exist. You know, I do this exercise with my wife relatively often. Um, I ask her to imagine the world for a moment, uh, without the social platforms that we use or, uh, that our parents use. And what would we have done, uh, without those things? And it, it clarifies a little bit of some of the weird behaviors that we kind of write off as okay. It clarifies in our minds, hey, you know, maybe, maybe somebody not liking a photo or, you know, whatever. We don't, we, we don't participate much on Facebook. Uh, but somebody not paying attention to your thing on social media, maybe that's not as big of a deal as it feels like, you know, in that moment, if you can remove yourself from the situation, maybe that is actually just a website at the end of the day. So if you're, if you're, you know, feeling the weight of the world, uh, Chris, I feel like you've gotten a good handle on this. I feel like you've gotten a good handle on this. I feel like you've Would you say that it makes sense to take a step back, take a break, that burnout discussion is really important, uh, but take a break, take a step back, act for five minutes as if GitHub wasn't even there. Yeah, no, absolutely. I, um, I, um, there've definitely been times where I've kind of stepped away and, uh, I just really kind of ignored, um, ignored kind of GitHub or my projects for a little while, um, just to kind of, I don't know, get some perspective or, um, you know, just take a break. Like it's totally cool to take breaks. Yeah, absolutely. This has been a fantastic discussion, Chris. Thank you so much for your time. Uh, I have one more question for you that I like to ask all of the developers who come on the show, all the guests who come on the show. Uh, if you could give developers just one piece of advice, 30 seconds of advice, what would you tell them? Ooh, um, geez. Uh, um, let's see. So if I had to pick, um, just one piece of advice to give all developers, um, it is, you don't have to know everything. Um, it is totally okay to not chase after every new thing that comes out, um, or not be an expert in, in everything. Um, I would, you know, pick the one or two things that you really want to focus on and just, um, you know, you know, you know, you know, you know, try and be aware of, of all the other stuff. I'm sure there's a much better way to say that, but I'm, uh, I'm, I'm running low on caffeine at this point. So, um, this is such a, such a important, and hopefully people have heard the theme going over and over, but really, truly, you know, if you are a new developer and you're confused, join the club. This is, this is, you're, you're going to be confused at least, uh, you know, 50% of your career as a developer. And, and the, the important thing is not, to give up just because you're confused. Sometimes, you know, confusion is just the pointer towards the next thing that you need to do. So your job as a developer isn't to know everything exactly what Chris is saying. I totally agree with that. It is to learn things constantly. And those are two very different scenarios. Yeah, absolutely. Chris, thank you so much for your time. Uh, where can I point people to find out more about the things that you have written and, uh, the things that you're sharing? Your, your, uh, uh, mentoring, uh, where can I point them to? Yeah, absolutely. Thank you. Um, so gomakethings.com is the easiest and best way to, um, to find me, um, links to all my social stuff, um, my daily newsletter and all sorts of other goodness. There's a whole bunch of freebies under the open source link, um, which, uh, just all the things I make, which should be hopefully interesting to some folks. Awesome. gomakethings.com. And of course, uh, get, uh, on GitHub, you can find Chris. I'm not going to spell out the username. I think you can get to the GitHub from the gomakethings.com pretty, pretty quickly. Uh, I guess I should, it's C Ferdinandi, which you can find that in the title of this episode. C Ferdinandi is, is Chris's GitHub. Yeah. There's a reason why my website is gomakethings and not my, my long with a lot of so. Yeah. Great. Good stuff. Chris, thank you again for your time. No, thanks. Nothing. I appreciate it. Thank you so much for listening to the second part of my interview with Chris Ferdinandi. Thank you again to Chris for coming onto the show. It was a fantastic time talking with you. If you are enjoying today's episode, if you enjoy the content that we create, make sure you subscribe and whatever podcasting app you use. We have over 400 episodes. You can go and browse tons of topics, tons of guests. Uh, we're continuing to make these episodes every single week. So make sure you subscribe. If you don't want to miss out on future episodes, and of course to go back and listen to the back catalog too. It's very easy to go and browse. Uh, if you keep that kind of in your subscribe list, thank you so much for listening. Thank you again to Linode for sponsoring today's episode of developer T an insanely good deal on Linux servers and incredible customer support, tons of features. Go and check it out. Spec.fm slash Linode. Use the code developer T 2017 to get $20 worth of credit. And by the way, if you want to get a free copy of this episode, please go to linode.com. And if you want to join a conversation with other developer T listeners, head over to spectrum.chat that's spectrum.chat and sign in with your Twitter account. You can join us that we used to be on Slack. Now we're moving our community over and having these more topical discussions there. It's more structure. Uh, this is a product that is being primarily driven by Bryn and Brian. These are the two, the other two co-founders of spec.fm, uh, by the way. So, uh, we found a spec together and they are driving, creating this brand new product, fantastic product, um, that facilitates incredible conversations from this community and other fantastic communities. You can discover new communities to join, go and check it out. Spectrum.chat. Thank you so much for listening to today's episode. And until next time, enjoy your tea.