Pioneers Insight Method Research Author
DHH: Future of Programming, AI, Ruby on Rails, Productivity & Parenting | Lex Fridman Podcast #474
Back to Episodes

DHH: Future of Programming, AI, Ruby on Rails, Productivity & Parenting | Lex Fridman Podcast #474

Summary

  • DHH’s core product thesis is that developer leverage comes from removing ceremony, not accumulating architecture. Rails 8’s “no build” approach tries to combine modern capability with late-1990s PHP immediacy, when changing a text file and reloading meant it was deployed. Web applications still often create, read, update, and delete database rows; his provocation is that “CRUD monkeys” compensate for that mundane reality by buying complexity they do not need.
  • Shopify is DHH’s strongest evidence that concise, dynamically typed software can scale from one founder to global infrastructure. He cites roughly 1 million dynamic requests per second on Black Friday, about 30% of internet e-commerce stores, a roughly $120 billion market cap, nearly 10,000 employees, and a Rails monolith around 5 million lines. The economic distinction matters: latency must stay below roughly 300 milliseconds—he targets 100—but throughput scales horizontally, while most companies spend far more on “wetware cores” than CPU cores.
  • AI already raises programmer leverage, but DHH sees a dangerous split between producing code and acquiring competence. He uses AI continuously as a patient pair programmer, research tool, and beginner’s guide, yet keeps it in another window and often types the implementation himself because “you learn with your fingers.” Lex argues that iterative prompting and editing might become a serious new skill; DHH’s harder answer is that “editing is the reward” for first becoming a capable doer, while acknowledging that “nobody fucking knows anything” about even the next six months.
  • The organizational corollary is that tiny, technically strong teams can create disproportionate enterprise value when communication and management overhead stay near zero. Basecamp’s first version took DHH about 400 billed hours, and 37signals still organizes much work around one programmer, one designer, and one feature. His anti-scale formula is explicit: avoid growth capital, preserve uninterrupted time, and remember that a thousand programmers will produce “the kind of software that a thousand people build,” not a more polished version of what two people make.
  • Leaving AWS turned infrastructure discipline into a multimillion-dollar operating-margin decision for 37signals. DHH says its AWS bill peaked around $3.2 million–$3.4 million; moving seven major applications to owned hardware in just over six months cut infrastructure spending by roughly one-half to two-thirds, or about $2 million per year, with projected five-year savings near $10 million. His qualification is important: cloud elasticity is unrivaled if 1,000 machines are needed in 15 minutes, but predictable workloads often make long-term renting irrational—especially when AWS earns margins near 40%.
  • DHH distinguishes productive platform power from extractive toll booths, rejecting a DOJ breakup of Chrome while celebrating Epic’s fight against Apple. Chrome, in his view, won largely on merit and helped keep the open web competitive; Apple’s App Store instead demanded 30% of businesses it neither built nor acquired, nearly blocking HEY after launch. Epic reportedly spent more than $100 million to obtain the right to link users to web payment, showing why founder-controlled companies—and what DHH calls “unreasonable” conviction—can produce ecosystem-wide returns conventional boards would never underwrite.
  • His open-source compact is equally hard-edged: maintainers give gifts under explicit licenses, not customer-service obligations or retroactive revenue claims. Rails is sustained because DHH builds what he needs and accepts compatible contributions, while the permissive MIT license says, in effect, “do whatever the hell you want” without warranty. That principle drives his criticism of Matt Mullenweg’s campaign against WP Engine: perceived under-contribution cannot justify rewriting the bargain after another company succeeds.
  • The deepest long-duration thesis is that flow, family, and autonomy outperform both maximal wealth and permanent hustle as sources of resilient output. DHH works roughly 40 structured hours, prizes “an empty schedule,” and says fatherhood expanded his perceived satisfaction scale from 1–10 to 1–100; racing supplies reliable flow by demanding complete attention at the edge of adhesion. His closing posture is deliberately anti-forecast: civilization repeatedly creates and solves new problems, so “we suffer more in our imagination than we do in reality,” and optimism is the better default when certainty is unavailable.

Deep dive

1. Programming clicked only after two failures and one tiny success

  • DHH first encountered a Commodore 64 at age five through Yie Ar Kung-Fu, then received an Amstrad CPC 464 from his father instead. Wanting games he could not afford, he typed magazine source listings for hours, inevitably made an error, and received messages his six-year-old, Danish-speaking self could not decipher.

  • His most vivid conceptual failure was the variable: constants made sense, but why assign something and later change it? Discovering piracy removed the practical incentive to struggle through programming, because copied games supplied the outcome he had wanted without requiring the skill.

  • At 11 or 12, the Amiga 500 and a language literally called Easy AMOS tempted him back. He reached loops and conditionals but never finished even a basic game, concluding that programming might require a kind of mathematical intelligence he did not possess: “Maybe I’m not smart enough.”

  • That history informs his obsession with an easy first success. Both early attempts demanded hours of preparation before returning an incomprehensible failure; the web later changed his trajectory because one HTML tag produced visible feedback immediately.

2. The Amiga scene taught him networks before it taught him code

  • DHH still calls the Amiga perhaps his favorite computer, partly because computing had not yet become globally homogeneous. The Amiga dominated parts of Europe while Apple II meant little to a Copenhagen child; each territory had its own machines, cultures, and aesthetic.

  • He admired Europe’s demo groups, which combined graphics and MOD music into programs as small as 4 kilobytes. Unable to match friends writing assembler, he joined the surrounding distribution culture instead and ran a bulletin-board system from his bedroom.

  • At 14, his Amiga 4000 had three telephone lines and blinking modems, puzzling the technician who installed the third. His parents understood the hardware but not necessarily the pirated-software trade; he later traveled by train with older hackers and a 14-inch CRT to The Party, where thousands created side by side.

