RailsConf 2014

Summarized using AI

Keynote: Writing Software

David Heinemeier Hansson • April 22, 2014 • Chicago, IL

In this keynote address at RailsConf 2014, David Heinemeier Hansson, the creator of Ruby on Rails, reflects on his decade-long journey with Ruby and Rails, sharing valuable insights about software development, programming culture, and the misconceptions surrounding computer science.

Key Points Discussed:
- Personal Journey: Hansson recounts his late start in programming, noting that he did not learn to code until he was closer to 20 years old. He emphasizes that one does not need to be a lifelong coder to contribute meaningfully to software development.
- Misconceptions about Programmers: He challenges the stereotype that serious programmers started coding at an early age and argues that many successful developers come from diverse backgrounds and experiences.
- Nature of Programming: Hansson differentiates between computer science and software development, advocating for the view that programming is more about writing information systems rather than rigorous scientific methods.
- Test-Driven Development (TDD): He critiques the obsession with TDD in software engineering, suggesting that it can lead to convoluted, less clear code. Hansson argues that focusing solely on tests detracts from the actual clarity and functionality of the system being developed.
- Programming as Writing: Hansson promotes the idea that software development should be approached as a writing endeavor, where clarity and readability are paramount. He believes that good software should prioritize clear communication over complex engineering metrics.
- Learning and Improvement: The importance of rewriting and refining code is highlighted, as Hansson encourages developers to aim for simpler, clearer systems—similar to the drafting process in writing.

Significant Examples:
- Hansson reflects on his own coding experiences and recognizes that many first attempts at coding are akin to first drafts—needing revision for clarity. He urges programmers to omit unnecessary complexity when writing software.
- He draws parallels between diets and software methodologies, noting that both often rely on pseudoscience rather than practical, evidence-based approaches.

Conclusions:
Hansson concludes by emphasizing that programmers should aspire to write clear and understandable software rather than get bogged down by strict adherences to methodical testing that may not result in better design. He invites developers to view software development as an act of writing—focusing on clarity and effective communication.

Overall, the keynote serves as a challenge to the traditional paradigms of programming and encourages a cultural shift towards better communication and understanding within the software industry.

Keynote: Writing Software
David Heinemeier Hansson • April 22, 2014 • Chicago, IL

Help us caption & translate this video!

http://amara.org/v/FG1c/

RailsConf 2014

