Refactoring
Even Hemingway Wasn't Hemingway
Edit
#refactoring
#code-quality
#writing
#programming-techniques
#developer-experience-dx
#design-patterns
#software-architecture
Summarized using AI

Even Hemingway Wasn't Hemingway

Ian Whitney • October 02, 2015 • Earth

The video titled 'Even Hemingway Wasn't Hemingway' presented by Ian Whitney at the Rocky Mountain Ruby 2015 conference discusses the parallels between the creative processes of writing and programming, emphasizing the importance of rewriting and refactoring for both disciplines. Whitney draws a connection between the iterative writing processes of authors, such as Ernest Hemingway, and the coding practices of developers.

Key points covered in the talk include:
- The Writing Process: Writers often produce multiple drafts, editing their work to achieve clarity and conciseness. Hemingway, known for his powerful prose, accepted that his first drafts were often poor and required extensive rewriting.
- Coding as a Form of Writing: Whitney argues that coding should also be viewed as storytelling. The process of coding, like writing, involves crafting a narrative that may need multiple iterations to clear and refine.
- Refactoring vs. Rewriting: In programming, the act of rewriting is commonly referred to as refactoring. While some refactoring leads to stylistic improvements, Whitney emphasizes that true refactoring should improve the underlying design and functionality of the code.
- Feedback Loops in Development: Programmers should view code as perpetually in draft form, allowing for ongoing revisions based on user feedback and project requirements. This iterative approach mirrors the evolutionary process writers undergo in developing their stories.
- Practical Tips: Whitney outlines specific types of refactoring and their purposes, making an important distinction between simple aesthetic changes and fundamental redesigns of code. He encourages programmers to adopt a mindset that values the narrative their code creates, much like how authors value the story their words convey.

The talk concludes with the reminder that both writing and coding require patience and a willingness to review and improve draft versions until a polished final product emerges. In both fields, the key is ongoing learning through practice and revision, reinforcing that even great authors have faced challenges in their early drafts.

Even Hemingway Wasn't Hemingway
Ian Whitney • October 02, 2015 • Earth

“The first draft of anything is **.” - Ernest Hemingway

Ernest Hemingway didn't write first drafts of sparse, clear prose. He wrote terrible first drafts and then rewrote them, over and over, until the design of the prose was right.

For Hemingway, and every good writer, Writing is Rewriting.

As programmers our first drafts are terrible as well. Perhaps we clean up that first draft with some stylistic tweaks that make it look nicer but that don't affect the underlying design. But how often do we really dig in to that first draft and tear it apart, redesigning it until it is sparse and clear? Not often enough. And that's to our detriment.

For good developers, Design is Refactoring.

That sounds easy, but all too frequently refactoring doesn't lead to appreciable changes in the code's design. How do you use refactoring to improve code design? And how do you identify when you're just changing the surface style of your code? What's the difference between coding style and design, anyway? I'll answer all of these questions, hopefully, and show you how to take your code from a first draft to a clear, sparse design.

Help us caption & translate this video!

http://amara.org/v/HLzY/

Rocky Mountain Ruby 2015