3. HTML and PHP supplied the ergonomic high he still pursues

  • During a ninth-grade university excursion around 1995, DHH received a text editor, an early browser, and permission to build. Making text blink, changing its size, and realizing someone in Germany could see it without anyone’s approval was the positive feedback loop his earlier programming attempts lacked.

  • He joined former demo-scene contacts on gaming websites, wrote reviews, and presented himself to shops as a 15-year-old journalist so he could borrow PlayStation games. HTML was not quite programming, but it “smells like it”: he was instructing a computer and publishing globally.

  • After early dynamic work in ASP, PHP finally made variables, loops, and conditionals cohere. Its late-1990s workflow became his ergonomic benchmark: write a script, FTP it to Apache with mod_php, reload, and “boom, it’s right there”—no build pipeline, framework ceremony, or server setup.

  • Lex jokes that DHH therefore owes his career to PHP; DHH answers, “100%, that’s true.” Pieter Levels proves to him that the old model is not merely nostalgia: one person still runs real businesses with PHP, jQuery, and SQLite, even if teams eventually require coordination tools such as version control.

4. Rails 8 treats complexity as a choice, not progress

  • DHH’s deliberately abrasive diagnosis is that many web developers remain “CRUD monkeys”: they build forms that create, read, update, and delete database rows, then overcomplicate that modest task to soothe the existential discomfort of admitting it.

  • His target is not a literal return to the 1990s, whose tooling also failed in many ways. Rails 8’s “no build” direction instead tries to retain 20 years of improvements while recovering the immediacy of changing a text file and refreshing the browser.

  • Faster computers should have made development simpler than it was in the 1990s, he argues, yet the industry surrendered ergonomics to “the merchants of complexity.” Rails is his attempt to make sophisticated systems arrive preassembled without shortening the runway from beginner project to serious business.

5. JavaScript’s build era was a bridge, not a destination

  • DHH calls JavaScript his second-favorite language—a very distant second to Ruby—and defends modern ES6, especially its proper class syntax. His complaint is not the language’s infamous coercion examples: “Why would you do that? Just don’t do that.”

  • The “dark ages” began when browsers could not execute the pleasant dialect developers wanted, making transpilers, Webpack, and dependency pipelines defensible. The experience nevertheless became absurd: he could leave a JavaScript project for “literally five minutes” and return to something that no longer compiled.

  • From roughly 2010 to 2020, frameworks churned so quickly that three-month-old knowledge was treated as evidence of incompetence. DHH calls that an “asylum” whose inhabitants rationalized endless rewrites because only people trapped inside could regard constant breakage as normal.

  • His charitable revision is that some complexity was a bridge. Firefox, then Chrome, restarted browser evolution after Microsoft won with IE5 and effectively froze development; today browsers can execute excellent JavaScript directly from text files, making much of that pipeline expendable.

6. Chrome rescued the open web even as browser monoculture remains dangerous

  • Browser compatibility is an extraordinary hidden achievement: DHH’s ninth-grade page would still render roughly 30 years later. Supporting nearly every page ever published makes a new engine “essentially an Apollo project,” explaining why Microsoft eventually adopted Chromium for Edge.

  • He supports the independent Ladybird browser because a single-engine monoculture threatens the web. Yet he simultaneously regards Chrome as “a complete gift to web developers,” because Google’s business had enough value riding on an open web to keep Apple and Microsoft from reducing it to a feeder for controlled native platforms.

  • DHH opposes the DOJ’s effort to separate Chrome from Google, despite broadly sympathizing with antitrust enforcement. Firefox and Safari provide alternatives, Android permits browsers with independent engines, and customers using 37signals products are never forced through Chrome; he therefore says Chrome “won on merits.”

  • The stronger monopoly cases, in his view, concern mobile toll booths and Google controlling both supply and demand in advertising. Lex agrees that Chrome’s technical and competitive contribution is immeasurable; their shared warning is that intervention can make an imperfect system worse.

7. Cookie banners are DHH’s monument to failed regulation

  • DHH treats the GDPR-era cookie banner as the canonical case of “good intentions leading straight to hell.” It consumes human time, protects no privacy in his assessment, and has enriched lawyers, accountants, and bureaucrats while making the entire web uglier.

  • The deeper indictment is institutional rigidity: after roughly 10 or 12 years, “no one anywhere who’s serious” thinks the banners help, yet governments cannot remove them. Their reach supplies his best comic summary: even on Mars, with a long communications delay, users would still be waiting to accept cookies—“No one in the universe is safe from this nonsense.”

8. Basecamp created the opening through which Ruby entered DHH’s life

  • DHH met Jason Fried in 2001 after emailing an answer to a PHP question from Copenhagen to Chicago. They moved from correspondence to paid client work and remain partners 24 years later, which DHH presents as a small miracle of the permissionless internet.

  • Their clients repeatedly began projects in email, then lost context among new participants, FTP directories, and files named variants of “final final V6 2.0.” After dropping consequential balls, they asked whether blogs and to-do lists could be combined into a project system simple enough to require only a login, not a seminar.

  • Basecamp was the first project on which DHH controlled the technology. Articles by Dave Thomas and Martin Fowler used Ruby as readable pseudocode for design patterns, leading him to investigate a language Matz had begun in 1993 and that remained obscure in the West a decade later.

  • DHH allotted himself two weeks to prove Ruby could query a database and display HTML. It took one weekend: Ruby fit his brain “like a perfect tailored glove,” and unlike PHP, it made him identify as a programmer rather than someone hitting a computer until an application emerged.

9. Ruby’s smallest expressions reveal its largest design commitment

  • The first thing DHH noticed was what Ruby omitted: semicolons. Their absence signaled that someone was optimizing for the human rather than making the parser’s work convenient, revealing that code aesthetics could be an objective instead of an incidental preference.

  • His signature example is 5.times: an integer is an object, and calling times iterates a block five times. Lex’s reaction—“That’s really nice”—captures the effect DHH values: a concept compressed to an expression from which nothing superfluous can be removed.

  • Python shares Ruby’s dynamic, interpreted, productivity-oriented ethos, but DHH rejects its aesthetics. He contrasts Python’s __init__(self, ...) with Ruby’s def initialize, arguing that the most important initializer should not be wrapped in underscores, abbreviations, or mandatory punctuation.

  • Ruby’s conditional vocabulary compounds the effect: if user.admin?, a statement followed by if, or user.downgrade unless user.admin?. The question mark communicates only to humans, while unless eliminates a negation; the machine receives equivalent instructions, but the person receives something approaching poetry.

