Lessons from the Masters

Geoffrey Grosenbach

Geoffrey Grosenbach

1 talk

#developer-workflows

#refactoring

#test-driven-development-tdd

#user-interface-ui

#ruby-programming

#programming-best-practices

#developer-tools

Lessons from the Masters

by Geoffrey Grosenbach

In the video titled "Lessons from the Masters," presented by Geoffrey Grosenbach during RubyConf AU 2013, the speaker shares insights gained from interviewing various expert designers and developers over two years. The primary aim is to extract valuable programming philosophies and tips from seasoned professionals. Grosenbach uses the example of Rodney Mullen, a skateboarder known for inventing new tricks, to illustrate that there are foundational techniques in programming that can be learned from observing others.

Key points discussed in the video include:

- Importance of Observation: Observing the programming process is crucial; it's more informative than simply reading source code.
- Diverse Tool Usage: The majority of developers, including those from prominent companies, often use Vim, highlighting a trend in programmer preferences, while others like Grosenbach himself use Emacs.
- Problem-Solving Techniques: Different developers have unique approaches to tackling problems. Ryan Singer emphasizes using sketching as a tool for thinking through UI design, while Neven Mrgan relies on established concepts for communication.
- Workflow Variability: Each developer's workflow can be distinct. For instance, Zed Shaw prefers to delete and restart projects to maintain clarity and focus, contrasting with the more iterative approaches of others.
- Managing Distractions: Kyle Neath discusses how to balance experimentation and focus on core objectives within projects, ensuring simplicity and avoiding over-complication.
- Flexibility and Adaptability: The ability to pivot in response to challenges is crucial for developers. This is illustrated by Tim Caswell, who demonstrates adaptability during difficult phases of projects.
- Sunk Cost Fallacy: Developers should recognize when to shift directions rather than waste resources on unproductive pathways.

Concluding thoughts emphasize that learning from expert developers and sharing knowledge within the community can foster improvement and adaptability in programming practices. Grosenbach plans to publish a blog post with projects discussed, encouraging peer review to enhance community learning.

00:00:04.020 Thank you. In the summer of 1982, a 16-year-old boy spent the summer in his driveway, figuring out how to jump into the air on a skateboard. Now, this is pretty much the most basic trick in skateboarding. If you've ever watched people riding a skateboard, you've probably seen this happen. If any of you want to leave right now to buy a skateboard and learn how to do this, you could probably learn it within a week or two. It's a little complicated, but not too bad.

00:00:14.410 The thing was, it took one person to figure out that this was even possible and how to do it. That person's name was Rodney Mullen, probably my favorite skateboarder. He invented dozens of other tricks, from very simple to advanced. For example, one of his tricks is called 'the impossible'. So I wondered, are there similar things we could learn in programming just by watching other people who have spent a lot of time really intent on improving their workflow, the tools they use, or anything they've learned about actually doing programming? I went various places around the world and talked to not only developers but also sat down with them, giving them tasks that they could complete in about 90 minutes.

00:00:44.800 I filmed it, and at Peak Code, we call this the 'play-by-play series.' It's been very popular, and I want to share with you some of the best things we've learned from watching other developers. Most of this talk will not be me talking but rather you hearing the voices of other developers discussing their own processes. To me, this has been very important because just reading the final source code of an open-source application is not the same as watching it being written, and many things can be learned by actually observing the process.

00:01:39.549 All the different people we've talked to have had many valuable insights to share, and they keep adding more every month. Let's start with tools. The most shocking thing I found about the tools that different programmers use is that the majority of them use Vim. Gary Bernhardt, the first person we worked with before he became famous, uses Vim. Two days ago, I filmed the keynotes of today, and both of the speakers also use Vim. Haines and Patterson, did I miss something? Is everyone supposed to be using Vim? I actually use Emacs, so I don't care what editor you use, but it was still interesting.

00:02:20.110 However, maybe it isn't all that important, because your text editor isn't the only tool you should use while programming. Here’s Ryan Singer, an amazing UX designer at 37signals, who is also a decent coder in his own right. He talks about how to get an email address in a streamlined way. Do we want to scroll through 295 that we didn't pick? I think we could probably figure it out. So I'm not going to spend a lot of time sketching it right now, like I won’t delve into a discussion about something I'm worried about. It's not a straightforward process; it’s not like you sketch everything first and then do it.

00:02:58.769 It's more like when you're concerned about something, sketching can help you. It's another tool for solving problems. For him, sketching is not about making the full app outline; it's about sketching enough that he knows what he's doing. He spent about an hour sketching through ideas on paper and then an hour coding. However, not everyone likes to sketch, and there are other ways to think through a problem.

00:03:48.200 Here’s Neven Mrgan, a UI designer at Panic Software. One reason I don't do much sketching is that my equivalent discussion on paper is making references to other things. Essentially, if I say 'highway signage' in those two words, I've described a concept that likely evokes a common image for all of us. For instance, we may picture green signs, round, with a white border, legible on an interstate. This shared understanding allows me to communicate complex ideas without sketching them out. I find it impressive how Neven's ability to communicate and think through a problem reflects his proficiency in his craft.

00:05:13.890 For example, I gave Neven a task which was to design a UI for a trail hiking directions application. Within two minutes, he had thought through the various elements involved and expressed them as highway signage because these were directions, and also as a recipe because there were multiple ways to navigate through trails in a forest. This way of thinking showed his skill in communicating about the core aspects of the problem, which is crucial for both problem-solving and effective communication.

