RailsConf 2014 - Keynote Writing Software by David Heinemeier Hansson

My notes

在编程中有两种方向，一种是解决复杂的计算问题，一种是写散文。就像在交易中有价值投资和技术分析投资一样，正确的方式是二者的结合而不是某一种

There are two directions in programming, one for solving complex computational problems and one for writing prose. Just as in trading there is value investing and technical analysis investing, the right way is a combination of both rather than one or the other

DHH在编程经验只有三年的时候就完成了Rails框架，我认为他在写作中的清晰组织观点和表达的能力迁移到了Rails中

DHH completed the Rails framework when he had only three years of programming experience, and I think his ability to clearly organize ideas and express them in writing migrated to Rails

Introduction

Software development is challenging, and over the years, my experiences with both hardware and software have shaped my understanding of this ever-evolving field. Last year marked a decade of working with Ruby and Rails. However, this year is even more significant, as it commemorates ten years of sharing Ruby on Rails with the community. This journey began with my first presentation on Ruby on Rails at a Danish university ten years ago, where I had to explain concepts like MVC (Model-View-Controller). Today, much of what we worried about back then has become second nature, allowing us to focus on more complex issues.

Early Misconceptions and My Path to Programming

Looking back over the past decade, I realize there’s a common misconception that anyone who creates something like Rails must have been programming since childhood. The stereotype of a hacker, who started coding at five years old, is pervasive. However, that wasn’t me. I didn’t start programming until I was almost 20, despite being interested in computers from a young age. It wasn’t until the late 90s and early 2000s that I dived into computer programming, mainly because I needed software for myself.

There are numerous essays about what makes a “true hacker,” and often, the notion of having ten years of experience is emphasized. However, I only had about three years of programming experience before I released Ruby on Rails, and things turned out just fine. I wasn’t programming from a young age because I grew up on a farm without access to computers. But by the time I was introduced to computers around age five, they quickly fascinated me, especially through gaming.

Early Failures and Struggles with Programming

My first exposure to computers was through gaming. In 1985, I was introduced to my first computer and was instantly captivated. However, we couldn’t afford our own, so we shared one with a neighbor. This experience sparked my curiosity, leading me to my first programming attempts. Around six years old, I tried to learn programming from a magazine, but I failed miserably. My first “program” was a simple message system for my mom, which, in hindsight, wasn’t really programming at all—it was just basic print statements.

As I grew older, I continued to struggle with programming. I attempted to learn through various means, such as Amos, a European programming environment, but the concepts like variables and conditionals baffled me. I simply didn’t get it. Despite my interest, programming remained elusive.

The Turning Point

In 1993, I attended a demo party in Denmark called “The Gathering 3,” where I was inspired by the impressive demos created by others. However, the programming involved, especially in assembler, was still beyond my grasp. Despite these repeated failures, I didn’t give up on my desire to create things with computers.

My struggles with programming were compounded by my poor performance in traditional computer science subjects. I failed my math final exam in high school and struggled with physics—subjects that are often seen as foundational for programming. This disabused me of the notion that I was a computer scientist destined for groundbreaking algorithms. Instead, it was a relief to realize that I could focus on building information systems without needing to delve into the complexities of computer science.

Embracing My Identity as a Software Writer

Over time, I came to see myself not as a computer scientist but as a software writer. The industry often pressures developers to conform to the ideals of computer science, emphasizing hard sciences and complex algorithms. However, I realized that my passion lay in building information systems, not in the low-level details of computer science.

The misconception that most programmers share is that they are all somehow equivalent to legendary computer scientists like Linus Torvalds, who improved the Linux kernel’s scheduler. But the reality is that most of us work on far less complex problems, such as building yet another social network or to-do list. It’s important to recognize the difference and embrace our roles as builders of information systems rather than aspiring to be something we’re not.

The Myth of Universal Programming Truths

The idea that there are universal truths in programming, akin to the laws of physics, is misleading. Many practices and principles in software development are treated as if they are immutable laws, but in reality, programming is much more subjective, similar to interpreting 17th-century French poetry. The notion that certain practices, like the Law of Demeter, are universally true is more pseudoscience than science.

A perfect example of this is Test-Driven Development (TDD), which has become one of the most popular software methodologies. TDD is often presented as the only path to professional software development, and many developers, including myself, have struggled with it. While TDD has its merits, it can also lead to code that is more convoluted and harder to understand, all in the name of making it easier to test.

The Problem with Overemphasizing Testing

Over time, I realized that the focus on TDD and unit testing often leads to architectures that are harder to reason about and less clear. Testing is supposed to support development, not drive it. However, the obsession with metrics like test coverage and speed has led many to prioritize these over the actual clarity and simplicity of the code.

In reality, testing at a higher level of granularity, focusing on systems rather than individual units, is often more valuable. A recent bug in Basecamp, where we lost customer data despite having extensive unit tests, drove home the point that unit tests alone are not enough to ensure a system works as intended.

The Importance of Clarity in Software Writing

The most important lesson I’ve learned is that clarity in code is paramount. Writing software is much more akin to writing clear, concise prose than to engineering or hard science. Clarity should be the primary goal, and everything else should be secondary.

Clarity in software comes from rewriting and refining code, just as good writing comes from editing and revising. It’s not enough to write code that works; it must be clear and understandable to others, including your future self. This focus on clarity can only be achieved by reading and writing a lot of software, developing an eye for what is clear and what is not.

Conclusion

In conclusion, my journey in software development has taught me that the most important skill is not mastering complex algorithms or adhering strictly to methodologies like TDD. Instead, it’s about writing clear, understandable code that effectively solves problems. By embracing the identity of a software writer rather than a software engineer, I have found greater satisfaction in my work and a deeper understanding of what it truly means to create good software.