10. Matz designed Ruby around trust in programmers

  • DHH contrasts Matz’s stated goal of programmer happiness with James Gosling’s account of Java. Gosling, as DHH interprets him, designed for ordinary programmers who might misuse sophisticated power; Matz assumed people could learn, improve, and deserve “sharp knives.”

  • Ruby lets strangers extend foundational classes. Rails’ Active Support adds days to numbers, so 5.days can represent the seconds in a five-day cache expiration; code written by DHH can appear indistinguishable from language-level code written by Matz.

  • Lex pushes back that compression alone can become Perl golf—short but unreadable. DHH agrees, crediting Ruby’s advantage partly to Matz studying Perl, Python, Smalltalk, and Lisp, then editing their strongest ideas; remarkably, he says roughly 90% of Ruby’s first design still holds after more than 30 years.

11. Metaprogramming makes Rails read like a language for each domain

  • DHH describes metaprogramming as turning Ruby’s openness “up to 11.” In Active Record, a User class can declare has_many :comments; that one line creates association, access, creation, and update behavior while looking like a native keyword.

  • Rails uses such declarations to form domain-specific languages: has_many, belongs_to, validations, and other constructs translate business relationships into readable class definitions. The achievement, for DHH, is not inventing metaprogramming but eliminating the line noise that exposes its machinery elsewhere.

  • Lex defends Lisp as his first love and notes that it pioneered similar powers. DHH admits he has never written serious Lisp, joking that “I have two eyes” with which to judge its parentheses; he recognizes that as a limitation and says Smalltalk has already taught him much about programming-language history.

12. Dynamic typing is inseparable from the Ruby bargain

  • DHH would “defend dynamic typing to the death” because static declarations impede metaprogramming and repeat information Ruby otherwise compresses. His caricature—type User, variable user, then User.new—repeats the same concept three times: “I don’t have time for this.”

  • He removed TypeScript from Turbo after trying to write metaprogramming through its type system. JavaScript’s dynamism smells like Ruby to him; TypeScript adds type gymnastics, extra characters, and frequent retreats to any, while offering autocomplete and editor guarantees he does not personally value.

  • That rejection is linked to tools. DHH writes in a text editor, without autocomplete, because manually producing every character applies pressure against boilerplate: once a language makes repetitive code painless to generate, its community becomes tolerant of much more of it.

  • He fully concedes the other domain. Systems with 5 million or 50 million lines and thousands of contributors may need stronger constraints, but it is “complete nonsense” to impose the methods of a 100,000-programmer system on one person building a bedroom application.

13. Shopify demonstrates Rails’ unusually long runway

  • DHH once evangelized Rails as though every web programmer merely needed to hear the gospel. He now accepts that brains differ: some people want IDE and compiler security, while his mind fits dynamic duck typing and a text editor; his objection is only to declaring one temperament universally correct.

  • Shopify is his evidence against the categorical claim that Rails cannot scale. He cites roughly 1 million dynamic requests per second on Black Friday, about 30% of internet e-commerce stores, nearly 10,000 employees, a market capitalization around $120 billion, and annual gross merchandise volume near a quarter-trillion dollars.

  • Shopify’s Rails monolith is about 5 million lines, a frontier where every language encounters human limits. DHH estimates equivalent Go or Java code might occupy 25 million or 50 million lines—possibly buying some local safety while multiplying the total system people must comprehend.

  • The more important target is Shopify before Shopify: Tobi building Snowdevil, the snowboard store that preceded the platform. Rails aims first at the individual whose productivity can create the seed; it keeps a runway long enough that the seed need not be discarded if it becomes critical infrastructure.

14. Scaling arguments confuse latency, throughput, and economics

  • YJIT, developed at Shopify, makes Ruby execution materially more efficient; even 5% or 10% matters at Shopify’s scale. Yet DHH stresses that Shopify existed before YJIT and initially ran on Ruby 1.8.6, which he recalls as roughly ten times slower than today’s implementation.

  • Performance first means request latency: a response taking 1.5 seconds feels broken, so DHH wants at least below 300 milliseconds and personally targets 100. Scale as throughput is different: if one box handles 1,000 requests per second, additional boxes can carry the system toward 1 million.

  • Languages generally scale horizontally; the harder constraint becomes shared state, especially databases such as MySQL and the problem of worldwide consistency and performance. Faster Ruby mainly changes the number and cost of application servers, not whether horizontal growth is possible.

  • DHH calls Ruby “the Coco Chanel of programming languages,” a luxury some ultra-low-value requests cannot afford. But for 99% of business applications, the expensive resource is “wetware cores”: when Ruby servers represented about 15% of 37signals’ operating budget, modest human-productivity gains outweighed even drastic compute savings.

15. AI is most useful to DHH as a high-bandwidth pair programmer

  • Lex argues that AI collaboration increases the value of readable code: generated Perl golf would not be a collaboration because the human could not inspect or alter it. DHH agrees that Ruby compresses more concept per character, increasing communication bandwidth between the model and programmer.

  • He keeps AI in a separate window instead of letting Cursor or Windsurf drive his editor. Claude Code in the terminal is his preferred agentic interface, though it can feel too slow after 20 years without compile waits: he becomes impatient while it thinks.

  • Used as a research partner, AI has already become indispensable. It explains APIs, offers second opinions, drafts approaches, and answers “stupid questions” without Stack Overflow’s judgment; DHH estimates that such learning might leave him half a percent smarter by the end of a day, which can compound.

  • Lex adds that the model’s relentless positivity makes programming more fun: it behaves like a smart hype partner that concedes corrections without ego. DHH recognizes the old pair-programming benefits without the exhausting social exposure that, as an introvert, he could tolerate with a human for only about five minutes.