00:06:02.840 Yet understanding the weaknesses of each tool used in programming is essential. Problems have multiple stages of thought, and as developers, we often want to dive straight into a text editor. Text editors are excellent for sequential ideas and very specific implementations, but they may not be as effective for undirected brainstorming. Refactoring highlights this distinction: satisfying the requirements for a feature is different from organizing your code. These are two separate stages: getting the code down and ensuring the tests pass, followed by refactoring. Using different tools for each stage can greatly enhance the process.

00:07:06.870 Gary Bernhardt is incredibly knowledgeable about Vim. I once sat with him while we worked in a coffee shop, and someone across the room asked him how he performed such an impressive maneuver in Vim so effortlessly. His skills amazed even other patrons. Gary explains that he uses a particular key binding to save and run tests with precision, customizing his editor to fit his workflow. While I sometimes wonder if Gary overthinks things, his level of comfort and control in using Vim can be a valuable lesson for others.

00:08:16.960 I asked him why he didn't just write a script to automate running tests, as there’s code available for that too. However, he prefers customizing Vim as it gives him the fine-grained control he desires. Yet, it prompts me to think about the approaches developers take to tools with sources. Zed Shaw, another controversial figure for some but whose insights I appreciate, believes in handling source code control not merely as code backup, but as communication. He likens writing a good commit message to writing an effective email that includes a clear subject. It’s crucial for ensuring messages are conveyed correctly within teams.

00:09:58.320 Now, we’ve talked about tools; let’s shift to workflow. How do people navigate through programming challenges? Since this is a Ruby conference focused on writing Ruby code, there’s no better example than a Ruby committer. Here's Aaron Patterson, another speaker today, demonstrating how a professional approaches writing Ruby code. Often, the first major challenge is defining the problem clearly. It's easy to assume it’s obvious, but failing to ask, 'What is the actual problem?' can lead to complications down the line. Gary emphasizes that programmers need to suppress their natural tendency towards hubris to avoid pitfalls.

00:12:20.739 Approaching software this way means being careful, especially regarding data structures and testing them. This framework showcases the importance of understanding the context around our problems. Ryan Singer, who often considers user interface issues, provides insights valuable for developers of all roles. He articulates the necessity of considering each state in the process of navigating through UI design, emphasizing not just the surface of the screen but also the background requirements.

00:13:03.180 Understanding what information is necessary, where it is coming from, and the potential issues arising as data evolves is crucial. This notion of context can fundamentally shift the way we approach problem-solving and coding. However, it is important to recognize that workflow styles can vary. Zed Shaw has a tendency to delete his entire project and restart when interrupted because it allows for a fresh perspective. His philosophy encourages focusing on one task at a time, identifying early on if it’s misguided. It’s about ensuring a project isn’t overly complicated and maintaining clarity in process.

00:14:58.962 Our capabilities to pivot and improve are part of refining the work we do, as we strive to build new iterations that surpass previous versions. Distractions can greatly harm our workflow, and even after silencing notifications, distractions from the project itself can take a toll. Kyle Neath, another designer at GitHub, discusses how experimentation can initially pull a project in various directions, potentially leading to oversights and errors. Designing quickly while remaining attentive to the core objectives of a project is critical.

00:15:58.369 In web apps, while focusing on functionality, the last thing we often want is to fix data persistence immediately. This helps curb distractions and allows for an effective way to clarify project elements without over-complicating the process. Just like in the world of unicycling, focusing on pivotal concerns can mean better progress. However, efficient developers know that the realization of what needs immediate focus is key. The order of project implementation can adapt fluidly with test-driven development, allowing flexibility.

00:17:25.450 As we wrap up this discussion, I want to draw another analogy to skateboarding. Great skateboarders exhibit an understanding of flow; they navigate 3D space and maintain momentum while adjusting their path as needed. This intuitive grasp of physics translates to programming as well. Experienced programmers often juggle multiple concepts simultaneously, recognizing that our first ideas may not always be our best strategies. This is echoed by Ruby veteran Jim Wyrick, who illustrates navigating a project as balancing expectations.

00:19:20.130 As he reflects on his journey with Rails, Jim learned the importance of simplifying complex ideas to stay focused and allow for clearer communication. My insights from Frederick Brooks’ 'The Mythical Man-Month' emphasize the optimistic nature inherent to programming. However, it's vital to acknowledge that not all initial ideas will navigate us successfully toward a solution. The practice of refinement and iteration is not just about coding but embraces the broader growth process that leads to improved systems.

00:21:15.000 Great developers possess an acute awareness of time management throughout their tasks. Kyle Neath demonstrates this via his leisure strategies, which reflect a balance between ongoing tasks and re-evaluating interests. There exists great merit in understanding the parameters of productivity; one must always consider if pursuing a particular solution is viable within the given resources. This growth in maturity as a developer is incredibly valuable.

00:22:29.840 To conclude, the most unexpected lesson I encountered was the ability to shift direction midway through a project, abandoning prior work to explore new pathways. Tim Caswell exemplifies this concept, readily pivoting when facing challenges, which reflects the essence of being adaptable in our approach to a problem. Developers must cultivate a balance between flow and mindfulness to avoid heading toward a dead end, and to consciously consider alternative tools and pathways.

00:23:51.060 The sunk cost fallacy, which often feeds into our reluctance to abandon unhelpful projects, is something to guard against in the world of software development. If investing more time and resources continues to generate minimal results, clearly it's time to reassess our direction. This approach can be beneficial not only in programming but extends to numerous aspects of life. These insights drawn from working with various developers will continue to shape our understanding of best practices moving forward.

00:25:41.640 Finally, we will publish a blog post detailing all projects we've shared with developers. I encourage you to try these projects, whether on your own or in groups, and observe how others work. Watch fellow developers code; learn from their processes and offer your insights. This exchange of knowledge can bolster our growth in the community.

RubyConf AU 2013