RailsConf 2012

Summarized using AI

Keynote: Progress

David Heinemeier Hansson • August 22, 2012 • Austin, TX

In this keynote speech at Rails Conf 2012, David Heinemeier Hansson, the creator of Ruby on Rails and a partner at 37signals, explores the concept of progress within the context of software development. Heinemeier Hansson shares insights from his decade-long experience with Ruby on Rails, emphasizing the importance of continuous progress in keeping developers engaged with the framework and the community.

Key points discussed during the presentation include:

- Defining Progress: Progress is generally viewed positively, but Heinemeier Hansson challenges the audience to think critically about the kind of progress that is not universally accepted. He argues that true progress often provokes discomfort and debate within the community.
- Examples of Progress: The speaker cites various instances in which advancements, such as the introduction of REST and the asset pipeline in Rails, met with resistance despite their eventual acceptance. He covers the transition to Ruby 1.9, Bundler, Rails 3, and Coffeescript, showing how these changes were initially met with skepticism.
- Curiosity vs. Suspicion: Heinemeier Hansson highlights a common transition from being curious about new technologies to becoming suspicious of them, which he associates with loss aversion. He describes how developers often resist progress after experiencing frustrations or failures associated with upgrades or new features.
- Age and Experience: The speaker compares the evolution of attitudes toward progress with aging, suggesting that as developers accumulate knowledge, they may become conservative in their approach to new technologies out of fear of losing what they have.
- Loss Aversion: He discusses how a fear of loss inhibits progress and calls for a mental shift from suspicion to curiosity, suggesting that embracing change is crucial for ongoing development.

In conclusion, Heinemeier Hansson advocates for maintaining a youthful, curious mindset when facing technological changes. Instead of fearing those changes, developers should embrace progress, acknowledging its difficulties as part of the learning process. He encourages the audience to stay engaged with the evolution of technology, suggesting that doing so will lead to personal and community growth in the software domain. The overarching message is a rallying cry to "stay young, stay curious, stay hippie."

Keynote: Progress
David Heinemeier Hansson • August 22, 2012 • Austin, TX

David Heinemeier Hansson is a partner at 37signals, a privately-held Chicago-based company committed to building the best web-based tools possible with the least number of features necessary.

37signals' products include Basecamp, Highrise, Backpack, Campfire, Ta-da List, and Writeboard. 37signals' products do less than the competition -- intentionally.

He is also the creator of Ruby on Rails.

RailsConf 2012