16. Letting AI type can create output while draining competence

  • While building Omakub, DHH used AI to generate Bash he had never properly learned. He repeatedly requested the same conditional syntax because, without typing it, he was using the expression but not retaining it; the experience frightened him: “Is this the end of learning?”

  • His compromise is to ask AI for explanations, APIs, and drafts, then type the implementation himself. The analogy is physical practice: watching guitar lessons cannot teach the fingers to play, and programming likewise includes motor and cognitive patterns acquired by doing.

  • DHH has watched senior programmers lose touch before AI: promotion fills calendars with meetings, the keyboard disappears, and technical feel decays quickly. Programming is not merely an economic route to software; like playing “Stairway to Heaven” despite a perfect recording, commanding the instrument supplies the human value.

17. Lex and DHH disagree over whether vibe coding can become a durable craft

  • Lex refuses to dismiss vibe coding as tapping “yes” repeatedly. Iterative prompting, understanding a model’s style, and learning to repair generated systems might become a distinct editorial craft whose best practitioners outperform people starting every file from nothing.

  • DHH’s answer is categorical: “Editing is the reward” earned by being a good writer or doer first. Every strong editor he has known possessed writing ability, because diagnosing a flawed solution generally requires knowing how to produce the solution oneself.

  • He nevertheless accepts that natural-language software generation may soon work extremely well. That future would be more democratic than a priesthood of prompt engineers: ordinary people could state messy intentions, receive software, revise their intent, and repeat the cycle that clients historically performed with programmers.

  • Current vibe-coded products, in DHH’s account, fail early beneath a convincing veneer. He cites leaked API keys and plain-text passwords as solvable symptoms; the deeper problem is an agent getting lost in its own labyrinth, fixing one behavior while breaking five others until the system “keeps biting its own tail.”

18. Nobody can tell whether manual programming is a horse or an airplane

  • DHH treats “nobody fucking knows anything” as rule number one. Running DeepSeek locally and watching its visible reasoning felt eerily human and even frightening, yet an extraordinary present capability does not establish the shape of the next six months.

  • His counterexample is 1995’s The Lawnmower Man, which convinced him that immersive virtual reality was five years away. Thirty years later, VR is important in games such as Gorilla Tag and some specialized work, but not the environment where most humans spend their day.

  • Aviation supplies the opposite curve: roughly four decades separated the Wright brothers from jets, then passenger-aircraft design largely plateaued after the 1950s. Early dots invite straight-line extrapolation precisely when a technology may be about to flatten.

  • Manual programming could become like horse transport—economically niche but recreationally beloved. DHH is skeptical of the Anthropic CEO’s reported prediction that 90% of code would be AI-written by year-end, but he is humble enough to say society may stop valuing what he does even while he continues enjoying it.

19. Young programmers should optimize for learning under uncertainty

  • DHH’s advice is simple: if programming appeals to you, learn it, even though no one can promise it remains a career forever. AI may disrupt artists before plumbers, or Tesla’s robots may reverse that sequence; choosing only allegedly safe professions is impossible.

  • He recommends spending more learning time writing from scratch than vibe coding. AI-assisted output can provide “empty calories” that feel like learning, while real competence requires struggling through the program yourself—just as fitness requires the exercise, not viewing the video.

  • The broader hedge is to choose pursuits whose journey remains worthwhile if the market changes. When 37signals starts a product, DHH values all outcomes: failure still buys a green-field problem and beautiful Ruby work; moderate demand funds salaries; a breakout brings wider impact.

20. Rails recorded its values so success would not erase them

  • DHH wrote the Rails Doctrine around 2012 because communities forget why their fences exist. Without articulated values, newcomers reasonably import their own preferences until an institution flails; Chesterton’s fence matters because removing it before understanding it may let the wolves in.

  • “Optimize for programmer happiness” appears first in homage to Matz. It permits ambiguity and human synonyms: an interactive Ruby session accepts both exit and quit, while Python’s prompt, in DHH’s telling, refuses bare exit and responds with a corrective lesson about parentheses or Control-D.

21. Convention over configuration gives developers a finished toy

  • Early Java frameworks required hundreds or thousands of lines of XML to settle details such as foreign-key naming. DHH’s objection is not that configuration lacks expressive power, but that almost nobody cares whether the column is styled post_id, postID, or some other variation.

  • Pick one answer, depend on it, and the answer becomes a convention that no longer needs configuration. Rails therefore arrives preassembled: “I’m not just handing you a box of fucking Legos and asking you to build the Millennium Falcon. I’m giving you a finished toy.”

  • Developers can still disassemble the toy and replace pieces. The purpose is to move their appetite for customization higher in the stack, toward decisions that distinguish the product rather than foundational choices whose alternatives carry no user value.

  • “The menu is omakase” extends the idea across the framework. Unlike JavaScript ecosystems with perhaps 25 controller options multiplied by database and rendering choices, Rails offers a chef-designed menu whose components have been selected and tested as one meal.

22. The monolith preserves comprehension until scale truly defeats it

  • DHH has opposed microservices since the term appeared. At Netflix scale, thousands of engineers and millions of lines may require decomposition; with 20 programmers and half a million lines, converting method calls into network requests is “premature decomposition.”

  • His first rule of distributed programming is “do not distribute your programming.” Networks add partial failures, latency, deployment coordination, and states a local call does not have, making everything harder before product complexity requires the trade.

  • Basecamp and HEY each contain just over 100,000 lines of Ruby, while Basecamp presents roughly 420 screens. DHH believes an individual can comprehend systems in that range, perhaps even two or three times larger; north of roughly half a million lines, the mental model begins to break.

  • He extends integration across front end and back end. Gmail reportedly ships about 28 megabytes of uncompressed JavaScript—roughly 6 megabytes compressed—while HEY launched with about 40 kilobytes; separating browser and server roles, in his view, helped produce needless boundaries and machinery such as GraphQL.