00:00:17.849 Software is hard, as you can see with hardware issues.
00:00:24.310 Last year, I had the personal pleasure of celebrating ten years of working with Ruby and ten years of working with Rails. But this year, I have a much more interesting anniversary—ten years of sharing Ruby on Rails with all of you.
00:00:36.820 And everyone who has been using it over the past decade.
00:00:48.370 The picture in the background is actually from almost exactly this time, where I gave the very first presentation on Ruby on Rails at a Danish university ten years ago.
00:01:00.610 At that time, I had to talk a lot about what MVC is, for example. Today, not so much. A lot of the things we worried about in the beginning have become less relevant as we have leveled up as a community and as programmers.
00:01:13.479 We’re just taking all of that stuff for granted, which is awesome because we get to care about many other things.
00:01:20.920 As I look back over the past ten years, which constitutes the majority of my adult life, I realize it’s fun to look back even further. There’s a common misconception that anyone who ends up creating something like Rails or doing something significant in software development must have been programming since they were five years old.
00:01:37.119 The notion of a hacker is often someone who got their first computer 20 years ago and has been programming the whole time. But that wasn’t me. I didn’t learn to program when I was five; I came to it closer to 20.
00:01:52.930 I had been interested in computers for a long time, but it wasn’t until the late 90s and early 2000s that I really dove into computer programming.
00:02:05.110 I knew many programmers and had a lot of friends who were doing it, but somehow it never caught on for me until I started writing software that I needed for myself and found a place in the software world.
00:02:24.209 Some say that a true hacker is someone who should have been programming for ten years already; otherwise, you’re way behind. Well, I learned to program just about three years before I released Ruby on Rails, and it turned out just fine.
00:02:45.349 I didn’t come from a background where I didn’t know what a computer was; I had exposure to it from a young age.
00:03:03.300 I grew up in the 1980s and was introduced to computers through gaming. I found them fascinating right from the beginning, capturing my imagination. I vividly remember there were lots of parents at that time urging kids to get outside and play instead of wasting time in front of the computer.
00:03:29.690 But the truth was, I really wanted to spend my time in front of the computer. The computer to have back in 1985 was an expensive one, and none of us could afford it, except for one kid in the neighborhood where we all shared it, taking turns playing.
00:03:56.330 Eventually, my dad was able to trade his repair work for a different type of computer, an Amstrad 646. I was excited but a little disappointed since it didn’t play all the games I wanted.
00:04:14.569 At about six years old, I tried to learn programming by typing in codes from a magazine. I thought it was amazing that I could control a computer.
00:04:31.130 I set up a system to send messages to my mom through a tape which I thought was clever at the time, but in reality, it was not real programming.
00:04:43.480 Years later, in the late ‘80s, I encountered a game called Battle Squadron, and the graphics amazed me. It sparked my desire to create something similar, so I found a programming environment called Amos.
00:05:03.359 However, all those concepts of variables and others seemed to confuse me, and I didn’t get very far.
00:05:29.169 In 1993, I attended a demo party in Denmark. That experience immersed me in the world of programming, yet I still couldn’t grasp the concept behind it.
00:05:47.160 So I built another information system, a BBS where we traded software and games. I worked hard to afford modems and phone lines, but I still felt out of place in programming.
00:06:07.100 The truth is, I struggled to identify with programming in a computer science context because it just didn’t resonate with me.
00:06:24.820 In fact, this isn't surprising. My high school diploma shows that I got an F in math but an A in English. My strengths were never rooted in hard sciences, and I initially felt it was a hurdle.”
00:06:48.390 With that, I disabused myself of the notion that I would ever be a groundbreaking computer scientist. I wanted to build information systems rather than focus on algorithms.
00:07:06.200 It also appears that many people in the industry still aspire to fulfill that computer scientist role, but that’s not the only path. Most of our work deals with creating information systems, but the industry often glamorizes different technical pursuits.
00:07:29.250 It's more about interpreting and combining elements than it is trying to uncover the secrets of science or engineering.
00:07:39.080 Despite all this, we often end up discussing hard sciences and universal programming laws, which should be critically assessed, as much of what we do is quite subjective, resembling poetry interpretation rather than mathematical deduction.
00:08:04.189 Instead of striving for hard science validation, we should embrace the truth that programming is more subjective than universal. This lack of understanding can lead to misinterpretations about our roles as developers.
00:08:23.780 In practice, most of what we create has very little to do with deep scientific methods. Understanding that is essential for development.
00:08:35.959 I noticed a parallel between software methodology and dietary advice. Just as diet fads thrive on anecdotal claims, many software development practices evolve without adequate scientific grounding.
00:09:03.740 Both diets and software practices can ultimately lead to confusion rather than clarity. We should aim for sustainable practices that lead to genuine understanding, rather than being overridden by buzzwords or buzz diets like test-driven development.
00:09:35.330 Before we dig deeper into concepts like TDD, it’s important to note that following practices without question can hinder our progress in creating clear and effective software.
00:09:48.020 In that context, I realized we need to focus more on clarity in our coding practices, and perhaps less on the overhead of metrics that don't necessarily lead to a better product.
00:10:05.700 My perception of clarity and simplicity in code has evolved as I’ve interacted more with different types of coding practices throughout my career.
00:10:24.140 The more I read poor software, the more I learn what clarity truly means and how I desire to achieve that in my own practices.
00:10:38.220 Reflecting on this, I equate writing software to the process of crafting understandable writing. It's not just about frameworks and methodologies; it's about how effectively we communicate through code.
00:11:04.850 I’ve seen many examples where developers prioritize patterns over clarity. What many still fail to understand is that simplicity and clarity should guide our work as we develop software.
00:11:21.130 It’s about cleaning up our codebases, ensuring that each submission enhances clarity rather than complicating the message the code aims to convey.
00:11:34.970 Ultimately, clarity should be our primary objective, just as it is the objective in writing and creative processes. When we focus on that, we make better connections between our intentions and our outcomes.
00:11:44.740 Taking all this into consideration, I call on my fellow developers to reevaluate their critical eye toward the critical components of not just development and design, but software writing as a whole.
00:12:01.360 When we become more adept at assessing our work based on clarity and simplicity, we improve our understanding of programming as a language unto itself.
00:12:12.330 The way we communicate through coding should reflect the values and sentiments we hope to share rather than follow trends for the sake of appearing knowledgeable.
00:12:23.390 Coding becomes much more rewarding when we care about clarity above all else, ensuring that our work resonates similarly to enticing writing.
00:12:31.110 In closing, let’s embrace the identity of ‘software writers’ and focus on delivering clear, succinct messages through our code, appreciating the unique way in which we can create experiences for users and ultimately enrich our community.
Explore all talks recorded at RailsConf 2014
+129