00:00:17.039 I have always been looking for ways to make people smile. Since we get hungry every day, we have to cook every day. Even though cooking is fun, doing it every day makes it a necessary task. We want to inspire people to enjoy cooking more.
00:00:46.719 Alright, let's talk about progress. I've been working with Ruby on Rails for close to a decade now, which is a long enough time to be one of the few people eligible to apply for the New York library position that requires eight years of Rails experience. I’m very happy about that, and I’m also pleased to still be here because I usually don't have an attention span that lasts a decade. The only reason I’m still interested is that over the past decade, we’ve managed to keep not only myself but a lot of other people engaged with the framework and the language by making progress every single year, almost every single day. There’s a flurry of new commits going to the Rails source. Some changes are tiny fixes, like correcting spelling mistakes in the documentation, while others are huge new features. The important part is that we are constantly making progress.
00:01:36.240 Now, this concept of progress is something I want to explore a bit more. When you think about progress as an abstract idea, most people would agree that they like progress. After all, who doesn’t like new things, improvements, and changes that make their world better? However, when you think about it more concretely, things become a bit more complicated. For instance, think of COBOL code—many in the community would agree it's great that we’ve moved on from that. Recently, our agreement on what constitutes progress has expanded to include other languages, like Java, and we can laugh together about the things that we’ve improved upon.
00:02:17.360 Of course, not all progress is universally accepted. For example, there was significant resistance when I first started discussing REST with the release of Rails 1.2 in 2006. Many people did not see this as progress. They thought it was unnecessary and complicated, requiring them to fill out a routes file instead of relying on automatic controller actions. Today, however, few cling to that belief, at least not in this room. We take REST for granted, and it has become a standard in our work.
00:02:37.600 The move to Ruby 1.9 is another topic of contention. Many of you in this room may still be using Ruby 1.8 for your main production systems. I have often heard questions surrounding the necessity of Ruby 1.9 and if the improvements are worth rewriting existing software. There is a sense of reluctance to upgrade, and this is a hurdle for many. Similarly, consider Bundler. When Yahuda and Kyle introduced Bundler, many were skeptical about its supposed advantages. I thought it was wonderful from the start because I had faced the hassle of managing dependencies across multiple applications. But not everyone shared my enthusiasm.
00:03:37.360 This continuous evolution within the Rails community isn't always embraced. People had difficulty transitioning to Rails 3, and there was a lot of hesitation regarding the changes necessary for that upgrade. The launch of the Asset Pipeline further exemplifies this resistance. Some people preferred their old clunky systems, feeling no need to reorganize their workflow. The irony is that, while progress in theory seems desirable, its practical implications often meet with skepticism. When discussing progress abstractly, most people will agree that they like it, but when it's personal and impacts their work, the acceptance becomes significantly more complex.
00:04:20.480 Let's talk about CoffeeScript, a change that has sparked considerable debate. Many developers are accustomed to writing JavaScript in their traditional manner, and CoffeeScript’s different syntax is often viewed as foreign and unnatural. The typical sentiment becomes: 'the old way is better.' This perception isn’t restricted to developers alone; many people resist change across various fields. For instance, when new versions of operating systems come out, individuals often lament the changes, even if they eventually adjust and appreciate those updates. Not all new advancements necessarily lead to genuine improvement. There are plenty of new features that just add complexity without real benefits.
00:05:20.640 In software development, unlike literary analysis, we can measure progress in more tangible ways. If you alter a car's design and it takes longer to complete a lap on the track, then that change has not improved performance. The same applies to software programming; if the code becomes more complicated without enhancing functionality, the changes are counterproductive. However, if you modify a system and it yields better outcomes, that is clear, measurable progress. I enjoy the advancement in software development; when I compare past code to today’s, the improvements are evident.
00:06:01.680 Skepticism towards progress is natural, and it's crucial not to embrace new technologies blindly. We should remain open to innovation without defaulting to skepticism because that is when stagnation occurs. I have two main theories about why people become suspicious of progress. The first illustrates how an initial positive experience can lead to eventual wariness. Many start out curious about technology but eventually experience a setback or failure—like losing data or encountering bugs—leading to distrust. This transition can be perceived as a negative inflection point in their relationship with technology, often leading them to reject new developments, and I can understand that reaction.
00:07:30.240 The second theory, however, reflects a more insidious trend that often accompanies aging—getting used to existing methods and becoming resistant to change. While some individuals maintain a youthful mindset towards learning and adaptation, many find themselves in a 'mr mature' mindset, feeling satisfied with their accumulated knowledge yet fearful of loss. This transformation can occur much faster in technology than in other life areas, leading individuals to turn wary of change in as little as three to five years in their career. This accelerated timeline intensifies the aversion to new development and innovation.
00:08:20.040 When developers transition from being open and curious to suspicious, it becomes difficult to revert. Not many individuals wake up and decide to reject their established routines for simpler, more experimental methods. This tendency reinforces a cautious mentality that stifles progress within the community. I believe that recognizing and addressing this behavior critically affects the vitality of communities in technology, especially involving frameworks like Rails.
00:09:34.560 The concept of loss aversion is pivotal here. People tend to fear loss far more than they value gains. This perspective translates to technology; as developers grow accustomed to their tools and knowledge, any potential loss—be it functionality or knowledge—sparks anxiety. However, studies involving cognitive reframing demonstrate that people can shift their mindset from a fear-oriented approach to one where they view their work and learning as valuable. By reframing how we approach new challenges, we can resist the tendency to remain in a 'mr dummy' state or revert to the safer confines of our comfortable knowledge.
00:10:38.560 We should encourage continuous learning rather than avoiding risks associated with progress. Each of us has the capability to set high expectations and pursue knowledge eagerly. I can share from my experience: when I began immersing myself in Ruby, I quickly moved on to Rails without anyone setting limitations on my learning timeline. Had I been told 'you must learn X before you can proceed,' my growth would have been stunted. Instead, I learned through engagement, which reflects how we should encourage newcomers to approach technology.
00:11:45.760 The motto should be: accept that progress, while often challenging, is part of the journey to mastery. We will inevitably face difficulties while learning, but this is not a deterrent; it's a necessary reality. Future iterations of technology, such as Rails 4, will bring significant changes. Initially, you may feel discomfort with the new systems—but as you acknowledge this as a natural reaction to progress, you can better cope and adapt. Remember, I will not fear change, and I will not fight progress.
00:13:30.240 In conclusion, remain youthful and open to exploring—stay curious and embrace the exuberance of progress. Thank you very much.
Explore all talks recorded at RailsConf 2012
+65