00:00:24.849 My talk today is titled 'Even Hemingway Wasn't Hemingway.' It details the creative process and reflections on writing.
00:00:27.650 At a happy hour last night, many people asked me what I would be discussing, leading to some interesting conversations. I would say, 'Well, you know, it's a talk about refactoring,' but then I realized I never really explain how to refactor!
00:00:34.190 Instead, I tend to discuss the types of refactoring, what they can offer, when you might want to do them, and what they can and can’t do. However, my primary goal is to convey why you should be excited to refactor.
00:00:43.670 I want to frame this discussion by looking at what real writers do. Writers frequently change their words, and it's a part of the writing process. They produce multiple drafts to hone their work into something shorter and more concise.
00:01:01.100 Writers edit their work, but honestly, I’ve struggled to understand the concept of editing, despite having worked as an editor. Writers rewrite their pieces, which is a more descriptive approach. If you were to Google this concept, you might find the quote from E.B. White: 'The best writing is rewriting.'
00:01:10.580 Interestingly, when I search for Hemingway and drafts, I come across numerous results about how valuable rewriting is for writers. The act of rewriting sharpens their message and helps clarify the story they are trying to tell.
00:01:56.560 Ernest Hemingway was very blunt about first drafts. If you look at anything related to him, you often find a consensus that his drafts were not perfect. Hemingway is known for his precision, terseness, and clarity, qualities I also aspire to achieve in my own coding.
00:02:31.720 He was open about the effort it took to develop his style. He never claimed to be a magical unicorn who could produce perfect first drafts and be done with it. Some of you may ask why I keep drawing parallels between writing prose and coding.
00:03:06.889 It’s essential to recognize that coding is also a form of writing. While it may seem distinctly different, both involve storytelling. Your code tells a story, whether it is a simple one or a complex narrative with various branching paths.
00:03:25.310 At the time I captured this screenshot, the Rails master branch had around 53,000 commits, which might now be up to 54,000. That reflects a multitude of drafts, each one being a developer's attempt to correct or improve the underlying story they've created with their code.
00:03:51.139 Although we may call it 'refactoring' instead of 'rewriting,' the essence is still akin to rewriting. By embracing the concept of coding as writing, we can grapple with the idea that our initial drafts, just like those of writers, are often lacking.
00:04:13.159 This acknowledgment leads us to an important understanding: if coding is akin to writing and if even acclaimed authors like Hemingway have struggled with drafts, then we too should accept our early attempts at coding may not be flawless.
00:04:58.480 Like genuine writers, we will need to rewrite our code. And as we engage with our code, we’ll gradually learn the story it endeavors to convey. The process of refactoring and rewriting improves the clarity and intent of our code.
00:05:39.200 However, while real writers can sometimes publish their work, programmers' code is never really finished. It continually evolves as long as it is operational. That means your code will always be in draft form, constantly being refined and improved.
00:06:20.600 This ongoing process emphasizes the necessity of honing our skills in rewriting, even if we choose to label it as refactoring for the sake of comfort.
00:06:50.260 Simply telling someone to 'get better at refactoring' lacks actionable wisdom. It’s akin to advising someone to learn how to dance by dropping them off at a concert hall and saying 'good luck.'
00:07:40.790 The topic of refactoring is immense, with numerous approaches all having distinct goals. Each method is independent and should be selected based on what you are trying to achieve. Let's explore two general families of refactorings to see what they can and cannot do.
00:08:40.330 Take, for instance, a common approach for clarity. When we revise prose, we often cross out unnecessary words, replacing them with ones that convey messages more clearly. The same applies in programming, where we can improve variable names to reflect their functionality better.
00:09:56.970 While aesthetic changes enhance comprehension, they don’t alter the core narrative your code conveys. In this case, we might stylistically rework the variables to make them clearer without changing the broader functionality of the code.
00:10:12.400 The story remains unchanged, even if the code reads more smoothly. These stylistic refinements, often referred to as 'litter pickups' or 'comprehension refactorings'—terms coined by Martin Fowler—serve to clarify the code’s intent without altering its plot.
00:10:59.000 To that end, we should consider how much of our time gets allocated to improving code aesthetics versus actually changing the code's functionality. In my experience, a significant portion of my work revolves around modifying the story my code tells rather than merely refining its style.
00:11:43.680 To achieve that, we can return to Hemingway and investigate his revision process. His rewrites involved major structural changes; for example, he wrote multiple chapters before realizing he needed to change the main character, which required him to discard his earlier work completely.
00:12:17.560 This detail about Hemingway illustrates a crucial point: allowing flexibility in our narratives. Just like Hemingway discovered his story through several drafts, we, too, uncover what our code needs to express through cycles of development and revision.
00:13:11.050 The process serves as a feedback loop: by engaging with the code, we learn and adapt our understanding of the story that our implementation is attempting to convey. From there, we apply the insights we've gained and continue this iterative process indefinitely.
00:13:59.740 For coding, this drafting step is about creating multiple iterations of your code—initial drafts may be sloppy, yet they pave the way for refinement. The subsequent stage involves learning about your story, whether through encountering bugs, receiving feature requests, or noticing usability hurdles.
00:15:20.430 The critical step is applying what you've learned until you reach a point of improvement in your code. This process is transformative, and it's documented in numerous resources that may be gathering dust on your bookshelf.
00:15:54.060 Returning to the lemur renaming example, after understanding user requests, we might adjust our code to include a feature that allows users to rename their lemurs based on their preferred names while retaining defaults when needed.
00:16:54.000 Thus, even with seemingly minor adjustments, we can shape the narrative our code tells by modifying its underlying structure. While we may not realize it at first, these structural changes amplify the breadth of what the code can do.
00:17:32.300 In conclusion, crafting code is an iterative drafting process akin to writing literature. Like every renowned author, our path forward involves ongoing drafts, rewrites, and gradual improvements.
00:18:18.000 My contact information is available, and I want to extend gratitude to those who supported me in preparing this talk. Its format evolved far beyond my initial expectations.
00:18:39.170 I appreciate your time and attention. If you have questions, feel free to approach me later. Thank you!
Ian Whitney
@IanWhitney
Explore all talks recorded at Rocky Mountain Ruby 2015
+5