Hey everyone and welcome to Developer Tea my name is Jonathan Cutrell and today I'm going to be talking to you about not repeating yourself and how that's not always the best idea. Today's episode is sponsored by Code School. You can check out Code School at codeschool.com of course and I'll be talking a little bit more about them later in the show but if you want to learn how to code and especially if you are at the very beginning of your career or you're trying to learn a specific new topic go and check out Code School.com I'll be sharing a few more details about how to get some some incentives especially for Developer Tea listeners but I want to jump into today's topic and believe it or not it is actually kind of an advanced topic and it's advanced because so many times as young developers we here don't repeat yourself and this is good advice in general because it teaches us to turn things that we do over and over into reusable chunks of code. How many times have you for example if you're a Rails developer created a partial to hold part of your views and this is not just for Rails Developer There's partials and all kinds of frameworks but sometimes this isn't the best idea. Now this may send alarms off in your head you may be thinking that this is somewhat heretical if you if you follow this fundamental concept if you were taught very strongly to never repeat yourself but I encourage you to take a step back and start questioning some of the things that you learned early on in your career. There are certain things that you learned kind of the practical pieces of probably but you didn't learn the wise and also the exceptions to the rule so the rule here is not to repeat yourself but there are exceptions to almost every rule especially in programming and let's talk about a few of those exceptions for the don't repeat yourself or dry principle. But before we talk about those exceptions I want to say that especially if you're a young programmer that the rule don't repeat yourself once again is a good guideline in fact it is usually applicable. This is one of those scenarios where you have to know the rules in order to know when to break them. Like many of my episodes this one gained some inspiration from Sandy Metts. Sandy talks a little bit about when you should repeat yourself specifically Sandy talks about repeating yourself before you refactor your code and then once you refactor your code you can remove that repetition. So the whole idea of repeating yourself and when that is a valid practice rather than a bad practice is when you're trying to understand a given method it is much easier for you to repeat yourself in that moment and it's very easy to copy and paste code. So instead of trying to refactor as you go it makes much more sense to repeat some of the steps that you've made perhaps in another method in another place. And this is really the primary exception to the rule and that is repeat yourself when you're trying to understand your code. We have this misconception that we understand our code as soon as we write it or that we understand our code even before we write it but it is very likely that the only time that you actually understand your code is after you write it and after you've experienced a bug with the way that you've written it. So let's talk for a second about why that would be a problem if you don't understand your code as you're writing it. Specifically, if code is run twice then something is duplicated. Now I'm not saying the code specifically has to be duplicated but that the actual actions that are taking place happen twice. So by trying to refactor your code on the spot by trying to offset that code into a different location what you're doing is is creating an abstraction and abstractions are only well created in the refactoring process. So to summarize this point that Sandy is basically making whenever you are writing code if one piece of code mimics a lot of the functionality of another piece of code then in the process of writing that method or that data structure or whatever it is that you're writing it's perfectly fine for you to duplicate the code that you've already written in order to understand step by step what exactly is happening. This is especially important if you're doing something relatively complex and also if you're modifying the way that that code initially was working. So for example you're adding a step or perhaps you're changing a variable here or there. This process of seeing things in a more granular perspective of actually repeating the code and then taking a step back and comparing the two pieces of code that gives you a perspective on how to create the abstraction in a more efficient manner. How to create it in a more effective manner. If you'd like to read up a little bit more on what Sandy has to say about this subject once again I can recommend to you the practical object oriented design with Ruby and the principles that you learn in practical object oriented design from Sandy will carry over to pretty much any other language. And in fact I think that it carries over even into functional language programming. Sandy has a background in small talk but a lot of the things that you will learn when you read that book are certainly applicable as overarching concepts in other languages as well. Now while we're on the subject of learning and reading I want to talk about today's sponsor code school. Code school is full of incredible content not only for young developers or people who are beginners but also for much more experienced developers and that's because they have just a super wide variety of content. You can learn things like Ruby, JavaScript, HTML and CSS but if you already know most of that stuff or if you feel like you don't need the beginner courses on that there's also deeper courses in completely different things. For example if you go to their electives path they have a regular expressions course they have a try R course the R programming language for statistics. They have a Google drive API course and they have a Chrome Dev tools course in fact all four of these courses that I mentioned are actually free. Just a ton of content on code school a lot of it is free go and check it out code school.com. Of course there's a link in the show notes and if you use that link code school will know that you came from Developer Tea. Thanks again to code school for sponsoring today's episode. So we've been talking about questioning our assumptions and specifically about questioning the idea that our code should always be dry. I mentioned that Sandy Mets has some interesting things to say about this. Specifically Sandy's position on writing your code before you refactor your code and that making code dry is a part of that refactoring process. But when you are writing your code you don't really understand it yet and it sometimes takes repetition. Sometimes it takes actually walking through each and every step of that process to know how you want that abstraction to look in the end and maybe you never will create that abstraction. Maybe that code will remain will remain repeated and when is that an okay thing when is it okay to have repeated code. What's the second exception? The second exception is when your code is likely to change in the future so that that abstraction makes it harder to change rather than easier to change. What is the easy way of saying that? Well basically if you think that this method isn't going to be able to cover all of the future flexibility that you need in that method. For example if you think that a particular query or if you think that a particular part of that method a few different steps are going to change in the future then it makes sense to repeat the code. This is how that actually plays out in a real life scenario. Let's say you create a basic function that takes a few arguments and returns something that uses those arguments and combines them together. Pretty common situation. Now let's imagine that you wanted to expand the functionality of that particular method to take a third argument and maybe do something slightly different given a different context. Now you have to make that method more flexible. If you do that enough times then that method becomes a overly complex, overly flexible and ultimately overly complicated method. This goes against so many other coding practices. What you're trying to do by making your code dry, by creating the single method that can take a bunch of configuration options and that can take a bunch of arguments to shift the way that that method is called, ultimately you're actually making it more difficult in the future because what you actually most likely need is either more methods, maybe two or three methods that are composed together or you need to just simply repeat yourself, especially if there is a high amount of variability in the different ways that you're calling that method. If that was a little bit too difficult to understand then to put it simply if your methods, if your abstractions become too flexible then they become overly complex and it's better for you to repeat code than to create complex code. Let me say that one more time because it really summarizes what I'm trying to say in this episode as a whole. It is much better for you to have repeated code than to have complex code. This may feel a little bit antithetical to what you've been taught about maintainability when it comes to code and that's because usually less code means less complex code. More code typically adds complexity but when more code, when verbosity of your code makes it easier to read and easier to understand and easier to change then it is better than less code. It is better than the dry version of that code. The main argument against this is that if you have to change something in more than one place then that makes it difficult and that's something that you have to weigh as the developer is it easier for me to change this thing in two places than to create an overly flexible, overly powerful method that I can't understand in the future. If that is easier, if it is easier for me to change it in two places then dry may not be the most helpful principle in that particular scenario. It's crazy to think that some of the things that we've been taught or perhaps some of the things that we read on a daily basis about programming, some of them may need more context to really make sense each and every day in what we do. But I would like to challenge you to question everything, question everything that you learn and try to investigate why and where those principles actually apply. Investigate things that you hear on this podcast and determine how they fit into the work that you are doing each and every day. I'd love to hear about the things that you are questioning about what you've learned, about programming practices or even completely unrelated stuff about life or about relationships. All of these things play into the work that we do as developers. You can reach out to me on Twitter at Developer Teaor you can email me at Developer Tea at gmail.com. I'd like to once again thank today's sponsor code school go to codeschool.com. If you are looking to learn how to code or if you're looking to expand your existing knowledge with new electives on things like regular expressions or the Google Drive API or if you want to learn R, go and check it out codeschool.com. Of course there is a link in the show notes for that as well. Thank you again for listening to today's episode. Of course Developer Tea is a part of the spec network that spec.fm go and check it out. There are other shows and interesting resources always being added to spec.fm. Thank you so much for listening to today's episode and until next time, enjoy your tea.