 I'm going to be talking about impactful refactors. I'm a software engineer, Echo Spot Check in Denver, Colorado. Today I'm going to go through a couple examples and get into the why. So before I jump in, I'm talking a lot about readability. I get that there are times when readability is going to get trumped by other things. So we're currently dealing with scaling and performance issues at my company now as we grow. Sometimes we need to do whatever it takes to keep our app up and running. And oftentimes, performance code is not very clear or readable. So save the unreadable performance code as the last resort or only when you absolutely need to be writing it. A lot of times I see people write very performance code that is unreadable when there aren't any performance issues occurring whatsoever or that will occur in the near future. So as a disclaimer, I'm coming at this from a non-technical background. I wrote my first line of code four years ago at a Rails Bridge workshop and didn't attend a coding school or get a CS degree, actually studied advertising in college. So making code readable makes me more productive as someone coming from a different background. It really gives me the confidence that I need to keep going because programming is hard enough. And when I can actually read the code and contribute, it really makes a huge difference and it helps me get over things like impasse or syndrome. But it also makes everyone else on my team more productive. And to quote Michael Feathers, he says that readability is the best default or the most important aspect for nearly all code. So a couple examples. Something that led me to have to debug when I could have completely avoided it was when the name was not as specific as it could have been. Leading me to have to use a debugger or to use a debugger in RubyMine, which for those of you who use RubyMine as their ID, know how painful of a process that can be. So for a similar example, I pulled this from a popular blog on presenters and Rails. And here it shows us that we're creating an instance of the post presenter. We're calling it post. But why not call the instance variable post presenter? Then I know that I can only call methods in that presenter class rather than from that post class. And I don't have to go back and find where this is instantiated and it's clear from the get go. I think that sometimes it's actually useful to put type and unit information in your names in Ruby. And I know this is a very controversial subject so I'm sure a lot of you disagree with me. But and I don't think you should do this everywhere but only where it's useful and to use them sparingly because like a comment they can be hard to maintain. So for this example, we have a method called birth date which takes a user and returns the user's date of birth. But what you can't see is that date of birth actually returns epoch time as an integer rather than an actual date. And I would not know that just from looking at this method. So why don't we call it something like birth date as integer? So actually putting the type in my name. Also be verbose, people want to reduce verbosus in their code. Cut down to tiny characters, but I disagree. I don't think we should be afraid of long names. A variable's name acts as a comment which can be very helpful in understanding code. So in this example, which Nadia is referring to in just a minute, was great, I have an instance very, you'll see too, gets better. You'll see I have a dog here, I'm newing it up, I'm setting some attributes on it and saving. And now I'm calling my variable name agility cattle dog with a wheat allergy. So this is ugly, but I think in a context it's an acceptable trade off because it's important for the person reading this to understand that the dog is a certain type of breed that has an allergy. So when you reference this instance variable elsewhere, once again, you don't have to go back and trace and see where it was first initiated. So put all this information in your variable name. And I know this is a little far fetched contrived example, but you get the idea. Also abbreviating, abbreviating is an example of a difference in readability, I think, between a junior and senior developer. So let's say we have this example of using the reject method. You can see how we abbreviate our block argument here, the D representing dog. So to me, abbreviating is not as readable as actually spelling out the whole word competing dog. But objections I've heard to this is that this is a junior-senior thing. So seniors are thinking in more abstractions and using methods like map and inject select methods like that for me are hard to understand, but can be sacrificing maintainability to not use those methods. Because it adds cognitive overload in thinking about the loop. So for me, this is an example where it's not so straightforward. Do you sacrifice things like maintainability so the juniors on your team can read the code better? And these are things that I don't have the answer for, but just important things to think about and talk about on your team. But the most important piece of advice that I have for writing readable code is to stop writing clever code. I know it's really fun to experiment, fun to show off something new. You learned in a blog post, but I think you should save that for the side projects. Don't sacrifice the readability of your code for everyone else on your team because you want to show off. And I think the goal should not be to minimize lines of code. The goal should actually be to minimize the time needed to understand it. So there are a lot of other awesome, bigger refactors that you can do to make your code more readable. You can make sure that you have explicit interfaces with small helper methods that are named wonderfully. But you can read about all of that in books like Pooter by Sandy Metz. Or you can pick up a copy of this book called The Art of Readable Code. And it has some great examples of readability refactors that you can do day to day. But now I really want to get into the why. So why is writing readable code so important? Code is easier to change and maintain because I don't have to spend time figuring out what the code's doing. I don't have to debug constantly in my slow RubyMind debugger and put and put statements everywhere. Also, that means that bug fixing is a lot quicker and easier. I can quickly find and diagnose a problem and understand what the code is doing. Also, a lot of readable code is tied to best practices. For example, a lot of the code that's in Sandy Metz's Pooter book is not only good OO design, it's readable. Also, engineering teams can work remote if code is readable. Instead of constantly having to get up, go ask my co-worker about the code they wrote and how it works, I can understand what's going on from the get go. And remote engineering cultures are becoming a very popular and prominent thing in our industry. Onboarding is also really important, and not only for juniors, but for everyone. And onboarding is a really hard thing to do. But the more readable your code is, the easier it is to onboard new developers onto your team. And think about what Nadia was saying earlier about making someone feel comfortable and at home in your code base when they first come to visit. Also, humane driven development, which is a term coined by Ernie Miller, I don't know if some of you know him, he speaks a lot. But he has the belief that we are humans developing software with humans to benefit humans. So we are doing so much more than just writing code for the machine to understand. We should be focusing on writing code that our fellow teammates can understand. And it's also really amazing that the Ruby community continues to become more and more diverse. More people from different backgrounds are learning to write code, and it's awesome. And diverse people with different backgrounds, more often than not, haven't been coding as long or building computers their whole lives. So let's write code that advocates and supports this diversity by making it as readable as we possibly can. Also, a lot of people with diverse backgrounds are juniors in the industry. And sometimes companies hire junior developers without any mentorship capacity and it's not really fair to them. Another reason is that they cannot come up to speed is because companies have code bases that are really unreadable, full of clever code, and it's really hard to get going. So if you plan on hiring a junior developer or currently have juniors on your team, take the time to refactor for readability, give them the best possible chance at succeeding. It's the right thing to do. And it's not something that we often think about. I always hear, oh, we don't have enough seniors to be able to mentor. But never do I hear, our code base kind of sucks, it's really unreadable. Maybe we should look at that before hiring some juniors. And know your audience, and like I was saying, if you want to have juniors, think of reading the code as a junior developer. Would this make sense to them? And put yourself in their shoes and try to remember what it was like when you were first learning to write code. Whether it was Ruby or Fortran or Cobalt, write to your audience. But if you know you're never gonna hire juniors or you're gonna be the only person that ever sees this code, I think it's totally cool to write clever code, like in side projects. But it's even bigger than junior developers. Maths created Ruby because shell programming sucked. It wasn't readable, it wasn't fun. And readability is the principle of why Ruby was founded. So let's not forget this or lose sight of it. And Miniswan, as we have all known from the game show, stands for Maths Is Nice So We Are Nice. And I used to interpret this as, be nice to others in the community and social interactions. But now I realize that it means so much more, write nice code. And that's the driving force of the Ruby language, and it's really awesome. So if you're in the Ruby community, which all of you in this room are, you should be holding up these values. And the beauty of Ruby is the sharing economy. Look at all the gems that we have available for free, for example. And let's remind ourselves of this every day and make sure that everyone learning the language knows how important readability, sharing, and diversity is to the community. We must continue to embody empathy when we're programming. We must embody empathy in our code. And we talk a lot about empathy outside of writing code, but you can write empathetic code by making it readable. So have empathy for your coworkers and yourself. So always be questioning your code. Always be pushing yourself to be better. Always be striving for empathy and diversity. And do your part as a member of the Ruby community and keep your code readable. Thank you.