DHH on Ruby, Small Teams, AI and Building a Life

DHH recalls wanting a Commodore 64, learning to use an Amstrad computer, and trying unsuccessfully to type in games and learn Easy Amos. He describes the Amiga demo scene, running a bulletin board system as a teenager, trading software, and attending demo parties.

DHH explains how making basic HTML pages in school revived his interest in programming, followed by work on gaming websites and a gradual move from ASP to PHP. He describes the immediacy of deploying PHP and argues that modern web development has often added complexity to relatively straightforward applications.

DHH and Lex discuss simple development practices, version control and Rails’ no-build approach. DHH criticizes the churn and build pipelines of the JavaScript ecosystem while distinguishing his dislike of its tooling history from his view of JavaScript as a language.

DHH traces browser stagnation and subsequent progress through Firefox and Chrome. He discusses the complexity of maintaining browser compatibility, the importance of independent browser engines, and why he credits Chrome with helping the open web while acknowledging concerns about Google.

DHH argues that breaking up Chrome would harm the open web and says browser competition is not the central problem in technology monopolies. The discussion extends to cookie banners and the consequences of regulation, then considers Chrome’s distribution, alternatives including Firefox, Safari and Edge, and browser engines on iOS and Android.

DHH explains that PHP taught him programming but Ruby changed how he thought about himself as a programmer. He recounts meeting Jason Fried through an email exchange, working together on client projects, and choosing Ruby for the project that became Basecamp.

Using examples such as iteration, conditionals and method names, DHH explains why he finds Ruby’s syntax readable and expressive. He contrasts Ruby’s human-oriented design with more rigid conventions and describes Matz’s stated priority of programmer happiness.

DHH contrasts different views of programmers in language design and describes Ruby’s openness to extending classes, including Rails’ Active Support. He reflects on Ruby’s influences and longevity, the difference between readability and excessive compression, and the work required to make Ruby both expressive and efficient.

DHH explains metaprogramming through Rails examples such as Active Record associations. He describes how Rails uses Ruby to create domain-specific language constructs that express database relationships in readable terms.

DHH defends dynamic typing, metaprogramming and text editors, while recognizing that different project scales can call for different tools. He uses Shopify to argue that Ruby on Rails can support very large systems and discusses how Ruby’s productivity can help a product grow from a solo developer’s project.

The conversation covers Shopify’s YJIT compiler and the difference between request latency and horizontal scaling. DHH says database challenges often matter more than programming-language choice for scaling, and argues that human productivity can outweigh savings from faster execution in many business applications.

DHH describes using AI for explanations, research and second opinions while preferring to type code himself. He worries that delegating too much can weaken programming skills, compares learning to practicing an instrument, and says programming itself—not only its output—can be a source of enjoyment.

Lex and DHH discuss AI’s value as a patient, encouraging learning tool and as a way to try unfamiliar programming domains. They consider whether manual programming could become less economically important, the possible effect on hiring, and why DHH views his own decades of programming work with gratitude.

The speakers debate how aspiring programmers should balance writing code from scratch with AI-assisted or “vibe” coding. DHH recommends doing the work to build real competence, while allowing that the future is uncertain. They discuss AI’s tendency to produce flawed systems and whether editing generated code can become a distinct skill.

DHH explains why he wrote down Rails’ principles, including programmer happiness, accepting useful ambiguity and convention over configuration. He describes Rails as a preassembled toolkit with strong defaults and discusses its integrated approach to building web applications.

DHH argues against premature decomposition into microservices and says small teams should keep systems understandable as a whole. He discusses Basecamp and Hay, their limited JavaScript use, and his opposition to splitting front-end and back-end development into disconnected work.

DHH describes Ruby and Rails as drawing on more than one programming paradigm, and discusses readable code and Active Record’s role in connecting objects to SQL databases. He argues that Rails should lower the barrier to entry while inviting developers to gain deeper competence, including learning SQL.

DHH discusses trusting programmers with powerful tools and revisits Rails’ principle of progress over stability, saying his experience of JavaScript churn changed how he would frame it now. He reflects on how some of his views have changed and how others have returned after testing alternatives.

DHH explains why he and 37signals tried engineering managers and later returned to a less managerial approach. He argues that programmers benefit from learning from people skilled in the work, long stretches of focused time and fewer meetings. He also discusses 37signals’ finance staffing and its response to a sales-tax problem.

DHH argues that small teams can make valuable products without the coordination costs of large organizations. He recalls building the first version of Basecamp and says smallness need not be merely a stage on the way to a much larger company.

DHH describes avoiding venture capital and explains Jeff Bezos’s purchase of a stake in Basecamp as providing financial security without growth capital for the company. He reflects on Bezos’s long-term thinking and on how successful, widely used companies can attract both strong support and strong criticism.

DHH describes the intense but idea-focused disagreements he and Jason Fried had, and how trust in their different strengths helped their partnership. He discusses their limited direct communication, preference for independent work and skepticism about meetings and constant brainstorming.

