 my talk today is even Hemmy wasn't Hemmy way details reaching me etc we're at a happy hour last night a lot of people asked me well what is your talk about which led to some odd conversations I would say well you know it's a talk about refactoring except I never really tell you how to refactor I do I kind of talk about types of refactoring and what they can offer you when you might want to do them what they can and can't do but mostly what I want to do is talk about why you might want to be happy to refactor and I want to do that in the context of looking at what real writers do something that writers do well they keep changing their words kind of an awkward sentence writers write several drafts if I make that shorter writers edit it's a synced but I honestly never even understood what editing is and I wasn't editor for a while so you think I know writers rewrite I like that it's descriptive and if you were to google that you might find this a quote from E.B. White which is called the best writing is rewriting but honestly what happens when I google that is that I get this and that tells me that rewriting is so valuable to writers that they've even rewritten their own maxim about rewriting so it's obviously got to have some value there and if you look into it what you'll find is that writers like rewriting because it sharpens their message and it clarifies and teaches them about the story it is they're trying to tell Ernest Hemingway was real blunt about first drafts if you google anything about Ernest Hemingway in draft this is what you find about a million results with this and here he is doing some of that rewriting he's taking a draft here of I don't know what and revising it something like this now I'm focusing on Hemingway here not so much because I like him personally I never really cared for the guy but his style is known for its precision and its terceness and its clarity and these are all things that I strive for in my own code and I also really like that Hemingway was upfront and honest about how much work his style took he never claimed to be a magical unicorn that could write perfect first drafts and then just be done and now some of you might be wondering why I keep comparing what I want to do with a prose writer I think there's an obvious question here or a statement big coding is not writing what Hemingway does is somehow distinctly different from what we do to which I would say that's wrong sure it's writing it tells stories really small stories in this case it's also a really dumb story but it does tell a story your story might be terse and small and simple your story could be large and complex with lots of branching statements but it is going to be a story just like real writers your code is going to have drafts at the time I took the screenshot of the rails master branch it had 53,000 commits that was yesterday it's probably up to 54,000 by now so that's a lot of drafts every single one of those is someone coming in saying this story is not right I need to change it code has rewrites we just don't use that word we call it refactoring we don't really like that rewrite word because I think we've all been on projects that we're doing from the first minute someone said well we're just going to totally rewrite this and then you kind of cower in fear you can also prove that coding is writing just by using simple logic if you start off with the promise that if writing is rewriting and we rewrite code then hey coding must be writing I will warn you but I never did take a logic class I was a drama major so you know what do I know this leads us to a quandary if coding is writing and professional famous writers like Hemingway can't write good first drafts or second drafts or third drafts the one hope do we have about writing good code early on you're doomed you're not going to do it just like a real writer you're going to have to rewrite your code and as you work with your code you are going to learn the story that your code is trying to tell and as you learn that story you can refactor or rewrite your code to make it tell that story honestly in many ways real writers have it better they get to publish their work sometimes right uh books and articles and things that are published don't tend to change a lot after they've shipped us poor programmers we're not at all that lucky our code is never finished as long as it's running somewhere we probably need to make changes to it and unless you're working on an embedded code that is impossible to change your code is never going to be done which tells me that your code is always going to be a draft you're always going to be learning about it you're always going to be improving it you're always going to be rewriting it so you better get really good at rewriting but just don't call it that because people will get nervous call it refactoring and just telling you to get good at refactoring is not helpful advice there's nothing actionable you can really do with that saying we'll just get good at refactoring this kind of like teaching someone to dance by dropping them off at Radio City Music Hall and just yelling good luck hope you enjoyed the rockets refactoring is a big topic there are a lot of different ways to refactor they all have different goals and whatever you're trying to approach you pick is this is going to depend on what you're trying to achieve so i'm going to quickly kind of go through two general families of refactoring and show you what they can do and what they can't and since we have these real writers and since our coding is writing it turns out we can use the same techniques so let's look at having a way again so what is he doing here it's a little hard to see the picture is grainy but i see a lot of crossed out words replaced with other words maybe sometimes a whole sentence is gone and we can follow an example like this in code the hot new lemur.io site lets people manage their lemur collections and for whatever reason lemurs like to change their names a lot so the owners want to be able to rename all of their lemurs at once using randomly picked names this code works but we can do some rewriting on this kind of like what we saw himilado right so what have we done here not very much but we've changed some of our pick variable names like x to something useful like lemur we've replaced that loop with a more idiomatic block since it's just one line and we changed how we get a random lemur name so it's a little bit clearer that that name is random this is all to the good right style changes like this are massive boons to everyone who has to look at this code including you next week or that new developer or whoever style like this clearly matters how many we didn't write sentences like this but we also have to ask ourselves what do we end up changing because the story that code tells is exactly the same we still loop through a collection of lemurs and we give each one a new randomly selected name from lemur names this code is much cleaner it's much easier to understand but that story that it tells hasn't changed so what have we changed we've changed style but we didn't change the code structure so I would call this stylistic refactoring martin fowler calls these kinds of refactorings litter pickup sometimes he calls them comprehension refactorings I think stylistic refactoring as an umbrella term kind of encompasses both of those things so what can it do it's going to clarify your story it's going to ease comprehension it's great to use this at that point where you finished a method and it works and you just need to clean it up you don't really need to change the story because what it can't do is change that story that your code is telling you can make your story easier to understand but you're not going to change its plot so I'll take a little quick poll here if you think of your day how much of it is spent improving your coding style versus changing the code to do something new or better and I think you know most of my job and I suspect most of yours is changing the story that my code tells so what this tells me is that it's important as comprehensible code is I probably can't spend my entire day just tweaking variable names so how do we change our stories we can go back to Hemingway again how do they how did he do it there's only one picture by the way of Hemingway editing his own work this is it so here he is his rewrites also involve involves really large structural changes he'd written several chapters of that novel the sun also rises before he decided to just change the main character this wasn't a simple matter of renaming that character he actually had to throw out everything he'd written and write the book again about a whole new main character and this led to my reaction you know wait what do you mean that Hemingway didn't even know the main character of his own novel that seems ridiculous to me you're a writer you're writing a novel of course you know who it's about but what this tells us is something important about story which is that we can't know it in advance you can have a rough idea of what that story is going to be you know if the sun also rises didn't become a book about limp pilots in new jersey it stayed more or less the same it just changed characters so we have to discover our story and we do this through many many drafts um brad's talk earlier had that controller feedback loop that controller feedback loop is essentially this exact same process just at a human scale instead of using you know math um you write a draft through that draft or through other means you're going to learn about what that story is that your code wants to tell you can then rewrite your draft applying the knowledge that you learned and then you repeat this and because code is always a draft you repeat this forever until you are dead enjoy so we can get into these steps a little bit more um write a draft like i've said code is always a draft this step is the easiest just write some code it'd be great if it worked i don't think it has to you're going to then learn about your story and this can come in through different methods maybe it's bugs maybe you're going to get feature requests maybe you are going to find your code hard to use or test or maybe someone else on your team is there's other ways but i think these are probably the main ways that we learned about the story that our code is trying to tell and now the big magic step apply that new knowledge and i'm going to have to punt on this this is that whole book is how to apply your new knowledge to code it is full of patterns on how to take your code and change the story that it tells and i think it's a book this was true for me that a lot of us had on our shelves but haven't actually ever really read and i spent a lot of the last year trying to actually really read this book and it's probably a very different book than you expect but it takes some time a lot more time than i can get into in a 20 minute talk but i can show you a quick example so if i go back to that lemur io code we have our current knowledge people want to rename lemurs with one of our randomly selected lemur names and then our knowledge changes we get a feature request usually want to maintain their own set of names and use those for renaming their fingers so now we have a new story we want to update each lemur with the random name from the user if they have that or from our default lemur names then we want to just change our story we have not made a big change here all we've done here is follow the ad parameter refactoring pattern from that martin crawler book and it doesn't look like we've done very much but this one structural change has changed the story that our code tells we're now saying update each lemur with a random name from the provided names if there is no provided names you know use the default so what have we done here we change we change the structure we didn't change the style stylistically this code is the same but the structure has changed so probably not surprised you that i would call this structural refactoring uh fowler has a presentation where he talks about different types of refactoring preparatory is the term he uses for this planned long term but those are all really terms about when you're going to do it and not so much about what you are changing so i use the word structural because that's what you're changing so what can structural refactoring do for you what is it you're going to get out of it you're going to be able to change your story you'll be able to take that knowledge that you learned about your code or what it needs to do and you're going to encode it into something that you can check into source control but what it doesn't do and this is the really crappy part it doesn't make it easier to write perfect code the next time because perfect drafts don't exist that in itself is an oxymoron if they were perfect then they're not drafts if they're drafts then they're not perfect but yet i think this is the mental block that a lot of us have when it comes to refactoring as we look at code that we wrote and it makes us sad or it makes us angry we want to write great code right away you know the shorthand for this is we all want to be rock stars and i hope somewhere in all of our brains we know that rock stars don't exist and that whole idea is a piece of crap but it's still there right but we can take away from this is that every writer every professional famous writer that you've ever heard of or read has the same secret they write and then they rewrite and they rewrite and they rewrite until they get to publish lucky people and we can take this lesson and we can apply it to ourselves and use it to make our own refactoring a lot easier and the first step there is to admit that our own code is a draft right if you realize that that code is not set in stone then it's going to be easier to accept and focus on the improvement that new knowledge that you need to encode into it the alternative is to be upset that you wrote bad code in the first place or to curse the programmer who wrote that code in the first place which honestly i do a lot uh and it's a bad practice and i try to stop myself if you do admit that your code is a draft then you can kind of move on to the next step which is that you can start to revel in your increasing smartness i have a project that i'm working on right now that has a bunch of really gross meta programming and i tried to fix it and i got like 75 percent of the way there and i hit a wall where i just don't know how to fix the problem that i see like i'm just i'm not smart enough i don't have this knowledge yet at some point i will write and then i could make that change and then when i do i get to be really proud but i've actually taken this code to a new place i will have gone from a place of less knowledge to a place of more knowledge which i think sounds great but i need to stop there and say well this is still draft code right yes i fixed this meta programming grossness but this code is going to change again soon a lot and this is the point of that kind of bizarre talk title Hemingway didn't start off just writing Hemingway like prose right he improved through mistakes and rewrites and that is true of every real writer and it's proven logically now that includes you so that's me um contact information is there i want to thank those folks for helping me get this talk together uh it ended up being a lot different than i expected i really want like i was trying to find a way to show get commits as a gif because what you would see is here's a bunch of green and then it just got deleted and then a whole bunch more green and then a bunch of red and a bunch more green about six times so i was following my own advice here and doing a lot of rewriting and they really helped me out i don't want to keep you from lunch and it is noon so if you have any questions just go up and get me later thanks