Hey everyone and welcome to Developer Team. My name is Jonathan Cotrell and in today's episode we're going to be talking about folklore. When we say that one of the hardest things in computer science is naming variables, it's actually not an exaggeration. Now it may sound like it's kind of a joke, right? It sounds kind of sarcastic that naming a variable is really difficult. But the reality is most of your code really is names. Names of messaging, names of variables, names of classes or functions or methods, names of objects, all of these things depending on what language. At the end of the day, when you write code, you may write code in language you may write code in language you may write code in language you may write code in language you may write code in language you may write code in language you may write code in language you may write code in language you may write code in language you may write code in language you may write code in language you may write code in language you may write code in language you may write code in language you may write code in language you may write code in language you may write code in language you may write code in language you may write code in language you may write code in language you may write code in language you may write code in language you may write code in language you may write code in language you may write code in language you may write code in language you may write code in language you may write code in language you may write code in language you may write code in language you may write code in language you may write code in language you may write code in language you may write code in language you may write code in language you is really what it comes down to. When we talk about maintainable code, we're talking about code that can be passed from my hands to yours or from your hands to another developer's, and it can be continued forward. You don't maintain code by putting it into a silo, and you don't maintain code by only having one developer that continues to work on that code. And the most common response that I hear from this is that if this is my own solo project, if this is my project and my project alone, then what's the problem? I don't have any plan of passing this on to another developer, and so why should I care about whether or not another developer can understand my code? And the simple answer is, there are very many things that you will build today that you will forget even as soon as you start working on it. And I think that's tomorrow, but certainly as soon as one year from now. And if you plan for this project to go any longer than even a month or even a week, then you should probably consider yourself in the future as if you are a different developer. So in that respect, the working memory that you have of a given piece of code, of how it works or what it is doing, it has a termination time, or maybe a better way of explaining it, it has an expiration. Right? Anything that you remember, the specifics of a given piece of code, especially if it's procedural or if it's not particularly relevant to the overarching thing that that project is doing, if it's something small, a small feature set, or if it's particularly clever code. This is the kind of stuff that becomes very difficult to remember why you did what you did, how you did what you did. Right? Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right.! Right. Folklore happens when you have a single developer or maybe a group of developers who have worked very closely together or are working in tandem next to each other talking out loud when they're developing code. Now, why does folklore happen? Well, the signs of folklore in your code, that's what we're going to talk about in just a moment. Folklore happens because you're talking about the code. You're having discussions about the code. And that may be internal dialogue that you're having with yourself, or it may be notes that you're taking on a notepad that don't necessarily get shared with other developers. The folklore happens about the code. It's kind of the meta discussion around the code. And this may seem to be a very simple aspect. It may seem very natural, actually. You will have discussion about code. You will have internal dialogue. You will have arguments between you and another developer, positive arguments, constructive criticism. You're going to have all of these things that swirl around in the meta space of that code. So we're going to talk about how this actually affects your code, how it actually affects it in a bad way. We're going to talk about how to eliminate folklore right after this quick sponsor break. Today's episode is sponsored by Rollbar. With Rollbar, you can catch code errors. Before your users do. That sounds like a pretty good idea, right? Dealing with errors sucks. We know dealing with errors sucks. You know, we deal with errors at Whiteboard, for example. We can have an error that occurs at 4.55. And no one else has the responsibility to deal with that error but us, right? So it's not really fun to have those things spring up on us. I'm recording this episode on a Friday. It's not really fun to have an error spring up on us at 4.55. And in fact, that has happened to us even as soon as today. Relying on users to report errors, that's when this becomes really frustrating, right? We have users reporting errors at all times, and they expect them to be fixed pretty much immediately. Rollbar works with all major languages and frameworks to eliminate this guesswork. So you can start tracking production errors in your code in minutes. You integrate Rollbar into your existing code. You integrate Rollbar into your existing workflow. And you send errors. You send these alerts to Slack or to HipChat. And you can link up your source code from GitHub or Bitbucket or GitLab and convert errors into issues in tools like Jira or Pivotal Tracker, Trello, all the things that you're already using pretty much. And some of the big customers that are using Rollbar include Heroku, Twilio, Kayak, Instacart, Zendesk, Twitch. These are massive, massive companies. And they have errors just like you do. But they rely on Rollbar because it helps them catch these errors that they didn't catch when they were building the software. They didn't catch it in their tests. You know, they have a lot of good practices. Even the best practices. This is kind of a side lesson here. Even the best practices are not going to catch every error, right? So relying on users to report errors is not a good idea. Digging through log files. Trying to debug the issues yourself. And 111. Alerts are flooding your inbox. This is not good. And Rollbar helps to eliminate it. Go and check out what Rollbar has to offer to you today. Head over to rollbar.com slash developer T. Rollbar.com slash developer T to learn more about what Rollbar has to offer to developer T listeners. One of the sources of errors that you're going to experience is a misunderstanding of the intention of your code. A misunderstanding from one developer to another. A misunderstanding of the intention of your code. Now this is why naming is so important, right? It's one of the reasons my naming is so important. Because a name carries a lot of value. A word carries a lot of value. A title carries a lot of information. The attributes on your class instance, for example. Those carry a lot of information. It's important to name things properly. But here's the thing. Naming is so hard because we all have context. And we have to learn what a name actually means. And this is where folklore comes in. And so I'm going to give you a very simple way to determine if your project has folklore kind of helping it succeed. Right? If there's folklore necessary in order to understand how to work on your project. If you, as a developer who is working on the project, if you have to explain what a class does. If you have to say, we're calling that X. And really what we mean is Y. Right? Or if you have to sit down and go through why you did a certain thing a certain way. Because the code is not necessarily clearly explaining that. Or there's no documentation explaining that. Or if quite literally you have to tell a story about your code for it to make sense to other developers. You literally have folklore that is supporting your code. Now folklore is quite simply stories. Right? This is stories that are passed on between people vocally. Typically handed down. And so what you need to do is evaluate your projects. And determine at what points has folklore entered your projects. When you have to say, we're calling this object. Let's say you have subscriptions in your application. This is something I dealt with actually today. If you have to say something like, we're calling this a subscription. But really what it is, is X. Right? We're calling it a user. But really what it is, is a computer. If you have to say these kinds of things. Then there's evidence that your code needs to change. Your code needs to reflect the reality without telling a story. So catch yourself. Go through the project that you're working on. The next time that you are explaining something to another developer. Find a way to capture how you are explaining it. If you can capture in your code what you are explaining. Then your code becomes much more maintainable. This is kind of a heuristic. Right? If you are trying to tell a story to explain why a given piece of code is the way that it is. Try to tell that story in the code itself. If it's impossible for some reason. If there's something weird happening in an external API, for example. And you have to check what's going on in that API in order to be able to respond to it. Then you need to document that weirdness. You need to document whatever that folklore is. It becomes. It's important that it is taken out of the conversational mode. And put into a concrete mode. And eventually work to get your code to the place where it describes. Most if not all of the folklore. Most if not all of the stories. The etymology of that code. So that you can look at the code and understand. Oh, this isn't a subscription object. This is X. I hope this has been enlightening for you. Hopefully. As you are. As you are moving through new pieces of your code. Or looking at old code that you wrote. Or collaborating with other developers. You can identify when folklore has entered into the picture. And identify how to eliminate it. Thank you so much for listening to today's episode of Developer Tea. Don't forget Rollbar is going to help you eliminate errors before your users see them. You can integrate Rollbar into your existing workflow. You can send error alerts to slack or hipchat. And you can also use Rollbar to automate errors. And you can also use Rollbar to automate errors. You can actually connect it to your source code directly. Tons of things you can do with Rollbar. Remember, you can get the bootstrap plan for free just because you are a Developer Tea listener. Head over to rollbar.com slash developer tea. That's rollbar.com slash developer tea. And you can get the bootstrap plan for free. Thank you again to Rollbar for sponsoring today's episode of Developer Tea. Thank you for listening to today's episode of Developer Tea. If you don't want to miss out on future episodes, make sure you subscribe on whatever podcasting app you use. You can reach out to me on Twitter at at developer tea. You can email me at developer tea at gmail.com. Hopefully you've heard all these things before. We would love to hear your feedback for Developer Tea. I need to hear from the audience that this show is made for. And you all are so good about getting in contact with me with questions. And I would love to hear more and more of this feedback. And you can leave a review. On iTunes, of course. And you can also always contact me once again at developer tea at gmail.com. On Twitter at at developer tea. On Twitter at at Jay Cottrell. Always love hearing from you all. Thank you so much for listening. And until next time, enjoy your tea.