If 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 talking about you know, we're continuing to talk a little bit about doing 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 Cutrell. We'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 you, 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. 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 you know, another thing that you've discussed in something that you like talking about that you sent me a head 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 Validates, Smooth Scroll, Gum Shoe, Atomic. You're listening to this podcast and you know of these things. Chris is the 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, you know, how can you keep this many projects going and how does it contribute to your career? But also, I'd love to know this 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 mean, a previous life was an HR guy. And 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 to my career. 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 and 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're considered hiring people. But for me personally, the honest truth is, it's just had a tremendous impact on my career. So I, I've for a long time felt comfortable 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 want to call them plugins. They were just like these little like script decomponent 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 like really simple kind of like toggle tab type thing. And you know, I 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 to 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 than I'm like, oh, I'll just I'll start throwing this thing. 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 their cruders to reach out, you know, it's the they're not the kind of, usually jobs that people 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 professional other than like, I don't know, talking to some past employers who were 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 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 animate 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, you know, 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. And 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 in the 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 plugin where 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, just because of this one pull request, I went and updated all my other scripts to match. Very cool. And so over time, this body of work is just really swell to something bigger than I ever, really imagined or planned. And to your point, you start to get some really some interesting things. You get beginners who are really struggling to figure out how to use it, sending you either emails directly or tweets or issues on GitHub saying like, I don't know how to use this. Can you help? You get the really, you get some some some some great bug requests, but you also get a 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. 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 assholes about open source. There's this feeling of entitlement that like I as the open source developer, oh, you something. And I 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 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 I just for me is 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 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 trolley kind of feature requests. So like I could probably like just word dump them. But like if we want to pick this apart like a little 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 one back 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 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 is this the sense that you know somewhere somehow there's a company backing every open source project. That's what it feels like probably to an incoming developer who has never really worked in open source and doesn't see you know how how could I possibly do this. Well, they must have funding right. This is this is a reasonable when I say reasonable. I mean this it would make sense to come to that conclusion with the level of detail that some open source projects actually have. So so thing number one here I think is to recognize that people like Chris are pretty much normal people right like overall you're 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 contributing to the community in a meaningful way. In the same way that Developer Teaou 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 the other side that I want to talk about with you that's a little bit harder to to nail down is there is for people who do have open source projects you know there is the social contracts that you've kind of entered into with other Developer 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 get 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 project up and you know follow kind of some rules of the road here where I'm not going to I'm not going to break it you know I'm not going to take it down without letting you know I'm not I'm not going to change the you know a minor version number and change the entire API of a plug-in that 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 expressed 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 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 feel very strongly about semantic versioning and about like really like being dogmatic about adhering to the the major minor patch kind of approach. Well let's cover that very briefly for people who are not who may not be familiar. You can cover it because you're going to be more precise with your definition of semantic version. 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 one dot one dot two 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 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. So 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 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 tiny little number at the end there the patch numbers you know like one dot one dot whatever those are for me and 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. The fix to that in my opinion is to provide a deprecation and 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 that you can add comments here I just want to interject that for anybody who is doing that right now maybe instead you can alias the 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 that log message that says hey this is 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 has changed names right and this is this is how the big 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 have never done that though have seen it numerous times I usually just issue the major version bump and yeah yeah call it day but well I mean for these larger things in the documentation but I am yeah exactly yeah like I like what's changed kind of sections and things like that but but yeah so that's you know the 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 that it's the kind of thing that like it's just not it's not compelling enough that like enough people would use it that I really want to like add a feature in or honestly even I just don't have time I can usually provide someone with a relatively quick way that they could just kind of do it themselves without having to modify the code like you can just kind of bolt this into what's already there and and that for me has been just incredibly useful at helping kind of manage the influx of like feature requests and things like that that come in because I can I can just close them really quickly without actually adding them into the code which right yeah yeah yeah yeah they are an I don't know what some people but like at the cognitive overload of having a whole bunch of issues open 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 I just I can't ignore it so I just turn off all notifications on my phone except for like texts and calls but um but yeah so and you know the truth is if I have no So, no inclination to actually implementing the feature anyways, like that's the way to go. And so the way I do this is twofold. The first is I love callbacks. So I include callbacks all over the place in my scripts. And I know some people prefer custom events that people can hook into. But, you know, at the end of the day, the thing you're trying to achieve is the same. You're providing people with hooks throughout your code that they can connect into to do additional stuff. Basically, ways of passing functions to be called at a particular point in time. Right? That's really what's happening. For example, one of the things I've gotten before from folks is with smooth scroll. People will sometimes use it for, like if they have just a single page site, their header navigation, they'll make those anchor links that animate down. 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. And it's one of those things that I didn't really want to add into the core script because it just would have been really kind of like clunky, you know, which would have been another option and more bloat in the code. The thing was already starting to swell because of the easing patterns and a few other kind of features. So now with callbacks, that's something people can 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't because there's a callback. Right. 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 a 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 other world of kind of stuff that 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 when you click on a link, it also updates the URL structure to kind of preserve the navigational history so you can use the forward and back tabs to jump from anchors. Every now and then I get requests from people who I think are using some specific frameworks that use hashtags for their internal kind of workings. And they want to they want to operate without without the hash changes and 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. And take advantage of all the heavy lifting I've already done. Sure. Yeah. So like those kind of two things callbacks and then making a lot of stuff public like a lot of those internal functions public instead of private. 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. Sure, so that makes total sense. Yeah. So that's super, super helpful. The, you know, the other piece here is 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 write JavaScript and just a little unfamiliar with some of this stuff. So I've, I've really gone out of my way to write developer friendly documentation. It's like heavily prescriptive rather than like I see a lot of, a lot of scripts that are just like, you know, like, 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 plug in might treat it where it's very, just really, really detailed and specific. And if you ask questions that aren't properly covered in the read me, I'll answer them and then I'll add it to the read me. And I've 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. That's a fantastic. That's me. I'm doing your documentation is circling around what it should be at that point. 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 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 one of the things that Linode does, for example, they have 24, 7 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 maybe you already use actually rely on Linode already, for example, Creative Commons, WP Engine, some of these companies rely on Linode already for their 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 Tealistener. Head over to Spectatifims 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 the stuff still applies. Go and check it out. Spectatifim. Search Linode. Make sure you use the code Developer Tea2017. Check out if you want to get that $20 worth of credit. Thank you again to Linode for continuing to sponsor Developer Tea. You mentioned something that I think is really important for us to do in our projects as well. That is the idea of, this is actually a good software design. 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 I'll use it. Which basically says, I'm going to put a placeholder here, kind of like a bookmark, a moment where a tagging where you can come in and put your code that you want to run. So by the way, it will receive this stuff. This is the idea of dependency injection as well. I may be butchering a little bit of the actual perfect definition of dependency injection. But the spirit of this is the same. That is this defensive coding. You want to defend against a future scenario that you don't yet know will happen. 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 common scenarios, do some common customizations, and then get out of there. The fact that you have good documentation is 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. This is an area that I think a lot of developers are just not good at documenting their stuff. I take pride in the fact that I've gotten pretty good at that. I feel good about that. Other piece of this too, and it's something I cover in my readmeas whenever possible, is really just 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 comes along with this. GitHub, they have you included 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. I'm pretty specific about the fact that I need a reduced test case and that if you don't provide one, I'm probably just going to close your issue without comment. 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. That's helped a lot too. It's been like the idea that you can do customer research and you probably will get a bunch of positive responses from almost any idea that you present. Very few people want to say that your idea is bad. That's kind of a difficult thing to tell someone, especially someone that you don't know very well. If somebody comes up to you on the street and says, hey, I've got this idea for this thing and they say something that's totally irrelevant to you and then they explain it and it's somewhat comprehensive, but 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, the moment that you say, okay, I've got this idea and it's ready to go and I just need funding. If you want to buy in now, 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. The idea here is everybody has ideas. He has suggestions, not everyone wants to invest to see those suggestions come true. That's exactly the principle that you're talking about. You point people towards the contributing document and if they don't have enough fortitude to actually go and follow the rules, they probably didn't really care that much anyway. Yeah, absolutely. Every now and then you get someone who literally just doesn't know any better and then I feel a little bit bad because they're maybe just learning or it's their first time GitHub can be an intimidating place. Sure. I try not to be a jerk about it. The only other piece here that I really did want to talk about with the open source thing is trolls. It hasn't happened to me once but there's been one or two situations where someone has started to get really abusive on a GitHub issue where I said I wasn't going to support their feature and they were trying to convince me that it was important. I was like, yeah, I hear what you're saying but I'm not going to do it because I have two dozen projects and you've already got this free code and it's GitHub. If you really want this, you can fork it and add it yourself. That's totally fine. Don't care. That's my license is very permissive. You can do whatever you want. I just shut it down. I block, I close the issue and prevent anybody from commenting on it further. I've got a point now where my own mental health and sanity is just more important than other stuff. I'm very comfortable with that. I used to get a lot of people asking questions about stuff on Twitter and I now just funnel everybody to GitHub issues. I have my one source, same thing with email. When stuff comes in on email, I will sometimes offer a paid if you really want one-on-one help by email kind of thing but my inbox is not your personal GitHub issues directory where you can just get that back and forth one-on-one stuff. I'm polite about it but I kind of tell people for time and sanity reasons. I need you to open it up here. Surprisingly, three quarters of the people I send that message to never open an issue on GitHub. They just disappear. Which is strange. I think this trolling discussion, it comes down to, there's a couple of things at play. One, this is your own space. In the same way that if somebody were to come up to your desk and harass you at work, at work at least they're giving you money to harass you. 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 at a coffee shop and somebody came up to you and was about to throw a coffee in your face because you wouldn't do something they wanted you to do for free. That's insanity. It's totally insane and you have all of the personal right to avoid that scenario. It's not about 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 somebody paying you respect because you deserve to be lifted. I'm not talking about basic human respect. Somebody's cursing you on the internet over and over because you aren't going to make your scroll plug in, 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, even if you pull down your code one day altogether, you still don't deserve abuse. You may, maybe that wasn't the best call, but you don't deserve for someone to break you over the calls over something that you did online. For those of you who feel guilty or you feel the weight of the world in your shoulders because of trolls or because of these issues that are sitting unmanaged because you barely have time to eat dinner, right? Take a moment, step back and imagine the world as if GitHub didn't exist. Imagine the world as if these various online platforms didn't exist. I do this exercise with my wife relatively often. I ask her to imagine the world for a moment without the social platforms that we use or that our parents use. What would we have done without those things? It clarifies a little bit of some of the weird behaviors that we write off as okay. It clarifies in our minds, hey, maybe somebody not liking a photo or whatever, we don't participate much on Facebook. But somebody not paying attention to your thing on social media, maybe that's not as big of a deal as it feels like. In that moment, if you can remove yourself from the situation, maybe that is actually just a website at the end of the day. If you're feeling the weight of the world, Chris, I feel like you've gotten a good handle on this. Would you say that it makes sense to take a step back, take a break, that burnout discussion is really important, but take a break, take a step back, act for five minutes as if GitHub wasn't even there. Yeah, no, absolutely. I have definitely been times where I've kind of stepped away and I just really kind of ignored GitHub or my projects for a little while just to kind of get some perspective or just take a break. It's totally cool to take breaks. Absolutely. This has been a fantastic discussion, Chris. Thank you so much for your time. 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. If you could give developers just one piece of advice, 30 seconds of advice, what would you tell them? Oh, geez. Let's see, so if I had to pick just one piece of advice to give all developers, it is you don't have to know everything. It is totally okay to not chase after every new thing that comes out or not be an expert in everything. I would pick the one or two things that you really want to focus on and just try and be aware of all the other stuff. I'm sure there's a much better way to say that, but I'm running low on caffeine at this point. This is such a important. Hopefully people have heard the theme going over and over, but really, truly, if you are a new developer and you're confused, join the club, you're going to be confused, at least 50% of your career as a developer. The important thing is not to give up just because you're confused. Sometimes, confusion is just the pointer towards the next thing that you need to do. 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. Where can I point people to find out more about the things that you have written and the things that you're sharing, your mentoring? Where can I point them to? Yeah, absolutely. Thank you. GoMakeThings.com is the easiest and best way to find me, links to all my social stuff, my daily newsletter and all sorts of other goodness. There's a whole bunch of freebies under the open source link, which is all the things I make, which should be hopefully interesting to some folks. Awesome. GoMakeThings.com. Get 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 quickly. I guess I should. It's C-Ferton Andy, which you can find that in the title of this episode. C-Ferton Andy is Chris's GitHub. Yeah, there's a reason why my website is go make things and not my name. Long a lot of hours, so. Yeah, great. Good stuff. Chris, thank you again for your time. No, thanks, Jonathan. I appreciate it. Thank you so much for listening to the second part of my interview with Chris, Ferton Andy. 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. If you have over 400 episodes, you can go and browse tons of topics, tons of guests. 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 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 Tea. 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 Tea 2017 to get $20 worth of credit. By the way, if you want to join a conversation with other Developer Tea listeners, head over to spectrum.chat. That's spectrum.chat. And sign in with your Twitter account. You can join us. We used to be on Slack. Now we're moving our community over and having these more topical discussions. It's more structure. This is a product that is being primarily driven by Bryn and Brian. These are the two co-founders of spec.fm, by the way. So we found it spec together and they are driving creating this brand new product, fantastic product 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.