Today's episode is about repeating yourself, and knowing when to repeat yourself and when not to. Thanks to today's sponsor: Code School. Visit codeschool.com/developertea to start learning web technologies from the comfort of your own browser for free.
Today's episode is about repeating yourself, and knowing when to repeat yourself and when not to.
This episode was inspired by Sandy Metz. One of Sandy's teachings is to repeat yourself until you understand your code. It is much better to have repeated code than to have complex code. As a developer, it is your responsibility to decide if your code is better suited to be duplicated or complex.
This episode goes against the grain of the DRY methodology, but I challenge you to question everything. Investigate everything you hear and challenge your learning.
Thanks to today's sponsor: Code School
If you're interested in learning anything development related from language basics to regular expressions, try R, Google Drive API and Chrome Dev Tools check out Code School. Start learning for free at codeschool.com/developertea
I would love to hear any questions you have about coding and life. If you have a question you'd like me to explore email me at developertea@gmail.com, or write to me on twitter @developertea. Developer Tea is a Spec Network production. Check out the Spec community and join the conversation.
I hope you enjoyed this episode and until next time,
Enjoy your tea
Hey, everyone, and welcome to Developer Tea. My name is Jonathan Cottrell, 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 CodeSchool. You can check out CodeSchool 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 codeschool.com. I'll be sharing a few more details about how to get 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 hear 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 developers. There's partials in 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 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 whys. 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 Metz. 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 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 the code. So if you're writing a code that you're writing, then you're going to have 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 learning, but also for 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, and 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 DevTools course. In fact, all four of these courses that I mentioned are actually free. So just a ton of content on Code School. A lot of it is free. Go and check it out, codeschool.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 T. 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 Metz 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. That when you are writing your code, you don't really understand it yet. And it sometimes takes repetition. And so I'm going to talk a little bit about that. So let's get started. Let's get started. Let's get started. So 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. Well, now you have to do something a little bit different. So you're going to make that method more flexible. Now, if you do that enough times, then that method becomes a overly complex, overly flexible, and ultimately overly complicated method. And this goes against so many other coding practices. So what you're trying to do by making your code dry, by creating this single method that can take a bunch of configuration options and that can take a bunch of arguments to shift the code, you're going to make that method more flexible. And so you're going to make that method more flexible. And so you're going to make that method more flexible. And so you're going to make that method more flexible. And so you're going to make that method more flexible. 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. So if that kind of 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. Well, 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. Now, 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. Now, 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 the things that you hear on this podcast and determine how they fit in to 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 T, or you can email me at developer T at gmail.com. I'd like to once again, thank today's sponsor, CodeSchool. 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 T is a part of the spec network. That's spec.fm. Go and check it out. There's other shows and interesting resources always being added. To spec.fm. Thank you so much for listening to today's episode. Until next time, enjoy your tea.