23. Active Record lowers SQL friction without pretending SQL disappeared

  • DHH calls Active Record the crown jewel of Rails. Martin Fowler’s Patterns of Enterprise Application Architecture supplied both the pattern and name: tables become classes, rows become objects, and relationships remain grounded in the relational database that persists them.

  • He rejects object-relational mappers that preserve an imagined pure object world, then invent convoluted translations to storage. Active Record accepts the impurity upfront: attributes correspond to columns, records live in SQL tables, and domain behavior can be layered around that fact.

  • SQL itself is readable, DHH says, but verbose—an INSERT enumerates columns and matching values every time. Active Record removes repetition and composes queries into methods; it does not excuse ignorance of SQL or database behavior.

  • Lex asks whether easy generators make users lazy. DHH’s answer distinguishes entry from mastery: Rails can put a functioning blog in a browser before the learner understands it, but that is an invitation to next week’s SQL lesson, not permission to remain incompetent—“a soft ramp” whose runway goes to infinity.

24. Rails combines paradigms and now values stability more than its doctrine admits

  • “No one paradigm” means Ruby remains fundamentally object-oriented while borrowing functional and imperative techniques where they fit. DHH admires functional programming for the 90% of a problem it may express elegantly, then rejects the contortions required when the remaining 10% genuinely needs mutation.

  • “Provide sharp knives” rejects Java’s protective butter knife. Rails accepts that programmers can cut themselves, learn, and recover because virtual fingers grow back; powerful tools make deeper competence possible and keep the learning ramp rising.

  • “Progress over stability” is the doctrine point DHH would rewrite. After watching JavaScript celebrate three-month churn, he developed greater respect for durability: upgrading Rails 7 to Rails 8 was nearly a non-event, as was Rails 6 to Rails 7.

  • Lex frames technology as usually moving glacially, with the web around 1995, the iPhone in 2007, and today’s AI as three major shifts in his career; DHH agrees that most things do not change quickly. Basecamp’s original Rails code still runs, earns millions in ARR, and remains recognizable.

25. 37signals tested professional management and returned it

  • DHH once rejected engineering managers, later wondered whether every programmer needed a weekly one-on-one, and hired capable managers for several years. The experiment changed his mind back: “No, no, I was right”—most programmers did not need recurring therapy sessions, huddles, and status meetings.

  • The case for management strengthens with headcount: juniors need guidance, coordination work accumulates, and someone must resolve ambiguity. His practical finding, however, is that the structure often manufactures more work and interruption than it removes.

  • The decisive question is whether feedback comes from someone better at the craft. A manager can coach courtesy and communication, but cannot deepen a programmer’s work after losing technical touch; DHH values learning beside strong practitioners over career guidance from a former practitioner turned status collector.

  • He rejects the conclusion that competence excuses cruelty. His narrower claim is that craft history advances through apprenticeship to people who can evaluate the work, while engineering managers rapidly become “pointy-haired bosses” once meetings replace their own programming.

26. Two-person teams eliminate the need for managerial sophistication

  • DHH points to id Software’s tiny group around John Carmack creating Quake as representative, not exceptional: major breakthroughs repeatedly emerge from individuals or small teams. Gmail likewise began as a side project by Paul Buchheit rather than a roadmap administered through layers.

  • At 37signals, the default unit is one programmer, one designer, and one feature. Two people can make, inspect, and revise something without elaborate planning, roadmaps, or management; they can follow truths that emerge from the actual product rather than predictions made 18 months earlier.

  • Basecamp’s first version required about 400 hours of DHH’s labor, tracked because he billed Jason Fried—initially around $15 an hour and later a “glorious” $25. That one programmer’s work became a product that has grossed hundreds of millions of dollars.

  • “Small is not a stepping stone” is the business conclusion. A thousand Microsoft developers could not recreate Basecamp by applying more labor; they would inevitably create “the kind of software that a thousand people build,” with different scope, compromises, and communication costs.

27. Avoiding outside capital preserved 37signals’ right to stop growing

  • DHH’s first defense against unwanted scale is blunt: “Don’t take venture capital.” Investors understandably seek maximal financial return, and B2B SaaS playbooks turn product-market fit into enterprise sales, abandoned small customers, large sales forces, and eventually a thousand-person organization.

  • Jeff Bezos’ investment was structurally different. He bought secondary shares directly from DHH and Jason; none of the money entered 37signals, and each founder received a few million dollars—enough personal security to decline larger checks without fearing that a collapse six months later would leave nothing.

  • Bezos’ investment team reportedly rejected the price as economically unreasonable, but Bezos said he wanted to back the pair anyway. Annual conversations brought encouragement rather than operating demands: he told them they understood their business and should keep making the work he admired.

  • DHH regrets taking some of that support for granted while publicly criticizing Amazon. His enduring lesson is Bezos’ extraordinary conviction: Amazon looked irrational and was hated around the dot-com crash, yet Bezos pursued a horizon so long that DHH calls his own long-term thinking “a child’s game.”

28. Partnership survives when trust is deep and contact is scarce

  • DHH and Jason did try to “murder each other” rhetorically in the early years; arguments became loud enough that employees feared the company was disintegrating. The disputes stayed about ideas, however, and the emotional intensity represented a search for a better answer rather than personal contempt.

  • Distinct competence made trust possible. Jason has final authority in design and product direction, DHH in technology, while business, writing, and marketing overlap; two founders with the same specialty might spend their lives contesting which one is superior.

  • When shared domains produced deadlock, Bezos’ “disagree and commit” supplied the rule. One partner can believe a choice is wrong, explicitly register that disagreement, then support the decision rather than sabotaging it.

  • Geographic separation helped them avoid wearing out the relationship. Across Chicago, Malibu, Spain, and Copenhagen, DHH estimates they often spend fewer than two hours a week in direct exchange: “There’s way too much bouncing going on and not enough scoring.”

