 In this video I'm going to talk about the paradox of documentation, which may be a term that exists out there, or I may have just made it up, but either way I think it's something really important if you're someone who is writing software, or does anything software related, or honestly even if you're a teacher or something else, it's something you need to keep in mind. Now, what do I mean by the paradox of documentation? Well, I'll put it this way. Let me give you an example, in fact. Around a year ago, I put out what I call a mutt wizard. So I used to get all of these questions about the email client mutt. Now, mutt is a very nice program, very customizable, but it's somewhat difficult to set up, but a lot of people would like to have an email client in the terminal. So I made a wizard, after I figured out how to write, how to, you know, configure mutt. I wrote a wizard for auto-configuring mutt, not just for mutt, but for automatically setting up offline IMAP so you can have offline email on your own computer, don't need any kind of internet connection, and all of that is configured automatically. Otherwise it takes a lot of effort. So I wrote this wizard for people with the idea that I would get less comments and questions on my channel or by email about mutt if I put this out. Now, one thing that I realized very quickly is that this is not the case. Or I lose, there are some types of questions I get less of, but in general I get more and more questions, not mind you about specific things in mutt. But I started getting questions from more and more basic users who lacked more and more general knowledge or things that I took for as general knowledge. Meaning once I put this thing up on GitHub, I had all these questions about how do I actually download it from GitHub? How do I clone a repository? The script doesn't work, ends up they put it in the wrong directory, or they download one file instead of the entire repository, or they make other basic mistakes. So what ended up happening is that I put this thing out that actually made getting things done a whole lot easier for many, many people. But I ended up getting more questions because while I had put good documentation, in fact more than that I put out a wizard to make things easier for people. I got more questions because it was now that much more accessible to an even wider swath of people. So this is something I have to look out for and it's happened to me many times, it happens to other people all the time. That is if you are writing documentation or if you're trying to make accessing your software easy for people and you have a large audience, a lot of consumers. If your concern is making things easy for yourself, documentation is not a good investment. Now I'm not saying you shouldn't document your software, obviously you should, but if you are just swamped with emails and swamped with different concerns, it is a mistake to invest a lot of time in documentation unless you've just documented poorly and you want to fix some mistakes. But in general, if you make things more accessible to people, you will get more questions. Now you're still making the world a better place or whatever, but if you're thinking in terms of you getting stuff done, this will probably get in your way. And it's happened to me in multiple domains. I mean, obviously I put out, you know, my .files on GitHub as well. And of course I get many, many questions about that, but in fact I even, I mean as most of you I assume know, I have a script that automatically installs not just my .files, but configures a blank Arch Linux install, installing all the needed programs for them, setting up system settings, all that kind of stuff. You can get it at larbs.xyz, but I have this script that basically automatically installs all of my .files. So you would think that would make things even easier, especially considering once you've installed this, you have, you can press, you know, Super F1 to get a readme file. You can stream videos directly from my YouTube channel with another keyboard setup. I've documented everything. Does that mean that I get less questions about it? No, because now I'm at a point where, you know, someone who barely knows how to install Arch Linux, which isn't really that big of a hurdle to go over, but even someone who barely knows how to install Arch Linux doesn't even know how to install a program on Arch. They are now using my system and the more the number of basic questions I get has exploded since I've done this. So what I'm trying to say, you know, well, I will say there are some people who take the opposite approach. And honestly, I understand this now, but every once in a while I'll get some butthurt comments from people who go to Succlis's website. Now, Succlis has the opposite philosophy of documenting everything. For them, I mean, it's somewhat of an exaggeration, but the source code is the documentation. If you want to know what it is, know what this program does, read the source code. Maybe there'll be comments in there. You don't need comments, though. So, you know, Succlis has this opposite mindset, but I remember there's, I think, their site for DWM, their window manager, where they say one of the advantages of DWM is because there's no, you know, extensive documentation. There is a small and elite and knowledgeable user base, so there's no stupid questions. And I've had many people come to my channel said, that's so mean, Succlis, it's so mean to me. But until you've been on that other side, until you have been on that side where you are actually writing documentation and getting questions, you do not understand how tempting that is. It's not, it would be nice to just be able to write something, it'd be nice to be able to write and document something that the better you write and better you document it, the worse your life doesn't get. That was a very complex sentence. But what I mean is, if you're in my position, the easier I make things, the better, more efficient I make things, the more difficulty that is going to cause for my life. The more, the better documentation I give, the more confused emails I will get. And that's on, it's honestly like a law in my life. Now it's different for, I mean, if you have a project that has a bunch of people on it, and you don't have to deal with every question, I can understand, you know, you might avoid that kind of stuff. And again, the whole point is to make things easy and accessible. But if you, one thing that I've found is that making things easy and accessible only makes things more difficult for the person who's making them easy and accessible. And that's just, you either have to deal with it or you have to get to a point where, honestly, where I've gotten, where I have to ignore most of the emails that I get, some of them are perfectly good questions, perfectly legitimate intelligent questions, but yeah, there's such a quantity to them, it's hard to even manage. So anyway, I just wanted to throw this out at you guys. If you're a newbie user, please, you know, read the documentation. It's there for a reason. And, you know, a lot of people have put work into it. And most of the times, if you figure something out on yourself, it's much better. But I will say, if you're someone who has swamped with all the projects you're working on, and you're trying to minimize your workload, I'm not saying you shouldn't document your software, you should. But that, that is not going to make your life easier. If anything, if you are successful at documenting your software, it's probably going to make your life harder because your software is just going to be so great. It's going to be so easy to use that it's going to cause you a bunch of confused questions. So anyway, that's all I wanted to do. This would have been a Boomerance and Woods video, but as you can see, the wind is too intense and the audio wasn't recording right. So anyway, that's about it. And I will see you guys next time.