00:00:10.920
Thank you so much for having me. It's great to be back at Euruko! This is actually the second Euruko that I've spoken at. The first one I attended was in 2010, so 13 years ago. I would ask, was anybody else there in 2010? Was anyone here in middle school then? Probably just a handful of you.
00:00:30.519
Today, I want to talk about version control. I am somewhat obsessed with version control; it's what I've been doing since before 2010. As you may know, I was one of the co-founders of GitHub, which we started in 2008, so I've been involved in this for quite a long time. I wrote a book called 'Pro Git,' which some of you may have read. It’s also available online and acts as the official Git documentation—it's completely open-sourced and I authored all of it.
00:01:08.080
Recently, I have returned to working on version control tools, trying to create a new Git client. This endeavor has made me reflect on product design, as I believe it can be generally applicable to almost any product you're working on. I want to share a couple of insights I've learned about product design while working at GitHub, as they have been valuable for me in my subsequent endeavors at various startups.
00:01:49.600
The central concept I'd like to convey is the idea of first principles. This term was mentioned frequently at GitHub, and it held great importance for us. If you're unfamiliar with what first principles are, they stem from physics and refer to basic concepts or assumptions that are universally accepted and not derived from anything else. It represents the essence where there are no more assumptions to be made and you can distill what’s true. The primary tool for discovering these first principles is simple: asking why. This basic approach is something we all likely experienced as children, leading to the endless cycle of 'why' questions.
00:02:50.920
An interesting thought experiment is to consider questions you might ask about everyday scenarios. For instance, if someone said that Aunt Minnie is in the hospital and you ask why, the initial response could be that she fell and broke her hip. If you continue—because children incessantly ask why—you could then find out she slipped on ice. Ultimately, if you persist, you may arrive at fundamental truths, such as why ice is slippery. This line of questioning can lead to surprising insights.
00:03:49.680
For example, ice is slippery due to the unique properties of water when it freezes, which is a topic still shrouded in scientific debate, as noted in academic research. This pursuit of deeper answers often leads to more fascinating revelations. I challenge you to apply this approach to your work. Whether you’re developing software or managing complex projects, don’t hesitate to question the tools and processes you use. Ask why frequently until you discover something truly insightful, enhancing your understanding and outcomes.
00:05:04.560
Now, moving on to some specific principles regarding version control, I want to emphasize that I'm more invested in asking questions than providing concrete answers. I encourage you to feel a bit frustrated with your existing tools. I want to delve into the first principles of version control itself. To begin, let's consider one straightforward statement: we all use Git. I can confidently say that 13 years ago, when I last spoke at Euruko, not everyone was using Git. My prior talk focused on convincing people of its utility.
00:05:54.880
Now, it seems almost unthinkable that there is anyone in this room who does not utilize Git. But it's worth pondering why it has become the de facto standard. We need version control to facilitate collaboration and save our work; those are quintessential functionalities. However, have you considered how variant these tasks could be approached? Version control systems arose to address deficiencies in our file systems. Our computers don't inherently track the history of our files in a way that allows collaborative work.
00:07:16.120
This analysis leads to an important inquiry: why can't our existing systems inherently manage this? For example, why do we rely on a separate version control system like Git? Platforms like Google Docs have innovated collaborative editing by allowing real-time access without the need to formally commit your work. Such systems exemplify alternative methods that achieve similar goals to traditional version control, often more conveniently.
00:08:28.720
If Google Docs manages versioning seamlessly, why can't other systems? This is a compelling thought. When considering what version control systems like Git actually do for us—like committing changes, collaborating, and reviewing it becomes clear we could utilize various specialized tools for these tasks. Each aspect of version control could theoretically have its own solution, akin to the independence seen in various software tools today.
00:09:36.880
Thus, my question for you is: are the version control tools we've used for the last 15 years truly the best solutions, or are we simply accustomed to them? I urge you to consider this as we enter a more thoughtful phase in product design and development. As we now look closely at our historical context, it is bewildering how many of the same routines remain in place for decades without significant evolution.
00:10:55.640
I will examine areas like archaeology within software development. This involves digging through your codebase to understand its evolution over time. It's not merely answering queries like, 'What are the last few commits?' But rather focusing on more engaging questions like, 'What’s the underlying motivation for these changes?' The most relevant matters tend to emerge when we reframe how we think about the tools and concepts at hand.
00:12:21.480
To contrast, the typical question of who made the last changes or what were the last commits is always easy to answer. However, I argue these inquiries might not be profound—though they are convenient to address. Instead, we should seek answers to more challenging and pertinent questions. By becoming more aware of what we truly want to understand about our development process, we can enhance our workflows.
00:13:40.640
But further unaddressed questions surpass our conventional metrics. While we can discover basic information like who touched a line of code, it is pivotal to know why they did it. Inquiries about commits that introduced certain lines or understanding the context behind a function’s evolution are crucial for improving our development efficiency. This presents an opportunity for improvement as we should push for clearer methodologies and enhance our understanding of alterations in our work.
00:14:54.240
As we integrate more complex features within our coding practices, we might encounter questions about how a specific line shifted from one part of the codebase to another. Such investigations can become overly convoluted due to lack of clarity over file histories in existing systems. As an example, utilizing tools that help to track code history effectively can streamline this type of inquiry—eliminating guesswork when determining code origins.
00:16:15.360
I contend that it is possible, though rare, to analyze different files more closely. A practical method entails exploring relationships between files to identify commonalities in edits that can occur in tandem. This often goes unrecognized due to limitations in our version control systems but also illustrates the potential for deeper analysis.
00:17:30.440
Finally, I want to address unanswerable questions or those that are often overlooked in conversations around version control: 'What pull requests contributed to this file?' or 'What was the context behind the coding decisions made?' With more emphasis on conversational data—instead of only commit messages—there is the potential for greater understanding within our teams. This lack of visibility limits our ability to ask pivotal questions regarding the origins of lines of code, which can drastically affect the efficiency of our workflows.
00:18:56.120
So to end this on a thought-provoking note, I want you all to contemplate what you would want to ask your code. If you can identify the tools or contexts that prevent you from exploring such questions, I hope this inspires you to consider configurable solutions that could facilitate those inquiries moving forward.
00:20:46.360
Lastly, I appreciate your attention today and look forward to having some discussions with you. Let’s take a moment to dive into questions—please raise your hand if you'd like to ask anything. Your thoughts are valuable to this ongoing dialogue about the future of version control and our tools!