29. A whole life made a 25-year company possible

  • Lex admits that remote work can make him seek meetings because he is lonely. DHH’s sincere, teasing prescription is “Get a wife. Get a couple kids”: humans need relationships, but work need not supply 40 hours of intimacy every week.

  • DHH and Jason agreed that roughly 40 hours was enough if they wanted a company lasting 20 years rather than a five-to-seven-year sprint toward an exit. Family, friends, health, and hobbies are not rewards deferred until success; they are the other legs that make a long working life stable.

  • “Mojito Island is a mirage.” Creative, ambitious people do not enjoy permanent retirement; Mihaly Csikszentmihalyi’s Flow taught DHH that happiness comes while stretching capacity just beyond its current limit, not while eliminating every problem and obligation.

30. Breadth can outperform singular greatness as a life strategy

  • DHH accepts that being the world’s best usually demands obsession: Ayrton Senna, Michael Jordan, and Max Verstappen do not distribute their attention evenly. He simply never needed that bargain and regarded his early programming failures as evidence that he would not become the best programmer alive.

  • His preferred learning bargain is the top 5% in several fields rather than the top 0.1% in one. He can write, program, race, run a company, and raise a family; reaching strong competence in five domains is vastly easier than reaching singular mastery in one.

  • Founders rarely reproduce their first breakthrough. Basecamp was DHH’s “first baby,” while later products achieved varying success without recreating its lightning; experience also removes the ignorance that made the original adventure tolerable, which is why he would tell his younger self nothing and refuse to spoil the movie.

  • “Inspiration is perishable,” his favorite Rework essay, captures how plans can kill momentum. DHH and Jason’s prospective new book explores trusting a career’s accumulated gut: creative work often discovers its argument through writing or coding, and independent ownership permits “because I feel like it” when analysis cannot express the evidence.

31. 37signals’ cloud exit converted skepticism into recurring profit

  • HEY initially ran entirely on AWS—compute, caching, storage, and databases—while 37signals used the platform for its services. AWS spending peaked around $3.2 million–$3.4 million, a figure DHH could not reconcile with continually faster commodity computers.

  • He had believed the cloud’s three-part pitch: easier, cheaper, and faster through hyperscaler economies of scale. AWS remained exceptional at instantly provisioning capacity, but DHH found it neither easier nor cheaper for stable workloads and notes that AWS itself operates at margins approaching 40%.

  • Beginning in early 2023, the team moved seven major applications’ compute, caching, and databases onto purchased Dell servers in just over six months, without hiring another operator. Infrastructure costs fell roughly one-half to two-thirds, saving close to $2 million annually.

  • The projected five-year benefit is around $10 million, subject to accounting assumptions. DHH accepts the opportunity-cost argument—engineers could have built features instead—but says those savings flow directly to owners and employee profit sharing, making efficiency economically and aesthetically worthwhile.

32. Owning hardware restores both autonomy and technical intuition

  • Storage took longer because reasonable S3 pricing required a four-year commitment for petabytes of customer files. This undercuts the image of cloud usage as pure day-to-day flexibility: serious discounts often bind customers through long commitments.

  • Purchased machines sit in a professionally managed data center, not under employees’ desks. A white-glove operator replaces failed SSDs and racks boxes; 37signals sees IP addresses and drives come online much as cloud customers do, but owns the equipment it will use for years.

  • DHH also values the internet’s original distributed topology. When AWS us-east-1 fails and a large share of the web disappears, the result insults the resilient network DARPA intended; he can praise AWS’s advances in virtualization and automation while rejecting hyperscalers as the final architecture.

  • His next experiment is literal home hosting. A 5-gigabit fiber connection and modern small servers could have carried Basecamp far into its growth; home labs revive the garage startup physically, while NVMe and SSDs show how old assumptions persist after hardware progress quietly invalidates them.

33. Technically grounded leaders can identify talent and demand simplicity

  • DHH thinks Elon Musk attracts talent more than he finds it. Lex described missions such as reaching Mars, electrifying transportation, and covering Earth with internet as a beacon for people seeking an audacious adventure; DHH agreed that such audacity inspires people.

  • DHH’s additional point is that Musk knows enough to evaluate work directly. A leader who understands the underlying technical work can distinguish who is “full of shit,” give capable people ownership, and tell a team that a design can be simpler with more substance than “do it faster.”

  • Steve Jobs represented a similar combination of taste, grounded possibility, and personal offense at mediocre results. The standard can make engineers feel small in the moment, but DHH believes the resulting demand occasionally unlocks a solution the team initially declared impossible.

  • Lex described Musk handing leadership to people without conventional résumés; DHH emphasized the smaller-scale version used at 37signals. Résumés and pedigree do not decide: a tailored cover letter proves the writing needed for remote work, while a realistic programming exercise reveals whether DHH wants to maintain that candidate’s code five years later.

34. Apple’s toll booth corrupted a relationship built over 20 years

  • DHH became an Apple evangelist after Macs adopted Unix underpinnings in the early 2000s, offering escape from the Microsoft that had “cut off the air supply” to Netscape. He converted classmates, appeared in an Apple developer advertisement, and expected to remain a Mac user indefinitely.

  • He queued roughly five hours for the first iPhone in 2007 and joined the ceremony of employees applauding buyers. Only later did he grasp that the device was not merely a phone but the primary computer through which software businesses would have to reach most customers.

  • The App Store converted that access into permission and a 30% toll. DHH’s objection covers both money and control: Apple owns the customer’s billing relationship, complicating refunds, discounts, support, and movement between iOS, Android, and the web.

  • HEY took two years and millions of dollars to build because DHH wanted to rethink email with control of both server and client. He expected Gmail—responsible, he estimates, for around 70% of US email—to be the impossible opponent; Apple instead became the immediate existential threat.

