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.