DHH responds to Lex’s question about loneliness in remote work by discussing family and relationships outside work. He argues that a sustainable career should leave room for family, hobbies and friendships, and challenges the idea that a business must become a venture-backed giant to count as a success.

DHH argues that creative people may not find lasting fulfilment in retirement and discusses flow as the satisfaction of stretching one’s abilities. He reflects on the difficulty of repeating an initial business success, the value of learning through experience, and balancing ambition with other interests and responsibilities.

DHH explains why 37signals moved applications from AWS to its own servers in a data center, describing the company’s cloud costs, the work involved and the savings he expects. He argues that cloud services are not always cheaper or simpler, while acknowledging their speed and the operational advantages they helped make possible.

DHH describes exploring home server setups and says modern computing and internet connections may make it practical to host services from home. He distinguishes leaving the cloud from leaving a professionally managed data center and discusses hardware ownership at different scales.

The conversation turns to how ambitious missions attract talent and how leaders can assess people by their work. DHH discusses hiring through writing and programming tests, and the ability of technically knowledgeable leaders to challenge teams to simplify. They compare this with Steve Jobs and discuss Apple’s leadership.

DHH recounts his long history as an Apple supporter and explains how the App Store’s rules changed his view. He describes Hey’s iOS app approval dispute over Apple’s in-app payment requirements, the public campaign that followed and the outcome he says allowed Hey to remain in the store. He also discusses Epic’s legal challenge and its consequences for app payments.

DHH discusses the conviction required to challenge a powerful company and says he is disappointed in Apple rather than simply hostile to it. He considers the effects of Apple’s App Store policies, its hardware and design strengths, competition and leadership, and warns that large companies do not necessarily remain successful indefinitely.

DHH describes how meeting his wife, Jamie, led him to have a family and how becoming a father changed his sense of what matters. He discusses the emotional experience of parenting, relationships and marriage, and the value and responsibilities of raising children.

The discussion considers the effects of social changes, religion and relationship technology. DHH explains how a supportive family arrangement has allowed him to maintain a 40-hour workweek, while children give his schedule boundaries and encourage focused work. He also talks about sharing games and go-karting with his children.

DHH recounts getting his driver’s license at 25, discovering race cars, and pursuing competition after years of track driving. He explains the appeal of driving at the limit of adhesion, the flow and danger of racing, and his path to Le Mans. He and Lex watch and discuss a close on-track battle.

DHH discusses being a gentleman driver, crashes and the responsibility he feels to a racing team. He recalls injuries and fatal accidents in motorsport, including a fatal Le Mans crash, and explains how he studies braking, acceleration, data and changing tire grip to drive consistently.

DHH discusses the obsession, sensitivity and reaction time associated with elite drivers, along with the role of nerve and risk in overtaking. He reflects on changes in racing safety, comparing drivers across eras and noting that modern sponsorship can affect drivers’ public personas.

DHH explains why the Pagani Zonda is his favourite car and why he values it as a road car rather than a track car. He discusses speed limits, the Autobahn and the sensation of driving at high speed, including his fastest racing speeds.

DHH describes moving from Mac to Linux and details his single-monitor setup, low-profile mechanical keyboard and mouse. He discusses Linux customization, keyboard control and virtual desktops, and explains why he finds the responsiveness of his current setup useful.

DHH recounts his involvement with TextMate and his move to NeoVim, including the role of the LazyVim distribution. He explains his dislike of TypeScript’s extra typing and type gymnastics, while saying people who prefer it should continue using it.

DHH recommends Ruby as a beginner-friendly language and Rails for people who want to build web applications, alongside JavaScript for web work and Go for tasks such as HTTP proxies. He discusses the limits of Ruby for low-level or performance-intensive work and his preference for object-oriented programming.

DHH describes himself as a software writer rather than an engineer and compares programming with the process of writing: solutions emerge while working. He and Lex discuss trusting experience and intuition, acting before inspiration fades, and the value of figuring out a project as it develops.

DHH argues that open-source maintainers should not treat users as customers entitled to direct their time or work. He describes open source as an exchange of gifts, says contributors should build software they themselves need, and distinguishes that approach from commercial software and paid employment.

DHH praises WordPress’s impact but criticizes Matt Mullenweg’s dispute with WP Engine, arguing that open-source users may use software under the terms of its license and should not face new demands after the fact. He explains why he sees licenses as essential to trust between open-source and commercial software, and urges restraint from project leaders.

DHH reflects on the reach of Ruby on Rails and why he does not regret that others have built valuable companies with it. He describes programming as a source of flow, an empty schedule as a form of tranquillity, and money as useful but unable to resolve every human concern. He places family, friends, meaningful work and hobbies ahead of wealth alone.

Asked about the future, DHH says he finds it easier to be optimistic because no one can reliably predict how complex events will unfold. He discusses climate concerns, technology and historical uncertainty, and argues for humility about expertise. The conversation ends with reflections on human cooperation, compassion and the capacity for both kindness and cruelty.