35. HEY survived Apple by making rejection more costly than approval

  • Apple approved HEY’s initial iOS app before its 2020 launch, then rejected the first bug-fix update and threatened removal because it lacked in-app purchasing. Basecamp had operated for years as a companion app for customers who subscribed on the web, making the reversal feel invented and discriminatory.

  • DHH refused: he would not give Apple 30% or surrender the direct relationship. With WWDC only a week away and 37signals possessing a public platform, he “turned it up to 11,” making Apple’s developer-love messaging compete with a vivid story about destroying an independent developer.

  • The initial fight lasted days, then became a prolonged two-year battle that ended in an inelegant truce. HEY kept external billing and remained in the store, while building a dummy-account experience so the downloaded app performed something before an existing customer signed in—a rule DHH says Phil Schiller appeared to formulate under media pressure.

  • His anger was genuine enough to say he would burn down the business before yielding. He calls that rage a volatile compound because employees and customers also bore the risk, yet believes incumbents do not compromise unless founders can credibly refuse an economically attractive submission.

36. Epic’s narrow legal win rewired mobile payment economics

  • DHH credits Tim Sweeney, Mark Rein, and Epic with inflicting the only serious wound on Apple’s App Store regime. Epic reportedly spent well over $100 million on legal fees, validating lawyers’ earlier warning that a 37signals suit would cost at least $10 million and consume five to seven years.

  • Apple initially won roughly 10 of 11 counts; Epic’s narrow victory said developers could link users to outside payment. DHH argues Apple could have accepted that result but instead obstructed it enough to anger the judge and trigger a criminal-contempt referral, converting a small loss into a much broader remedy.

  • HEY planned to use the resulting rule immediately: an iOS user could begin signup, follow a link to the web to enter a card, return to the app, and retain one direct subscription across Android and desktop without paying Apple 30%.

  • Only a founder-controlled company could have provoked and sustained the battle, DHH believes. A conventional board would not authorize more than $100 million to risk a profitable franchise over principle; Sweeney’s willingness to “sink this whole fucking company” created value for developers who never funded the case.

37. Apple remains exceptional, but its accumulated bill is arriving

  • Lex pushes back that the 30% dispute is one slice of a company still unmatched in hardware and design. DHH agrees, calling disappointment proportional to admiration: Apple’s acquisition of PA Semi and persistence with Arm produced the M-series chips and accelerated hardware progress.

  • His criticism is that toll-booth economics damaged developer trust. He links the Vision Pro’s weak ecosystem partly to developers no longer volunteering their best work for Apple, demonstrating that a platform can hold all the cards temporarily while degrading the relationships needed for its next category.

  • DHH once thought Tim Cook’s extraordinary operational performance proved a logistics leader could preserve Jobs’ system indefinitely. He now believes the invoice was merely delayed: software quality is faltering, Apple trails in AI, and competitors using TSMC can approach its manufacturing advantages.

  • He also flags succession risk: Apple’s board averages roughly 75 years old and its executives are over 60, by his account. At 45, DHH already must force himself to become an AI beginner; he doubts a leadership cohort much older will embrace a paradigm shift without the founder’s unreasonable curiosity.

38. Fatherhood expanded DHH’s perceived scale of a good life

  • DHH was unsure he wanted children until meeting Jamie, who clearly wanted marriage and three kids. Her certainty turned a fuzzy “someday” into a decision; looking backward, he sees the childless branch of his life as a source of potentially existential regret.

  • Parenthood delivered a truth that words had failed to transmit despite every parent openly repeating it. Watching a child understand or accomplish something revealed that his satisfaction scale did not run from 1 to 10 but “from 1 to 100,” and he had mistaken the lower range for the whole field.

  • He had never felt much toward other people’s babies and therefore lacked an emotional analogy. Love for his own children arrived before they could return language; not necessarily instantly, but once it came, “it hit like the kick of a horse.”

  • DHH would trade software, companies, racing, and every other achievement for his three boys “in a heartbeat.” Because the claim sounds clichéd, he thinks parents have an obligation to repeat that it is literal, especially amid far more articulate public cases against marriage and children.

39. Removing family institutions created second-order effects society did not price

  • DHH and Lex see a broken Western pairing system behind falling family formation. Technology appears to have improved hiring more than friendship and romantic matchmaking; dating tools expanded theoretical choice while making durable coupling harder.

  • DHH says the cost of having the wrong partner can be high, while also noting that a divorced friend still loves his children and makes the situation work. He does not claim that divorce should be avoided in every case, but says he personally does not know whether that kind of divorce would destroy him.

  • He uses marriage, religion, and inherited norms as Chesterton’s fences. Easier divorce or declining religious belief may remove some old constraints, but civilization also encoded load-bearing coordination in institutions, and society often removed the software before constructing a replacement.

  • Though not religious, DHH “sort of” wishes he were because he now appreciates religion as an operating system for individuals and societies. Like legacy COBOL that nobody fully understands yet cannot safely replace, some rules are obsolete artifacts while others keep the system running—and modern substitutes have often been worse.

40. Children time-box work instead of eliminating productivity

  • DHH’s family structure matters: Jamie left her corporate work and carries much of the daily childcare, a choice he resists describing merely as uncompensated labor. Raising children can be valuable work in itself rather than a failure of ambition, though he presents their arrangement as personal rather than universally prescriptive.

  • His day begins around 6:30, includes one or two Fortnite rounds, school drop-off before 8, and work from roughly 8:30 or 9 until 5:30 or 6. Dinner and reading then close the workday; unfinished tasks wait for tomorrow instead of leaking through the night.

  • That boundary has not reduced his roughly 40-hour volume but makes it more honest. People boasting of 80 or 100 hours usually count meetings, distraction, and low-value motion; three or four uninterrupted hours can move a meaningful problem much farther.

  • Family also creates shared play rather than pure obligation. DHH has logged roughly 1,000 Fortnite hours since 2019, nearly all with his children, and now watches his oldest improve at karting—experiences that make sending a few more emails seem unworthy of ending a 30,000-year lineage.

41. Racing became DHH’s reliable machine for entering flow

  • Growing up in Copenhagen, where car taxes effectively made buyers pay for three vehicles to receive one, DHH did not obtain a license until 25. Racing games supplied the earlier fascination; moving to the United States made actual driving necessary.

  • Two years later, a friend brought him to Autobahn Country Club near Chicago and placed him in an old single-seat Mazda race car. Roughly 20 laps produced the same near-religious recognition he had felt with Ruby: the visible wheels, stiff slick tires, bumps, and exposure made speed physically immediate.

  • The intoxication comes at “the edge of adhesion,” where a couple degrees of tire slip rotates the car fastest. One tiny extra input begins a spin and possibly sends it into a wall; DHH compares the stake to gambling, where the possibility of losing something real changes the psychological game.

  • Programming flow depends on finding exactly the right problem. A race car creates it almost on demand because survival at speed consumes 100% of his attention: there is no dinner, meeting, or launch, only “you and the next corner.”

42. Le Mans mastery combines repetition, data, nerve, and accepted danger

  • DHH began serious competition in 2009 and reached the 24 Hours of Le Mans in 2012, inspired by fellow Dane Tom Kristensen’s record nine victories. Three drivers share the race; regulations cap one driver at four hours within six, while DHH’s longest individual stint has been roughly two and a half hours.

  • An LMP2 car moves among perhaps 60 vehicles, overtaking slower GT cars while hypercars overtake it. DHH tries to “become a robot,” loading a program for every corner—braking point, pressure curve, steering, throttle—then comparing telemetry with professional co-drivers down to 100-millisecond losses.

  • Tires may meaningfully decline after about 40 minutes, weather changes grip, and a roughly 2-meter-wide, 5-meter-long car must pass rivals within inches despite poor mirrors. Professionals combine a mental spatial model with reactions around 200 milliseconds; even 10 or 20 milliseconds can decide a start or save a slide.

  • The danger remains load-bearing. DHH describes teammates’ severe injuries and a fellow Danish driver’s fatal 90-g impact the year before DHH’s class win; he does not consciously contemplate death while driving, because doing so would prevent speed, yet the impossibility of pressing reset is part of the appeal.

43. His personal stack makes every interaction immediate and tactile

  • For roughly 20 years, DHH’s answer was a Mac, Apple Magic Keyboard, one large display, and virtual desktops. He still uses Apple’s 32-inch 6K XDR display after leaving macOS because he has not found a better screen.

  • His current machine runs Ubuntu with Omakub, a reproducible setup that can configure a fresh Linux computer in under 30 minutes. Linux is closer to his servers, permits more individual expression, and can switch virtual desktops in roughly a screen refresh instead of forcing macOS’s animation.

  • Hardware matters because programmers touch it all day. The Lofree Flow 84 mechanical keyboard produced an “angels are singing” reaction after years with Apple’s low-travel board; he pairs it with a Logitech MX Master 3S, whose feel he likes more than its appearance.

  • TextMate, created by his longtime friend Allan Odgaard with DHH’s early encouragement, delayed his departure from Mac. Neovim finally displaced it after three days of cursing and one week of conversion, with LazyVim supplying a polished distribution so adopting Vim need not require 17 configuration tutorials.

44. DHH recommends languages by domain and identifies as a software writer

  • For a web-focused beginner, DHH chooses Ruby first, then JavaScript, then Go. Ruby removes ceremony from foundational concepts; JavaScript is unavoidable on “the greatest application platform of all time”; Go is excellent for low-level web infrastructure such as HTTP proxies.

  • He advises moving to Rails immediately if the learner wants web applications, because real desire drives study better than an abstract language specification. Ruby is wrong for a 3D engine or Unreal’s Nanite, just as Go’s speed and primitives do not make it DHH’s choice for business-domain logic.

  • Lex notes that he has never built anything real in a fully functional language and calls that somewhat embarrassing; DHH agrees that his own problem is finding a project he wants to build. Objects remain how DHH carves a business domain, while functional techniques are tools he borrows when they solve a local problem more cleanly.

  • “Software engineer” misdescribes his work. DHH calls himself a software writer: in Ruby, solving and expressing the problem happen together, much as a blog post discovers its argument during composition; he and Lex suggest that AI may make this human-readable, literary layer more important rather than eliminating it.

45. Sustainable open source begins with self-interest, not customer obligation

  • Rails taught DHH that treating users as paying customers is a fast route to burnout. Early demands included Oracle support accompanied by threats that Rails would otherwise remain a toy; his notorious conference slide answered, “Fuck you”—the project was a gift, not a vendor contract.

  • Users may take, fork, and improve the code under its license, while maintainers may choose their own priorities. DHH invokes Adam Smith: he builds features he needs because self-interest produces better, narrower software than obligations to hypothetical users whose problems he cannot personally evaluate.

  • Open source is therefore not in crisis merely because maintainers lack universal funding. Most open-source work already comes from commercial companies contributing infrastructure they need; anyone requiring payment can sell software or take employment that funds open-source development.

  • He favors the MIT license over the GPL: in his paraphrase, it says the software has no warranty, users cannot sue, and they may “do whatever the hell” they want. Money and donation models can coexist, but retroactive expectations contaminate the clarity that allowed commercial and open software to stop fighting.

46. WordPress, wealth, and optimism all reduce to honoring the original bargain

  • DHH praises WordPress as one of the internet’s greatest open-source projects and Matt Mullenweg for enabling broad website creation. Yet he condemns Mullenweg’s fight with WP Engine and Silver Lake: releasing code under a license does not permit a later ransom because a recipient became successful or contributed less than hoped.

  • Personal betrayal might explain anger but cannot override the license. DHH urges Mullenweg to admit a bad bet and lay down the sword; a “mad king” threatens not only WordPress trust but every business evaluating whether an open-source foundation might later demand a share of its revenue.

  • Rails has reportedly powered more than 1 million applications, yet DHH does not regret failing to charge each beneficiary. Basecamp gave him enough, and maximizing every available dollar would trade away flow and “nirvana” as an empty calendar; people at every wealth level imagining they need exactly double reveal the endpoint’s perpetual retreat.

  • His civilizational conclusion applies the same humility. Nuclear weapons may have deterred direct great-power war; climate interventions may help or misfire; pandemic experts proved how little credentials can guarantee foresight. Since he cannot know the outcome, DHH chooses optimism: humans repeatedly build their way through problems, and “we suffer more in our imagination than we do in reality.”