Lex Fridman Podcast · 2025-07-12 · 369 min

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

Lex FridmanDavid Heinemeier Hansson

YouTube ↗

TL;DR

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.

Digest · the substance, structured for research

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.”

David Heinemeier Hansson

No one anywhere who's serious believes that cookie banners do anything good for anyone. Yet we've been unable to get rid of them. This is the thing that really gets me about cookie banners, too. It's not just the EU; it's the entire world.

You can't hide from cookie banners anywhere on this planet. If you go to goddamn Mars on one of Elon's rockets and try to access a web page, you'll still see a cookie banner. No one in the universe is safe from this nonsense.

It sometimes feels like we're barely better off. Web pages aren't that different from what they were in the late '90s and early 2000s. They're still just forms. They still just write to databases.

A lot of people, I think, are very uncomfortable with the fact that they are essentially CRUD monkeys. They just make systems that create, read, update, or delete rows in a database. They have to compensate for that existential dread by overcomplicating things.

That's a huge part of the satisfaction of driving a race car: driving it at the edge of adhesion, as we call it, where you're essentially just a tiny movement away from spinning out. It doesn't take much. Then the car starts rotating. Once it starts rotating, you lose grip and you're going for the wall.

That balance of danger and skill is what's so intoxicating.

The following is a conversation with David Heinemeier Hansson, also known as DHH. He is a legend in the programming and tech world. Brilliant and insightful, sometimes controversial and always fun to talk to. He's the creator of Ruby on Rails, which is an influential web development framework behind many websites used by millions of people, including Shopify, GitHub, and Airbnb. He is the co-owner and CTO of 37signals, which created Basecamp, and is a New York Times best-selling author together with his co-author Jason Fried of four books: Rework, Remote, Getting Real, and It Doesn't Have to Be Crazy at Work. And on top of that, he's also a race car driver, including being a class winner at the legendary 24-hour lemon race. This is the Lex Fridman Podcast. To support it, please check out our sponsors in the description and consider subscribing to this channel. And now, dear friends, here's DHH.

Lex Fridman

For someone who became a legendary programmer, you officially got into programming late in life. I guess that's because you tried to learn how to program a few times and failed. Can you tell me the full story, the saga of your failures to learn programming? Was the Commodore 64 involved?

David Heinemeier Hansson

The Commodore 64 was the inspiration. I really wanted a Commodore 64. That was the first computer I ever sat down in front of.

The way I sat down in front of it was, I was 5 years old, and there was this one kid on my street who had a Commodore 64. No one else had a computer, so all the kids were just getting over there and playing Yie Ar Kung-Fu. I don't know if you've ever seen that game. It was one of the original fighting games. It's really a great game.

I was playing that for the first time at 5 years old. There were about 7 kids sitting up in this one kid's bedroom, all taking turns to play the game, and I just found that unbelievably interesting.

I begged and begged and begged my dad, "Could I get a computer?" He finally comes home and says, "I got your computer." I was like, "Yes, my own Commodore 64." He pulls out this black, green, and blue keyboard.

"That's an Amstrad 464." I was like, "Dad, what's this? This is not a Commodore 64."

Lex Fridman

The disappointment.

David Heinemeier Hansson

But it was a computer, so I got my first computer at essentially 6 years old: that Amstrad 464.

Of course, the first thing I wanted to do was play video games. I think the computer—which he, by the way, had traded for a TV and a stereo recorder or something like that—came with about 2 games. One was this Frogger game where you had to escape from underground. It was actually kind of dark, with this frog that you're trying to get out from underground.

I was pretty bad at it, and I only had those 2 games. Then I wanted more games. One way to get more games when you're a kid who doesn't have a lot of money and can't just buy a bunch of games is to type them in yourself.

Back in 1984 and 1985, magazines would literally print source code in the back of their magazines, and you could just sit and type it in. I tried to do that, and it would take about 2 hours to type this game into the Amstrad. Of course, I'd make some spelling mistake along the way, and something wouldn't work.

The whole thing was difficult because I wasn't that good at English. I was born in Denmark. I was really trying to get into it because I wanted all these games and didn't have the money to buy them. I tried quite hard for quite a while to get into it, but it just never clicked.

Then I discovered the magic of piracy. After that, I basically just took some time off from learning to program because suddenly I had access to all sorts of games. That was the first attempt, at around 6 or 7 years old.

What's funny is that I remember these fragments. I remember not understanding the purpose of a variable. If there's a thing and you assign something to it, why would you assign another thing to it? For some reason, I understood constants. Constants made sense to me, but variables didn't.

Then maybe I'm 11 or 12. I've gotten into the Amiga at this point. The Amiga, by the way, is still perhaps my favorite computer of all time.

To me, even as someone who loves computers and loved new computers, the Amiga was this magical machine that was made by the same company that produced the Commodore 64. I got the Amiga 500, I think, in 1987.

Lex Fridman

Look at this sexy thing. That is a sexy machine right there.

David Heinemeier Hansson

This is from an age, by the way, where computing wasn't global in the same sense. Different territories had different computers that were popular. The Amiga was really popular in Europe, but it wasn't very popular at all in the US, as far as I understand. It wasn't popular in Japan. There were just different machines.

The Apple II was a big thing in the US. I'd never even heard of Apple in the '80s in Copenhagen. But the Amiga 500 was the machine that brought me to want to try programming again.

You know what's funny? The reason I wanted to try it again was that I remembered the first time I tried to learn. Then there was this programming language that was literally called Easy AMOS. Like, the easy version of AMOS. I'm like, "If it's Easy AMOS, how hard can it be? I've got to be able to figure this out."

This time I tried harder. I got into conditionals. I got into loops. I got into all these things, and I still couldn't do it.

On the second attempt, I really got to the point of thinking, "Maybe I'm just not smart enough. Maybe programming is too much math." I like math in this superficial way. I don't like it in the deep way that some of my perhaps slightly nerdier friends did, who I had tremendous respect for.

I'm not that person. I'm not the math geek who's going to figure it all out. After that attempt with Easy AMOS, and failing to complete even one very basic game, I thought, "Programming is just not for me. I'm going to have to do something else."

I still loved computers. I still loved video games. At that time, I had already begun making friends with people who knew how to program. They weren't even programming in Easy AMOS; they were programming freaking assembler.

I would sit down and think, "How do you do the moves and the memory copies? How do you even do this?" I didn't understand how you went from this to Amiga demos, for example.

That was the big thing with the Amiga. It had this wonderful demo scene in Europe. It was a really interesting period of time in the Amiga's history, where you had all these programmers spread out mostly all over Europe who would compete in graphics competitions.

Lex Fridman

You could probably bring one of these up on YouTube on this thing.

David Heinemeier Hansson

They would make these little, almost like music videos, combining some MOD music and some cool graphics, and they would do all of it in about 4 KB.

Lex Fridman

4 kilobytes. That is not 4K. It's a revolution.

David Heinemeier Hansson

Four kilobytes of memory. I just thought that was such a cool scene. This was obviously pre-internet. It was even pre-bulletin board systems, to some extent.

I was enamored with that whole scene. I was enamored with what they were able to create, and I just wanted to be a part of it, even though I didn't have any skills to contribute. That's how I got into running BBSs.

I didn't learn programming then, and I wouldn't learn programming until much later, until I was almost 20 years old.

The bulletin board systems existed in this funny space where they were partly a service to the demo scene, allowing all these demo groups to distribute their amazing demos. It was also a place to trade pirated software.

I ended up starting one of those when I was 14 years old, in my tiny little bedroom in Copenhagen. I had, at that point, an Amiga 4000. I had 3 telephone lines coming into my tiny room.

Lex Fridman

Nice.

David Heinemeier Hansson

It was funny because, again, I'm 14 years old. By the time I was installing my third line, you had to get someone from the telephone company to come do it. I get this guy, and he's just looking around like, "What is this? Why the hell does a 14-year-old have 3 phone lines coming into their tiny little bedroom? What's going on here? Why are all these modems blinking red and making funny sounds?"

Lex Fridman

Did your parents know?

David Heinemeier Hansson

They did and they didn't. They knew I had the phone lines. They knew I had the computer. I don't think they really understood that I was trading pirated software, which was both illegal, and whatever else was going on.

Lex Fridman

Oh, we should probably say that in Europe—maybe you can comment on this, especially in Eastern Europe—but Europe in general, piracy, I think, was more acceptable than it was in the United States. I don't know; maybe it's just my upbringing.

David Heinemeier Hansson

That conversation wasn't present. I never spoke to anyone growing up in Denmark who had any moral qualms whatsoever about piracy. It was just completely accepted: you're a kid, you want a lot of games, you don't have a lot of money. What do you do? You trade.

Some people would occasionally buy a game. I once bought a Sega Master System, and I bought one game because that was what I could afford. I got After Burner II. I don't know if you've ever played that game. It's a pretty bad implementation on the Sega Master System, but it was about 600 kroner, and I was making money at that time doing newspaper delivery.

I had to do that for a month to afford one game. I like video games way too much to wait a month just to get one game. So piracy was just the way you did it. That was how I got into running this bulletin board system, being part of the demo scene, and being part of the piracy scene to some extent.

Then, at some point, I realized, "Oh, you can actually also make money on this, and this can fund buying more phone lines, buying more modems, and buying more Amigas." Oh, yeah, that was one of the demo parties. These were amazing things.

Lex Fridman

What am I looking at?

David Heinemeier Hansson

Look at all those CRT monitors.

Lex Fridman

All these CRT monitors.

David Heinemeier Hansson

Again, when I was 14, I don't fully understand why my parents allowed this, but I traveled from Copenhagen, the capital of Denmark, to Aars, this tiny little town in Jutland, on the train with a bunch of dudes who were in their late teens or in their 20s. I'm 14 years old. I'm lugging my 14-inch CRT monitor, with my computer on my back, to go to The Party. That was what it was called. That was the biggest demo scene party at that time.

It was exactly as you see in that picture. Thousands of people just lining up with their computers, programming demos all day long, and trading these things back and forth.

Lex Fridman

That's kind of awesome. Not going to lie, it's a little ridiculous.

David Heinemeier Hansson

It's totally awesome. I miss it in ways where the internet has connected people in some ways, but the connection you get from sitting right next to someone else who has their own CRT monitor, who's lugged it halfway around the country to get there, is truly special.

It was also just this burst of creativity. You're constantly running around. You're constantly surrounded by people who are really good at what they do. They're really good at programming computers. It's infectious.

It was part of that pang I felt then, going, "Oh, man, why can't I figure this out? I mean, why can't I even figure out Easy AMOS?" It's kind of frustrating.

Lex Fridman

But on your third attempt, you were more successful.

David Heinemeier Hansson

The third attempt is when I start getting it. This is when I start helping out building things for the internet. So, around '95, I think, is when I discovered the internet. Actually, ninth grade—that was my first experience.

I went to some university in Denmark, and in ninth grade we had this excursion. They sat us down in front of a computer, and the computer had Netscape Navigator, the first version, or maybe it was even the precursor to that. They had a text editor, and these guys and I just got, "Hey, build something on the internet."

It was just HTML, and the first thing you do is, "Oh, I can make the text blink by just putting in this tag and saving it." That was that moment. That was actually when I reawakened the urge to want to learn to program because I got a positive experience.

All the other experiences I had with programming were that I'd spend hours typing something in, I'd click Run, and it wouldn't work. I'd get an error message that made no sense to me as a kid, either at 6 or 7 or at 12. And here I am, sitting in front of a computer connected to the internet, and I'm making text blink. I'm making it larger. I'm turning it into an H1 or an H2.

These guys and I just did it for about an hour and a half, and suddenly I go, "Oh, I can make things for the internet that someone in Germany can access and see, and I don't have to ask anyone for permission. This is super cool. I gotta do more of this."

So I got into the internet. I got into working with HTML, and I still had all these friends from these demo parties. I started working with them on creating gaming websites. I'd write about the video games. I'd review them.

This was another good way of getting new video games: to walk down to some store and say, "Hey, I'm a journalist. I'm this 15-year-old kid," and they're looking at me, "You're a journalist?" "Yeah. Can I borrow some games?"

This was when games moved on to the PlayStation and these other things. You couldn't just as easily pirate them, at least not at first. So I went down there and did all that.

That started the journey of the internet for me. It started with working on these gaming websites, working with programmers, and figuring out that I could do something. I could work on the HTML part. It's not really programming, but it kind of smells like it.

You're talking to a computer, you're making it put text on the screen, and you're communicating with someone halfway around the world. So that became my pathway back into programming. Then slowly I picked up more and more of it.

The first website I did with someone—one of these programmers from the demo scene—that was dynamic was ASP. It wasn't even actually called .NET. That was what we started on, and then we moved on to PHP. PHP was when I finally got it, when it finally clicked—when conditionals and loops and variables and all of that stuff started to make enough sense to me that I thought, "I can do this."

Lex Fridman

So would it be fair to say that we wouldn't have DHH without PHP, and therefore you owe all your success to PHP?

David Heinemeier Hansson

100%, that's true, and it's even better than that because PHP, to me, didn't just give me a start in terms of making my own web applications; it actually gave me a bar in many ways. I think the pinnacle of web-developer ergonomics is late-'90s PHP.

You write this script, you FTP it to a server, and instantly it's deployed; instantly it's available. You change anything in that file and you reload—boom, it's right there. There are no web servers, there's no setup, there's just an Apache that runs mod_php.

It was essentially the easiest way to get a dynamic web page up and going. This is one of the things I've been chasing—that high—for basically the rest of my career: that it was so easy to make things for the internet in the mid-to-late '90s.

How did we lose the sensibilities that allowed us to not just work this way, but get new people into the industry and give them the success experiences that I had—adding a freaking blink tag to an HTML page, FTPing a PHP page to an Apache web server without knowing really anything about anything, without knowing anything about frameworks, without knowing anything about setup?

All of that stuff has really taken us to a place where it sometimes feels like we're barely better off. Web pages aren't that different from what they were in the late '90s and early 2000s. They're still just forms. They still just write to databases.

Now, that's a bit of a caricature. There's more to it, and there are things you can learn from more sophisticated ways of thinking about this, but there's still an ideal here. That's why I was so happy you had Pieter Levels on, because he still basically works like this. I look at that and go, "Man, that's amazing."

Lex Fridman

Yeah, you're chasing that high. He's been high all along, using PHP, jQuery, and SQLite.

David Heinemeier Hansson

I think it's amazing because he's proving that this isn't just a nostalgic dream. He's actually doing it. He's running all these businesses. Now, some of that is, as he would admit up front, because he's just one guy. You can do different things when you're just one guy.

When you're working in a team—when I started working with Jason Fried on Basecamp—we at first didn't use version control together. I used version control for myself, and then I thought, "You know what? Designers, they're probably not smart enough to figure out CVS."

Lex Fridman

Yeah.

David Heinemeier Hansson

Therefore I was just like, "No, no, no. You just FTP it up. You just FTP it." I knew they knew how to do FTP. Then, after the third time I'd overridden their changes, I was like, "God damn it. I guess I got to teach Jason CVS so this doesn't happen again."

But I think there's still way more truth to the fact that we can work the way we did in the '90s, work the way Pieter works today, even in the team context, and that we've been far too willing to hand over far too much of our developer ergonomics to the merchants of complexity.

Lex Fridman

And you've been chasing that with Rails 8. So how do you bring all the cool features of a modern framework and make it no-build, make it as easy to create something and ship it as it was in the '90s with just PHP?

David Heinemeier Hansson

It's very difficult for me to beat the Pieter Levels' approach of just—it's so easy to just ship some PHP. Why should it be harder than that? Our computers today are almost infinitely faster than what they were in the '90s.

Shouldn't we be able to work in even easier ways? We should be looking back on the '90s and go, "Oh, that was way too complicated. Now we have more sophisticated technology that's way faster, and it allows us to work in these easier-to-use ways." But that's not true.

But now you can see the line I draw in my work with Ruby and Rails, and especially with Rails 8. No build, to me, is reaching back to that ’90s feeling and going, “Now we can do some of those things without giving up on all the progress,” because I do think you can get too nostalgic. I do think you can start just fantasizing that everything was better in the ’90s. It wasn’t.

I mean, I was there. There were a lot of things that sucked. If we can somehow find a way to combine the advantages and advances we’ve had over the past 20 years with that ease of developer ergonomics, we can win. No build is a rejection of the part of web development I’ve hated the most in the past 10–15 years, which is the JavaScript scene.

Lex Fridman

Yeah.

David Heinemeier Hansson

And I don’t say that as someone who hates JavaScript. I often joke that JavaScript is my second favorite programming language. It’s a very distant second. Ruby is by far and away number one. But I actually like JavaScript. I don’t think it’s a bad language.

It gets a lot of flak. People add a string of 2 plus a 1, and it gives something nonsensical, and I just go, “Yeah, but why would you do that? Just don’t do that.” The language is actually quite lovely, especially the modern version, ES6, which really introduced a proper class syntax to it. So I could work with JavaScript in many of the same ways that I love working with Ruby, and that made things so much better.

David Heinemeier Hansson

But in the early 2010s until quite recently, all of that advancement in preprocessing happened in build pipelines. The browsers couldn’t speak a dialect of JavaScript that was pleasant to work with, so everyone started precompiling their JavaScript to be able to use more modern ways of programming with a browser that was seen as stuck with an ancient version of JavaScript that no one actually wanted to work with.

That made sense to me, but it was also deeply unpleasant. I remember thinking during that time, the dark ages, as I refer to them with JavaScript, that this cannot be the final destination. There’s no way that we have managed to turn the internet into such an unpleasant place to work, where I would start working on a project in JavaScript using Webpack and all of these dependencies, and I would put it down for literally 5 minutes and the thing wouldn’t compile anymore.

The amount of churn that the JavaScript community, especially with its frameworks and its tooling, went through in the decade from 2010 to 2020 was absurd. You had to be trapped inside of that asylum not to realize what an utterly perverse situation we had landed ourselves in. Why does everything break all the time?

The joke wouldn’t be just that the software would break. That would annoy me personally. But then I’d go on Hacker News and I’d see some thread on the latest JavaScript release of some framework, and the thread would be like—someone would ask, “Well, aren’t we using the thing we just used three months ago?” And people would be like, “That thing is so outdated. That’s so three months ago. You’ve got to get with the new program. We’re completely rewriting everything for the 10th time, and anything you’ve learned in the framework you’ve been spending the vast amount of time on, it’s all useless. You’ve got to throw everything out and you’ve got to start over. Why aren’t you doing it, stupid idiot?”

Lex Fridman

Is that a kind of mass hysteria that took over the developer community, you think? Where you have to keep creating new frameworks and new frameworks? Are we past that dark age?

David Heinemeier Hansson

I think we’re getting out of it. And we’re getting out of it because browsers have gotten so much better. There was a stagnation in browser technology. Some of it was an overhang all the way back from IE5.

So IE5 essentially put the whole internet development experience into a deep freeze because Microsoft won the browser wars in the mid-2000s, and then they basically disbanded their browser development team because they were like, “All right, job done. We don’t need any more innovation on the internet. Can we just go back to writing Windows Forms or something now that we control everything?”

It really wasn’t until Firefox kindled a little bit of something, and then Chrome got into the scene and Google got serious about moving the web forward, that you had a rekindling of the idea that maybe the browser could be better. Maybe the browser wasn’t frozen in time in 2005. Maybe the browser could actually evolve like the development platform that it is.

But then what happened was you had a lot of smart people who poured into the web because the web turned out to be the greatest application development platform of all time. This was where all the money was being made. This was where all the billionaires were being minted. This was where the Facebooks and whatever of the world came to be.

So you had all of this brainpower applied to the problem of how to work with the web. There were some very smart people with some, I’m sure, very good ideas who did not have programmer happiness as their number one motivation. They had other priorities, and those priorities allowed them to discount and even rationalize the complexity they were injecting everywhere.

Some of that complexity came from organizational structure. When you have a company like Facebook, for example, that depends on the web and wants to push it forward but has sliced the development job into these tiny little niches—“I’m a front-end build-pipeline configurator.” “Oh yeah, well, I’m a front-end whatever engineer.”—suddenly the web developer was no longer one person. It was 15 different roles. That in itself injected a ton of complexity.

But I also want to make the bold case here: some of that complexity was necessary to get to where we are today. The complexity was a bridge. It wasn’t the destination, but we had to cross that bridge to get to where we are today, where browsers are frankly incredible.

The JavaScript you can write in a text file and then serve on a web server for a browser to ingest is amazing. It’s actually a really good experience. You don’t need any preprocessing. You can just write text files, send them to a browser, and you have an incredible development experience.

Lex Fridman

And we should also say that it can be kind of broken. At least the HTML, but even the JavaScript could be a little bit broken, and it kind of still works. Maybe it half-ass works, but the amount of mess, of smelly code that a browser has to deal with is insane. This is one of the hardest problems in computing today: to parse the entire internet, because thankfully for us as web developers, but perhaps not so much for the browser developers, every web page that has ever been created, minus the brief period with Flash, still runs today.

David Heinemeier Hansson

The web page I did in 9th grade would render on a modern browser today, 30 years later. That is completely crazy when you think about the amount of evolution we’ve had with the web, how much better we’ve made it, and how many more standards browsers have adopted.

It’s essentially an Apollo project today to create a new browser, which is why it doesn’t happen very often, and why even companies like Microsoft had to throw in the towel and say, “We can’t do it.” Now, I actually don’t think that’s good for the web. There is the danger of the monoculture if we just get a single browser engine that runs everything, and we are in danger of that.

I love the fact that the Ladybird project, for example, is trying to make a new browser engine from scratch. I’ve supported that project. I would encourage people to look into that. It’s really a wonderful—

Lex Fridman

Nice.

David Heinemeier Hansson

—thing. We really need that.

Lex Fridman

A truly independent web browser.

Rich Harris

We really need that. But I can hold that thought in my head. At the same time, I hold the thought in my head that Google’s Chrome was pivotal to the web surviving as the premier web development platform.

If it had not been for Google and their entire business depending on a thriving open web, Apple and Microsoft, I think, would have been just as fine to see the web go away, to disappear into being something that just served native web applications, or native mobile applications and native desktop applications that they could completely control.

So I have all sorts of problems with Google, but it’s not Chrome. Chrome is a complete gift to web developers everywhere, to the web as a development platform, and they deserve an enormous amount of credit, I think, for that—even if it’s entangled with their business model, and half of Chrome is code that spies on you or informs targeted ads and a bunch of things I’m not a big fan of.

I can divorce that from the fact that we need champions in the corner of the web who have trillions of dollars of market-cap value riding on the open web.

Lex Fridman

We’re going to take tangents upon a tangent upon a tangent. So let’s go to Chrome. I think Chrome’s positive impact on humanity is immeasurable for the reasons that you just described. On the technology front, the features they present and the competition they created have spurred on this wonderful flourishing of web technologies.

But anyway, I have to ask you about the recent stuff with the DOJ trying to split up Chrome and Google. Do you think this is a good idea? Do you think this does harm? Is it a disaster? And I say that as someone who’s been very sympathetic to the antitrust fight, because I do think we have antitrust problems in technology.

But the one place where we don’t have them, by and large, is with browsers, with the tools we use to access the open web. First of all, we have Firefox. Now, Firefox is not doing all that great, and Firefox has been propped up by Google for many years to deter exactly what’s going on with the DOJ, where they were the only game in town.

Apple has Safari. I have a bunch of problems with Apple, too, but I love Safari. I love the fact that we have a premier browser running on a premier operating system, so that people can’t turn the web into just a Chrome experience. But I also think that the open web needs this trillion-dollar champion, or at least benefits from it.

Rich Harris

Maybe it doesn't need it, but it certainly benefits from it. And of all the things that are wrong with monopoly formation in technology, Chrome is the last thing. This is why I get so frustrated sometimes about the anti-monopoly fight: there are real problems, and we should be focusing on the primary problems first, like the toll booths on our mobile phones. There are far bigger problems. It's not the open web, and it's not the tools that we use to access the open web.

If I don't want to use Chrome, or if my customers of my businesses that run on the internet don't want to use Chrome, they don't have to. We're never forced to go through it. The open internet is still open. So I think it's a real shame that the DOJ has chosen to pursue Google in this way. I do think there are other things you can nail Google for, like their ad monopoly, or the shenanigans they've done in controlling both sides of the ad ledger—that they control both the supply and the demand. There are problems. Chrome isn't it.

And you end up making the web much worse. This is the thing we always have to remember when we think about legislation and when we think about monopoly fights: you may not like how things look today, and you may want to do something about it, but you may also make it worse. The good intentions behind the GDPR in Europe have currently amounted to what? Cookie banners that everyone on the internet hates, that help no one do anything better or more efficiently, save no privacy in any way, shape, or form, and have been a complete boondoggle that has only enriched lawyers, accountants, and bureaucrats.

Lex Fridman

Yeah. You said that the cookie banner is a monument to why Europe is losing, to why it's doing the worst of all the regions in tech. It's a monument to good intentions leading straight to hell.

David Heinemeier Hansson

And Europe is actually world-class.

Lex Fridman

In good intentions leading straight to hell.

David Heinemeier Hansson

So hell is the cookie accept button. They have to accept all cookies. That's what hell looks like, over and over. You don't actually ever get to the web page.

Lex Fridman

Just on a human scale, try to imagine how many hours every day are wasted clicking that away and how much harm we've done to the web as a platform that people enjoy because of them. The internet is ugly in part because of cookie banners. Cookie banners were supposed to save us from advertisement, and advertisement can make the web ugly. There are plenty of examples of that. But cookie banners made the entire internet ugly in one fell swoop, and that's a complete tragedy. What's even worse, and this is why I call it out as a monument to everything the EU gets wrong, is that we have known this for a decade.

No one anywhere who's serious believes that cookie banners do anything good for anyone. Yet we've been unable to get rid of them. There's this one piece of legislation that's now, I think, 10 or 12 years old. It's a complete failure on every conceivable metric. Everyone hates it universally, yet we can't seem to do anything about it. That's a bankruptcy declaration for any body of bureaucrats who pretend to make things better—not just for citizens, but for people around the world. This is the thing that really gets me about cookie banners, too. It's not just the EU; it's the entire world.

David Heinemeier Hansson

Slower. You have basically a 150-second ping time, so it'll take you 45 seconds just to get through the cookie banners from Mars.

Lex Fridman

All right. Let's walk back up the stack of these recursive tangents we've been taking. So Chrome, we should say, at least in my opinion, is not winning unfairly. It's winning in the fair way, by just being better.

David Heinemeier Hansson

It is. If I was going to steelman the other side just for half a second, people would say, "Well, maybe." Most people do sort of begrudgingly agree that Chrome is a pretty good browser, but then they'll say the reason it got dominance was distribution. The reason it got distribution was because Google also controls Android and therefore can make Chrome the default browser on all these phones.

Now, I don't buy that. The reason I don't buy that is because on Android, you're actually allowed to ship a different browser that has a browser engine that's not the same as Chrome. Unlike on iOS, where if you want to ship a browser—Chrome, for example, ships for iOS—but it's not Chrome. It's Safari wrapped in a dress. Every single alternative browser on iOS has to use the Safari web engine. That's not competition. That's not what happened on Android.

Again, I think there are some nuances to it, but if you zoom out and look at all the problems we have with big tech, Chrome is not it. Chrome won on merits. I begrudgingly have switched to Chrome on that realization alone. As a web developer, I just prefer it. I like Firefox in many ways. I like the ethos of it, but Chrome is a better browser than Firefox. Full stop. And, by the way, we've never mentioned Edge. Edge is also a good browser.

Lex Fridman

Because it's also Chrome in a dress, but it never gets the love. I don't think I've ever used Bing, and I'm sure Bing is really nice.

David Heinemeier Hansson

Maybe you have, because do you know what Bing in a dress is?

Lex Fridman

What?

David Heinemeier Hansson

DuckDuckGo, which is actually the search engine that I use. DuckDuckGo gets its search results from Bing—or at least it used to. If they changed that, that would be news to me.

Lex Fridman

Well, maybe everything is just a wrapper or a dress. Everything is wearing a dress. Underneath, there are some other turtles. It's turtles all the way down. Okay, what were we talking about? We got there from JavaScript and from you learning how to program. So eventually, the big success story is when you built a bunch of stuff with PHP and you were actually shipping things.

David Heinemeier Hansson

Yes.

Lex Fridman

And that's when the Ruby story came in. That's when your big love affair with programming began. Can you take me there? What is Ruby? Tell the story of Ruby. Explain Ruby to me.

David Heinemeier Hansson

PHP was what converted me from just being able to fondle HTML and turn out some web pages to actually being able to produce web applications myself. I owe tremendous gratitude to PHP in that regard. But I never thought of PHP as a calling. I never thought, "I'm a professional programmer who writes PHP. That's who I am and that's what I do." I thought of PHP as a tool I needed to smack the computer with until it produced the web applications I wanted.

It was very much a means to an end. I didn't fall in love with PHP. I'm very grateful that it taught me the basics of programming, and I'm very grateful that it set the bar for the economics. But it really wasn't until Ruby that I started thinking of myself as a programmer. The way that came about was that the first time I ever got hired as a professional programmer to write code was actually by Jason Fried, my business partner still.

All the way back in 2001, I had been working on these gaming websites in PHP for essentially 18 months at that point. No one had been paying me to write code in that regard. I connected with Jason Fried over an email sent from Copenhagen, Denmark, to Chicago, Illinois, to a person who didn't know who I was. I was just offering unsolicited advice. Jason had asked a question on the internet, and I had sent him the answer. He was asking about PHP, and I had sent him the answer to that question. We started talking, and then we started working, which, by the way, is a miracle of what the internet can allow.

How can a kid in Copenhagen who's never met this guy in Chicago connect just over email and start working together? By the way, we're still working together now, 24 years later. That's incredible. We started working together on some client projects. Jason and 37signals would do the design, and I would bring the programming in PHP.

After we worked on, I think, two or three client projects together in PHP, we kept hitting the same problem: whenever you work with a client, you start that project off with an email. "Oh, yeah, let's work together. Here's what we're building." You start trading more and more emails, and before a few weeks have passed, you've got to add someone to the project. They don't have the emails. They don't have the context. You send, "Where's the latest file?" "Oh, I've uploaded it to the FTP." It's like, "final_final_v6_2.0," right? That's the one to get. It's just a mess—a beautiful mess, in some ways—a mess that still runs the vast majority of projects to this day.

Email is the lowest common denominator. That's wonderful. But we'd dropped the ball a couple of times in serious ways with customers, and we thought, "We can do better. We know how to make web applications. Can't we just make a system that's better than email for managing projects? It can't be that hard. We've been doing blogs. We've been doing to-do lists. Let's put some of these things together and just make a system where everything that anyone involved in the project needs is on one page."

It had to be simple enough that I wasn't going to run a seminar teaching people how to use the system. I was just going to give them the login code, and they were going to jump into it. So that's Basecamp.

And when we started working on Basecamp, I had, for the first time in my experience with Jason, the freedom of technology choice. There was no client telling me, "Yeah, PHP, that sounds good. We know PHP. Can you build it in PHP?" I had free rein.

At that time, I'd been reading IEEE magazine and a couple of other magazines from the early 2000s, where Dave Thomas and Martin Fowler had been writing about programming patterns and how to write better code. These two guys in particular were both using Ruby to explain their concepts, because Ruby looked like pseudocode.

Whether you were programming in C, Java, or PHP, all three constituencies could understand Ruby because it basically just reads like English. So these guys were using Ruby to describe the concepts. First of all, I would read these articles just for the concepts they were explaining, and I’d think, “What is this programming language? I like the concept you’re explaining, but I also want to see the programming language. Why haven’t I heard of this?”

So I started looking into Ruby, and I realized that at that time, Ruby might not have been known by anyone, but it had actually been around for a long time. Matz, the Japanese creator of Ruby, had started working on Ruby back in 1993, before the internet was even a thing. Here I am in 2003, 10 years later, picking up what seems like this hidden gem that’s just lying in obscurity in plain sight.

But Dave Thomas and Martin Fowler, I think, successfully put me and a handful of other people on the trail of a programming language that hadn’t been used much in the West, but could be. So I picked up Ruby and thought, “This is very different.” First of all, where are all the semicolons?

I’d been programming in PHP and ASP. I’d even done some Pascal, and I’d looked at some C. There were semicolons everywhere. The first thing that struck me was, “Where are the damn semicolons?” I started thinking, “Why do we have semicolons in programming?” They’re there to tell the interpreter that there’s a new line of instructions, but I don’t need them as a human. Someone is looking out for the human here, not the machine.

That really got me interested. Then I thought to myself, “You know what? I know PHP quite well. I’m not an amazing programmer. I haven’t been working in programming for all that long, but maybe I can figure it out. I’m going to give myself 2 weeks. I’m going to write a proof of concept where I talk to a database, pull some records, format them a bit, and display them on an HTML page. Can I figure that out in a couple of weeks?”

It took about 1 weekend, and I was completely mesmerized. I was completely mind-blown because Ruby was made for my brain, like a perfectly tailored glove, by someone I’d never met. How is this even possible?

Lex Fridman

We should paint a picture of the qualities that Ruby has, maybe even compared to PHP. There’s a ridiculous thing that I’m used to and forget about: there are dollar signs everywhere in PHP.

David Heinemeier Hansson

There’s line noise. That’s what I like to call it.

Lex Fridman

Line noise. That’s such a beautiful phrase.

David Heinemeier Hansson

There are all these things that look like programming. With Ruby, I mean, there are some similarities to Python. It just looks kind of like natural language. You can read it normally.

Here’s a loop that does 5 iterations. You can literally type 5.times. Now I’m calling a method on the number 5. By the way, that’s one of the beautiful aspects of Ruby: primitives like integers are also objects, and you can call 5.times and start a block. Now you’re iterating over the code in that block 5 times. That’s it.

Lex Fridman

Okay, that’s nice.

David Heinemeier Hansson

That’s not just nice. That’s exceptional. There is literally no other programming language that I know of that has managed to boil away the line noise that almost every other programming language would inject into a 5-time iteration over a block of code to that extent.

Lex Fridman

That’s a really nice example. Thank you for giving that example. That’s beautiful. I don’t think I know a programming language that does that. That’s really nice.

David Heinemeier Hansson

Ruby is full of that. Let me dive into a couple of examples because I really think it helps paint the picture. Let me preface this by saying that I actually like the ethos of Python. I think the Ruby and Python communities share a lot of similarities. They’re both dynamic, interpreted languages, and they’re both focused on immediacy, productivity, and ease of use in a bunch of ways.

But they’re also very different in many other ways. One way they’re very different is aesthetically. Python, to me—I hope I don’t offend people too much; I’ve said this before—is ugly. It’s ugly at its base because it’s full of superfluous instructions that are necessary for legacy reasons from when Guido made Python back in 1989, and that are still here in 2025. My brain can’t cope with that.

Let me give you a basic example. When you make a class in Python, the initializer method, the starting method, is def __init__. Okay, fair enough. That’s actually the same as Ruby’s def, short for definition of a method. Then it’s underscore, underscore, init, underscore, underscore.

Lex Fridman

Yeah.

David Heinemeier Hansson

Parentheses, then self, and then the first argument.

Lex Fridman

Yeah, the whole self thing.

David Heinemeier Hansson

Mm-hmm.

David Heinemeier Hansson

I look at that and go, “I’m sorry, I’m out. I can’t do it.” Everything about it offends my sensibilities to the core. Here you have the most important method that all new objects or classes have to implement, and it is one of the most aesthetically offensive ways of typing “initialize” that I’ve ever seen anywhere. And you guys are okay with this?

Lex Fridman

You’re making me feel like you’re talking about my marriage or something, and I’m now realizing I’ve been in a toxic relationship all along. I just get used to it.

David Heinemeier Hansson

That, to me, was the magic of Ruby. It opened my eyes to how beautiful programs could be. I didn’t know—I’d been working in ASP, I’d been working in PHP—that aesthetics and beautiful code were something we could optimize for, something we could pursue. Even more than that, I didn’t know we could pursue them above other objectives.

Ruby, as beautiful as it is, is not an accident, and it’s not easy. Ruby itself is implemented in C. It’s very difficult to parse Ruby code because Ruby is written for humans, and humans are messy creatures. They like things in just the right way. I can’t fully explain why the underscores in __init__ repulse me, but they do.

When I look at the Ruby alternative, it’s really instructive. Here, you have def initialize—def, a space, initialize, parentheses; not even parentheses if you don’t need to call it with arguments. There’s not even a parenthesis. That in itself is also a major part: if the human doesn’t need the additional characters, we’re not just going to put them in because it would be nicer for the computer to parse.

We’re going to get rid of the semicolons. We’re going to get rid of the parentheses. We’re going to get rid of the underscores. We’re going to get rid of all that ugliness, all the line noise, and boil it down to its pure essentials. At the same time, we’re not going to abbreviate.

This is a key difference in the aesthetics between Ruby and Python as well. Init is shorter to type. It’s only 5 characters. Initialize is a lot longer, but it looks a lot better. You don’t type it very often, so you should look at something pretty. If you don’t have to do it all the time, it’s okay that it’s long.

Those kinds of aesthetic evaluations are rife all over the Ruby language. Let me give you an even better example. The if conditional—that’s the bedrock of all programming languages. They have the if conditional. If you take most programming languages, they all have if. That’s basically the same in almost every language: a space, a starting parenthesis. We all do that. Then you have, perhaps, an object called user, and you call user.is_admin, close the parenthesis, start the brackets. Here’s what we’re going to do if the user is an admin.

Ruby doesn’t do it like that. Ruby boils almost all of it away. We start with if. That’s the same. No parentheses are necessary because there’s no ambiguity for the human to distinguish that the next part is just a single statement. So you do: if user.admin?

Lex Fridman

Yeah.

David Heinemeier Hansson

No open brackets, no parentheses, no nothing. Next line, here’s our conditional. That question mark means nothing to the computer, but it means something to the human. Ruby put in the predicate-method style purely as a communication tool between humans. It’s actually more work for the interpreter to be able to see that this question mark is there. Why is this question mark in here? Because it reads so nicely: “if user admin question mark.” That’s a very human phrase.

But it gets better. You can turn this around. You can have the statement you want to execute before the conditional. You can do user.upgrade if user.admin? We do the thing if the thing is true, instead of saying, “If the thing is true, do the thing.”

But it gets even better. This is why I love this example with the conditional, because you can keep diving into it. Let’s flip it around. A typical way of writing it would be user.downgrade if !user.admin?, right? Ruby goes, “That exclamation point is line noise. Why do we have if and then an exclamation point? That’s ugly.” We could do user.downgrade unless user.admin?

That, to me, is an encapsulation of the incredible beauty that Ruby affords the programmer through ambiguity that is only there to serve the human reader and writer. All of these statements we’ve just discussed are the same for the computer. They’ll compile down to the same C code. They’ll compile down to the same assembly code. It makes no difference whatsoever.

In fact, it just makes it harder to write an interpreter. But for the human who gets to choose whether the statement comes before the conditional or whether the predicate method has the question mark, it’s just incredible. It reads like poetry at some point.

Lex Fridman

It’s also incredible that one language designer is creating that. Guido and Matz, too—it’s like one person gets to make these extremely difficult decisions. You have to think about how it all gets parsed, and you have to think about the thousands—or, if it’s a popular language, the millions—of people who end up using this and what they feel with that question mark for the if statement. What does that feel like for—

David Heinemeier Hansson

That’s what Matz thought about, because he started his entire mission off a different premise than almost every programming language designer whose vision I’d heard articulated.

His number one goal was programmer happiness. His number one goal was the affordances that would allow programmers to articulate code in ways that not only executed correctly, but were a joy to write and a joy to read. That vision is based on a fundamentally different view of humanity.

There’s no greater contrast between Matz’s and James Gosling’s vision, the designer of Java. I once listened to James talk about the design of Java: Why was it the way it was? Why was it so rigid? He was very blunt about it, which I really appreciate. I think Gosling has done a tremendous job with Java.

But his view of humanity is rather dark. His view of humanity was that programmers, on average, are stupid creatures. They cannot be trusted with sophisticated programming languages because they’re going to shoot their foot off or their hand off, and that would be kind of inconvenient to the regional development office of a mid-tier insurance company writing code that has to last for 20 years.

Now, it’s actually a very Thomas Sowell view of constrained capacity in humans that I’ve come to appreciate much later in life. But it’s also a very depressing view of programmers: that there are just certain programmers who are too dumb to appreciate code poetry. They’re too ignorant to learn how to write it. Well, we need to give them a sandbox where they just won’t hurt themselves too much.

Matz went in the complete opposite direction. He believes in humanity. He believes in the unlimited capacity of programmers to learn and become better, so much so that he’s willing to put the stranger at his own level.

This is the second part I truly appreciate about Ruby. Ruby allows you to extend base classes. You know how we just talked about 5.times being a way to iterate over a statement five times? That 5 is obviously a base class. It’s a number. Do you know that you can add your own methods to that?

I did that extensively in Rails. We have something called Active Support, which is essentially my dialect of Ruby for programming web applications. I’ll give you one example: I’ve added a method called 5.days to the number. So if you do 5.days, you get five days in seconds, because seconds are the way we set cache expiration times and other things like that. So you can say, “Cache expires in 5.days.”

Lex Fridman

Yeah.

David Heinemeier Hansson

And you’re going to get whatever 5 × 24 × 60 × 60 is, or whatever the math is, right? It’s very humanly readable. In a normal programming language, you would type out the seconds, and then you would have a little comment above it saying, “This represents five days.” In Ruby, you get to write 5.days.

But even better than that, Matz didn’t come up with it. Matz didn’t need 5.days. I needed that because I needed to expire caches. I was allowed by Matz to extend his story with my own chapters on equal footing, such that a reader of Ruby could not tell the difference between the code Matz wrote and the code that I wrote.

He trusted me as a complete stranger from Denmark, whom he had never met, to mess with his beautiful story. That level of trust is essentially unheard of. I know there are other programming languages that allow things with macros and so forth, but none do it in a way like Ruby does. None do it with an articulated vision of humanity—a trust in humanity and programmers like Matz does. That is the opposite end of the spectrum from Java.

Lex Fridman

Yeah. I mean, for my aesthetic sensibilities, just the way you describe 5.days, that’s really pleasant to me. I could see myself sitting alone, sleep-deprived, and just writing that. It’s an easy thing. You can write it in a long way with a comment. You can write multiple lines. You could do it. Now, with AI, I’m sure it’s going to generate it correctly, but there’s something really pleasant about the simplicity of that.

I’m not sure what that is, but you’re right, there is a good feeling there. I’m sure we’ll talk about happiness from all kinds of philosophical angles, but that is what happiness is made of. That little—

David Heinemeier Hansson

Exactly.

Lex Fridman

Good feeling there.

David Heinemeier Hansson

It’s the good feeling that comes out of a concept compressed to its pure essence. There’s nothing you can take away from that statement that’s superfluous.

Lex Fridman

But see, I also want to push back a little bit, because I also program in Perl a bunch just to be cool. It’s not all about compression. No, you can compress it too far.

David Heinemeier Hansson

Perl golf is a thing where you can turn programs into something that’s unreadable for humans. Now, the great thing about Perl was that it came out before Ruby. Matz was a great student of Larry Wall, a great student of Perl, a great student of Python, Smalltalk, and Lisp. He took inspiration from all of these prior attempts at creating good programming languages and really edited down the very best bits into this. He was able to learn from their lessons.

But what I find incredible about Ruby is that here we are in 2025. Ruby has been worked on for over 30 years, and essentially the first draft is 90% of what we’re still using. There was almost a sense of divine inspiration in wherever Matz was writing that initial version of Ruby that transcended time to such a degree that no one has still even begun to reach it.

This is the other thing I always find fascinating. I generally believe in efficient market theory: If someone comes up with a better mousetrap or a better idea, others will eventually copy them to such an extent that perhaps the original mousetrap is no longer even remembered. No one has been able to copy that essence of Ruby. They’ve borrowed elements, and that’s totally fine, but Ruby still stands taller than everyone else on these metrics, on this trust in humanity and programmers.

Lex Fridman

And we should also say that maybe there’s the perfect programming language by that metric, and then there’s the successful language, and those are often different. There’s something wonderful about the Brendan Eich story of creating JavaScript. There’s something truly beautiful about the way JavaScript took over the world.

David Heinemeier Hansson

Yes. There’s something truly beautiful about the way JavaScript took over the world. I recently got to visit the Amazon jungle, and one of my favorite things to do is just to watch the ants take over anything—everything. It’s a nice distributed system. It’s a messy thing that doesn’t seem to be in order, but it just works, and the machinery of it—

Lex Fridman

Worse is better. I mean, that’s actually the name of a pattern in software development and other ways of how to do things. It’s the pattern of Linux. Linux was quantifiably worse than MINIX, I think, at the time. Other ways of doing it were more cathedral-like—

David Heinemeier Hansson

Less bizarre, and it’s still one where there’s something to it: The imperfections can help something go forward. It’s actually a trick I’ve studied to the degree that I now incorporate it in almost all the open source that I do.

I make sure that when I release the first version of any new thing I work on, it’s a little broken. It’s a little busted in ways that invite people to come in and help me, because there’s no easier way to get the collaboration of other programmers than to put something out that they know how to fix and improve.

Lex Fridman

Yeah, that’s awesome. But Ruby was somehow, or was at least, a little bit different in that regard. Not in all regards. Matz got the ethos of the language, the design of the language, just right. But the first versions of Ruby were terribly slow. It’s taken hundreds of man-years to get Ruby to be both this beautiful and also highly efficient and really fast.

We should say that the thing that made you fall in love with this particular programming language is metaprogramming.

David Heinemeier Hansson

Yes. That takes all of these elements we’ve just talked about and turns them up to 11. I’ll explain metaprogramming.

Metaprogramming is essentially a version of 5.days. You get to add keywords to the language. Active Record is the part of Rails that communicates with the database. This is a system where every table in the database is represented by a class.

So if we take the user example again, you do class User < ActiveRecord::Base, and then the first line you can write is this: “I want my users to have many posts,” or, “have many comments.” Let’s do that. We’re making some system where users can make comments. The very next line is has_many :comments.

Now you’ve set up a dependency between users and comments that will give you a whole host of access and factory methods for users to be able to own comments, create comments, and update comments. In that line alone, has_many looks like a keyword. It looks like it’s part of the Ruby language. That’s metaprogramming.

Rails is able to add these elements to how you define a class, and then that runs code that adds a bunch of methods to the User class. That’s metaprogramming. When metaprogramming is used in this way, we call it domain-specific languages. You take a generic language like Ruby and tailor it to a certain domain, like describing relationships in a database at an object level.

This is one of those early examples where you can do user has_many :comments, belongs_to :account. Now you’ve set up a one-to-one relationship. Before, we had a one-to-many relationship.

Rails is rife with all these kinds of domain-specific languages where, at times, it doesn’t even look like Ruby. You can’t identify Ruby keywords. You can just identify what looks like keywords in its own programming language.

Now again, I know that Lisp and others also do this stuff. They just do it with the maximum amount of line noise that can ever be crammed into a programming language. Ruby does it at a level where you cannot tell my metaprogramming from Matz’s keywords, and it does so with zero line noise.

Lex Fridman

Yeah, I should say that my first love was Lisp. So there’s a slow tear that you can’t see.

David Heinemeier Hansson

I’ve actually never written any real Lisp myself.

Lex Fridman

Well, how can you judge it so harshly, then?

David Heinemeier Hansson

Because I have two eyes, and I can look at code. My aesthetic sensibilities forbid me to even go much further, which is a limitation.

Lex Fridman

I know I should actually dive into Lisp, because I found that I've learned a lot just diving into—maybe I'm insulting Lisp again here—the past of programming languages, with Smalltalk, for example. I think Smalltalk is an incredible experiment that also worked but isn't suitable for today's programming environments.

I love that we're talking about Ruby so much and what beautiful code is, what a beautiful programming language is. One of the things that is, I think, implied—maybe you made explicit in your descriptions there—is that Ruby is dynamically typed versus statically typed, and you have been not just saying that it's a nice thing but that you will defend dynamic typing to the death, like that freedom is a powerful freedom to preserve. It's the essence of what makes Ruby Ruby.

This is why I don't fully understand when people call for Ruby to have static typing, because to me, it is the bedrock of what this is. Why would you want to turn one of the most beautiful languages into something far uglier?

David Heinemeier Hansson

This is one of my primary objections to static typing. It's not just that it limits you in certain ways; it makes metaprogramming harder. I write a bunch of metaprogramming. I've seen what it takes to do metaprogramming in TypeScript, and that was actually one of the things that sent me on a tear to get TypeScript out of some of the projects that I'm involved with.

We pulled TypeScript out of Turbo, one of the front-end frameworks that we have, because I tried to write some metaprogramming in TypeScript and I was just infuriated. I don't want that experience, but I also don't want it from an aesthetic point of view. I hate repetition.

We've just talked about how much I love that Ruby boils all of these expressions down to their essence. You can't remove one dot. You can't remove one character without losing something. The moment you go for static typing and declare a type—at least, I know there are ways to do implied typing and so forth, but let's just take the stereotypical case of an example: `User user = new User`. I've repeated “user” 3 times. I don't have time for this. I don't have the sensibilities for this. I don't want my Ruby polluted with this.

Now, I understand all the arguments for why people like static typing. One of the primary arguments is that it makes tooling easier. It makes it easier to do autocomplete in editors, for example. It makes it easier to find certain kinds of bugs because maybe you're calling methods that don't exist on an object, and the editor can actually catch that bug before you even run it.

I don't care. First of all, I don't write code with tools. I write it with text editors. I chisel it out of the screen with my bare hands. I don't autocomplete. This is why I love Ruby so much, and this is why I continue to be in love with the text editor rather than the IDE.

I don't want an IDE. I want my fingers to have to individually type out every element of it because it will force me to stay in the world where Ruby is beautiful. As soon as it gets easy to type a lot of boilerplate, guess what? You're going to have a lot of boilerplate.

Every single language that has great tooling support has a much higher tolerance for boilerplate because the thinking is, “Well, you're not typing it anyway. You're just autocompleting it.” I don't want that at all. I want something where the fabric I'm working in is just a text file. There's nothing else to it.

These things play together. There's the aesthetic part, there's the tooling part, there's the metaprogramming part, and there's the fact that Ruby's ethos of duck typing—I don't know if you've heard that term before—is essentially not about, “Can I call this method if an object is of a certain class?” It is, “Can I call this method if the object responds to it?”

It's very much from Smalltalk in that regard. You don't actually check whether that class has the method, which allows you to dynamically add methods at runtime and do all sorts of really interesting things that underpin all the beautiful metaprogramming that we do in Ruby.

I don't want to lose any of that, and I don't care for the benefits. One of the benefits I've seen touted over and over again is that it's much easier to write correct software. You're going to have fewer bugs. You're going to have fewer null pointer exceptions and less of all this stuff.

I don't have any of that. It is just not something that occurs in my standard mode of operation. I'm not saying I don't have bugs. Of course I do. But I catch those bugs with unit testing and integration testing. Those are the kinds of precautions that will catch logical bugs—things that compile but are wrong—along with the uncompilable stuff.

I've never been drawn into this world. Part of it is because I work on a certain class of systems. I fully accept that if you're writing systems that have 5, 10, or 50 million lines of code with hundreds, thousands, or tens of thousands of programmers, you need different methods.

What I object to is the idea that what's right for a code base of 10 million lines of code with 100,000 programmers working on it is also the same thing I should be using in my bedroom to create Basecamp because I'm just a single individual. That's complete nonsense.

In the real world, we would know that makes no sense at all. You don't use your Pagani to go pick up groceries at Costco. It's a bad vehicle for that. It doesn't have the space. You don't want to muddy the beautiful seats. You don't want to do any of those things.

We know that certain things that are very good in certain domains don't apply to all programming languages. It seems like we forget that.

Now, to be fair, I also perhaps had a reputation for forgetting that. When I first learned Ruby, I was so head over heels in love with this programming language that I almost found it inconceivable that anyone would choose any other programming language at all to write web applications.

I engaged in the evangelism of Ruby on Rails in that spirit, as a crusade. I thought, “I just need to teach you the gospel. I just need to show you this conditional code that we just talked about, and you will convert at the point of a sharp argument.”

Now I've learned that's not the way. Part of the reason it's not the way is that programmers think differently. Our brains are configured differently. My brain is configured perfectly for Ruby, perfectly for a dynamically typed language that I can chisel code out of a text editor with.

Other people need the security of an IDE. They want the security of classes that won't compile unless you call the methods on them. I've come to accept that, but most programmers don't. They're still stuck in essentially, “I like static typing, therefore static typing is the only way to create reliable, correct systems,” which is just such a mind-blowing—to be blunt, idiotic—thing to say in the face of mountains of evidence to the contrary.

This is one of the reasons I'm so in love with Shopify as the flagship application for Ruby and Rails. Shopify exists at a scale that most programmers will never touch. On Black Friday, I think Shopify did 1 million requests per second. That's not 1 million requests for images. That's 1 million dynamic requests funneling through the pipeline of commerce.

Shopify runs something like 30% of all e-commerce stores on the damn internet. A huge portion of all commerce in total runs through Shopify, and that runs on Ruby and Rails. Ruby and Rails is able to scale up to that level without using static typing in all of what it does.

I know they've done certain experiments in certain ways because they are hitting some of the limits that you will hit with dynamic typing. Some of those limits you hit with dynamic typing are actually, by the way, just limits you hit when you write 5 million lines of code.

I think the Shopify monolith is about 5 million lines of code. At that scale, everything breaks because you're at the frontier of what humans are capable of doing with programming languages.

The difference, in part, is that Ruby is such a succinct language that those 5 million lines, if they had been written in, let's just say, Go or Java, would have been 50 million or 25 million. That might have alleviated some of the problems that you have when you work on huge systems with many programmers, but it certainly would also have compounded them: trying to understand 25 million lines of code.

The thing does scale. That's a persistent myth, that it doesn't scale. Shopify and others—but Shopify, I think, is a great example. By the way, I love Shopify and I love Tobi.

Lex Fridman

You've got to have Tobi on.

David Heinemeier Hansson

For sure. He's brilliant. I got to hang out with him in the desert somewhere—I forget, in Utah. He's just a brilliant human.

Lex Fridman

I mean, it's a big company, right?

David Heinemeier Hansson

It's a huge company. I think just under 10,000 employees, a market cap of $120 billion, and GMV of a quarter of a trillion every year.

Lex Fridman

And he's involved with the details still.

David Heinemeier Hansson

He is very much so. A funny story about Tobi: Tobi was on the Rails core team back in the mid-2000s. Tobi himself wrote Active Merchant, which is one of the frameworks for creating shops. He wrote the Liquid templating language that Shopify still uses to this day.

He has a huge list of contributions to the Rails ecosystem, and he's the CEO of the company. I think it's very inspiring to me because it's at the opposite end of what I like to do. I like to chisel code with my own hands most of the day.

Lex Fridman

He runs a company of almost 10,000 people that is literally, like, world commerce depends on it.

David Heinemeier Hansson

A level of criticality I can’t even begin to understand. And yet we can see eye to eye on so many of these fundamental questions in computer science and program development. That is a dynamic range.

To be able to encompass Rails being a great tool for the one developer who’s just starting out with an idea, who doesn’t even fully know everything, who is right at the level where PHP would have been a good fit in the late 1990s because, yeah, I could probably upload something to an FTP server and so on. Rails does have more complexity than that, but it also has a much longer runway. The runway goes all the way to goddamn Shopify.

That is about the most convincing argument I can make for the sort of dynamic range we have: we can do a lot of it. And even having said that, Shopify is the outlier. Of course, I don’t think about Shopify as the primary target when I write Rails. I think of the single developer. Actually, I do think about Shopify, but I don’t think about Shopify now.

I think of Shopify when Tobi was writing Snowdevil, which was the first e-commerce store to sell snowboards that he created. There was the pre-Shopify Shopify that he created all by himself. And that was possible because Ruby and Rails isn’t just about beautiful code. It’s just as much about productivity. It’s just as much about the impact that an individual programmer is able to have: they can build a system where they can keep the whole thing in their head and move it forward, such that you can go from one developer sitting and working on something, and that something is Shopify, and it turns into what it is today.

When we talk about programming languages and compare them, we often compare them at a very late stage. What is the better programming language for, let’s say, Twitter in 2009, when it’s already a huge success? Twitter was started on Ruby and Rails. They then hit some scaling problems. It was a big debacle at the time. They ended up, I think, writing it in some other language, which, by the way, I think is the best advertisement ever for Ruby and Rails, because nothing fucking happened for 10 years after they switched over—essentially zero innovation.

Some of that was because they were doing a long conversation, and all of the early success in part came because they had the agility to quickly change and adapt and so forth. That’s what startups need. That’s what Shopify needed. That’s what Twitter needed. That’s what everyone needs, and that’s the number one priority for Ruby and Rails: to make sure that we don’t lose that.

What happens so often when development tools and programming languages are driven by huge companies is that they mirror their org chart. React and everything else needed to use it are, in some ways, a reflection of how Meta builds Facebook, because of course they are. Of course, it’s an abstraction of that. I’m not saying React isn’t a great tool or that it can’t be used by smaller teams. Of course it can. But it’s born in a very different context than something like Ruby and Rails.

Lex Fridman

Shopify.com has been supporting this podcast for the longest time. I don't think actually Tobi knows that they sponsor this podcast. I mean, it's a big company, right? I don't care that they're sponsoring. Stop sponsoring. It doesn't really matter to me. But yeah, I just want to make that explicit.

Lex Fridman

So, to linger on the scaling thing with Twitter and Shopify, can you just explain to me what Shopify is doing with YJIT? What did they have to try to do to scale this thing? Because that’s kind of an incredible story, right?

David Heinemeier Hansson

Yeah. One of the great contributions that Shopify has made to the entire Ruby ecosystem—not just Rails, but in particular Rails—is YJIT. YJIT is their compiler for Ruby that just makes everything a lot more efficient. At Shopify’s scale, eking out even a 5–10% improvement in Ruby’s overhead and execution time is a huge deal.

Now, Shopify didn’t need YJIT. Shopify was already running on the initial version of Ruby that was, I think, 10 times slower than what we have today. If you look back upon Ruby 1.8.6, which Tobi probably started on, just as I started on, that was enough to propel Shopify to the scale that it has today.

A lot of the scaling conversation is lost in a failure to distinguish two things. Scale is one package we talk about when there are really multiple packages inside of it. One is runtime performance—latency. How fast can you execute a single request? Can it happen fast enough that the user will not notice? If your Rails request takes 1.5 seconds to execute, the user is going to notice. Your app is going to feel slow and sluggish. You have to get that response time down below, let’s say, 300 milliseconds. I like to target 100 milliseconds as my latency.

That’s performance: how much performance of that kind of latency can you squeeze out of a single CPU core? That tells you something about what the price of a single request will be. But then there’s whether you can deal with 1 million requests per second, like Shopify is doing right now. If you have one box that can do 1,000 requests per second, you just need X boxes to get up to 1 million.

What you’ll actually find is that, when it comes to programming languages, they’re all the same in this way. They all scale beautifully, largely horizontally. You just add more boxes. The hard parts of scaling Shopify are typically not the programming language. It’s the database. That’s actually one of the challenges that Shopify has now: how do you deal with MySQL at the scale that they’re operating at? When do you need to move to other databases to get worldwide performance? All of these things.

The questions about scaling Ruby are economic questions. If we’re spending so much on application servers, if we can get just 5% more performance out of Ruby, we could save 5% of those servers, and that could filter down into the budget. That analysis concludes with basically one thing: Ruby is a luxury language. It’s a luxury—the highest luxury, in my opinion. It is the Coco Chanel of programming languages, something that not everyone can afford. And I mean this in the best possible way.

There are some applications on the internet where each request has so little value that you can’t afford to use a luxurious language like Ruby to program in it. You simply have to slum it with C or Go or some other low-level language, or Rust.

Lex Fridman

The thrift store of languages.

David Heinemeier Hansson

Exactly. Where you need a very low level to do it, you can’t afford to use a luxury language to build it with. That’s not true of Shopify. It wasn’t true of Basecamp, even back in 2004. It’s not been true of 99% of all web applications ever created.

Because the main cost component of 99% of web applications isn’t CPU cores. It’s wetware cores. It’s human cores. It’s human capacity to understand and evolve systems. It’s their personal productivity.

I did a calculation once when someone had, for the 400th time, said, “Oh, if you switched from Ruby to some faster language, you could save a bunch of money.” I calculated it out, and at the time—I think the last time I did this calculation was almost a decade ago—we were spending about 15% of our operating budget on Ruby application servers.

For me to improve my cost profile of the business by 7 percentage points, I’d have to pick something twice as fast. That’s quite hard. Versus if Ruby and Rails were even 10% more productive than something else, I would move the needle far more, because making individual programmers more productive actually matters a lot more.

This is why people are so excited about AI. This is why they’re freaking out over the fact that a single programmer in Silicon Valley who makes $300,000 a year can now do the work of 3 or 5, at least in theory. I haven’t actually seen that fully in practice, but let’s just assume the theory is correct. If not now, then in 6 months, that’s a huge deal. That matters so much more than whether you can squeeze a few more cycles out of the CPU when it comes to these kinds of business applications.

Lex Fridman

If you’re making Unreal Engine rendering stuff, like Tim Sweeney, who you had on—

David Heinemeier Hansson

Yeah, he needs to really sweat all those details.

Lex Fridman

The Nanite engine can’t run on Ruby. It’s never going to. It was not meant for that.

David Heinemeier Hansson

Fine. These kinds of business applications absolutely can. And everything that people are excited about AI for right now—that extra capacity to just do more—that was why we were excited about Ruby back in the early 2000s. That was because I saw that if we could even squeeze out a 10% improvement in the human programmer, we’d be able to do so much more for so much less.

Lex Fridman

I’d probably argue about this, but I really like working together with AI, collaborating with AI, and I would argue that the kind of code you want AI to generate is human-readable, human-interpretable.

David Heinemeier Hansson

Yes. If it’s generating Perl golf code, it’s just not a collaboration. It has to be speaking to the human. It’s not just that you’re writing the prompts in English. You also want to read the responses in a human-interpretable language like Ruby, right?

That’s actually beneficial for AI too, because you’ve kind of said that for you, the sculptor—the sort of elitist Coco Chanel sculptor—you want to, on your fancy keyboard, type every single letter yourself with your own fingers. But the benefit of Ruby also applies when some of that is written by AI and you’re actually doing the editing part with your own fingers.

Yes. Because you can interact with it because it's human-interpretable. The paradigm I really love with this was something Elon actually said on one of your shows when you guys were talking about Neuralink: Neuralink allows the bandwidth between you and the machine to increase. Language, either spoken or written, is very low bandwidth. If you were to calculate just how many bits we can exchange as we're sitting here, it's very slow.

Ruby has a much higher bandwidth of communication. It reveals and conveys so much more concept per character than most other programming languages do. So, when you are collaborating with AI, you want really high bandwidth. You want it to be able to produce programs with you, whether you're letting it write the code or not, that both of you can actually understand really quickly, and that you can compress a grand concept or a grand system into far fewer parts that both of you can understand.

Now, I actually love collaborating with AI, too. I love chiseling my code, and the way I use AI is in a separate window. I don't let it drive my code. I've tried that. I've tried Cursor and Windsurf, and I don't enjoy that way of writing.

One of the reasons I don't enjoy that way of writing is I can literally feel competence draining out of my fingers. That level of immediacy with the material disappears. Where I felt this the most was when I did this remix of Ubuntu called Omakub when I switched to Linux, and it's all written in Bash. I'd never written any serious amount of code in Bash before.

So, I was using AI to collaborate and write a bunch of Bash with me because I needed all this. I knew what I wanted. I could express it in Ruby, but I thought it was an interesting challenge to filter it through Bash because what I was doing was setting up a Linux machine. That's basically what Bash was designed for. It's a great constraint.

But what I found myself doing was asking AI for the same way of expressing a conditional, for example, in Bash, over and over again. By not typing it, I wasn't learning it. I was using it. I was getting the expression I wanted, but I wasn't learning it. And I got a little scared. I got a little scared: Is this the end of learning? Am I no longer learning if I'm not typing?

The way I recast that for me was: I don't want to give up on the AI. It is such a better experience as a programmer to look up APIs, to get a second opinion on something, to do a draft, but I have to do the typing myself because you learn with your fingers. If you're learning how to play the guitar, you can watch as many YouTube videos as you want. You're not going to learn the guitar. You have to put your fingers on the strings to actually learn the motions.

I think there is a parallel here to programming, where programming has to be learned in part by the actual typing.

Lex Fridman

This is fascinating. Listen, part of my brain agrees with you 100%; part doesn't. I think AI should be in the loop of learning. Current systems don't do that, but I think it's very possible for Cursor to basically force you to type certain things. So, if you set the mode to learning—

I just don't want to be the sort of person who gives up on AI. I really think vibe coding is a skill. For an experienced programmer, it's too easy to dismiss vibe coding as a thing.

David Heinemeier Hansson

I agree. I wouldn't dismiss it.

Lex Fridman

But I think you need to start building that skill and start to figure out how to prevent the competency from slipping away from your fingers and brain. How do you develop that skill in parallel to the other skill? I don't know. I just think it's a fascinating puzzle, though. I know too many really strong programmers that just kind of avoid AI because it's currently a little too dumb.

David Heinemeier Hansson

Yes, it's a little too slow. That's actually my main problem. It's a little too dumb in some ways, but it's a little too slow in other ways. When I use Claude Code, the terminal version of Claude, which is actually my preferred way of using it, I just get too impatient.

It feels like I'm going back to a time when code had to compile and I had to go do something else or boil some tea while the code was compiling. I've been working in Ruby for 20 years. I don't have the compile wait in me anymore.

But I think the more crucial aspect for me is I really care about the competence. I've seen what happens to even great programmers the moment they put away the keyboard. Even before AI, this would happen as soon as people got promoted. Most great programmers who work in large businesses stop writing code on a daily basis because they simply have too many meetings to attend. They have too many other things to do, and invariably they lose touch with programming.

That doesn't mean they forget everything. But if you don't have your fingers in the source, you are going to lose touch with it. There's just no other way. I don't want that because I enjoy it too much.

This is not just about outcomes. This is what's crucial to understand. Programming for programmers who like to code is not just about the programs they get out of it. That may be the economic value. It's not the only human value. The human value is just so much in the expression.

When someone sits down at a guitar and plays “Stairway to Heaven,” there's a perfect recording of that that will last in eternity. You can just put it on Spotify. You don't actually need to do it. The joy is to command the guitar yourself. The joy of a programmer, of me as a programmer, is to type the code myself.

If I elevate, if I promote myself out of programming, I turn myself into a project manager—a project manager of a murder of AI crows, as I wrote the other day. I could have become a project manager my whole career. I could have become a project manager 20 years ago if I didn't care to write code myself and just wanted outcomes. That's how I got started in programming. I just wanted outcomes. Then I fell in love with programming, and now I'd rather retire than give it up.

Now, that doesn't mean you can't have your cake and eat it too. I've done some vibe coding where I didn't care that I wasn't playing myself. I just wanted to see something. There was an idea in my head. I wanted to see something. That's fine.

I also use AI all day long. In fact, I'm already at the point where, if you took it away from me, I'd be like, “Oh my God, how do we even look things up on the internet anymore?” Is Stack Overflow still around? Are forums still a thing? How do I even find answers to some of these questions I have all day long? I don't want to give up AI.

In fact, I'd say the way I like to use AI, I'm getting smarter every day because of AI. I'm using AI to have it explain things to me, even stupid questions I would be a little embarrassed to enter into Google. AI is perfectly willing to give me the ELI5 explanation of some Unix command I should have known already, but I don't. “I'm sorry. Can you just explain it to me?” And now I know the thing.

So, at the end of the day of me working with AI all day long, I'm a little bit smarter—like 5%. Sorry, not 5%, half a percent maybe. That compounds over time. But what I've also seen when I worked on the Omakub project and tried to let AI drive for me, I felt I was maybe half a percent dumber at the end of the day.

Lex Fridman

Okay, you said a lot of interesting things. First of all, let's just start with the very fact that asking dumb questions—if you go to Stack Overflow and ask a dumb question, or read somebody else's dumb question and the answer to it, there's a lot of judgment there.

David Heinemeier Hansson

Yes.

Lex Fridman

AI sometimes, to an excessive degree, has no judgment. It usually says, “Oh, that's a great question,” to a fault.

David Heinemeier Hansson

Yeah. Oh, that's wonderful. It's so conducive to learning. It's such a wonderful tool for learning, and I would miss it, too. It's basically a great search engine into all kinds of nuances of a particular programming language, especially if you don't know it that well. For APIs, you can load in documentation. It's just so great for learning.

For me personally, on the happiness scale, it makes me more excited to program. I don't know what that is exactly. Part of that is—I'm really sorry, Stack Overflow is an incredible website, but there is a negativity there. There's a judgment there.

It's exciting to be with a hype man next to me, just saying, “Yeah, that's a great idea,” and I'll say, “No, that's wrong.” I'll correct the AI, and the AI will say, “You're absolutely right. How did I not think about that?” It'll rewrite the code. I'm like, “Holy shit, I'm having—” It's like a buddy that's really being positive and is very smart and is challenging me to think. Even if I never use the code it generates, I'm already a better programmer.

But actually, the deeper thing is, for some reason, I'm having more fun. That's a really important thing.

Lex Fridman

I like to think of it as a pair programmer, for exactly that reason.

David Heinemeier Hansson

Pair programming came into vogue in the 2000s, where you'd have 2 programmers in front of 1 machine and you'd push the keyboard between you. One programmer would be driving, typing in the code. The other programmer would essentially sit and watch the code, suggest improvements, and look something up. That was a really interesting dynamic.

Now, unfortunately, I'm an introvert, so I can do that for about 5 minutes before I want to jump off a bridge. It doesn't work for me as a full-time occupation, but AI allows me to have all the best of that experience all the time. I think what's really interesting is what you said about it making it more fun. I hadn't actually thought about that, but what it's made more fun for me is to be a beginner again.

It's made it more fun to learn Bash successfully for the first time.

Now, I had to do the detour where I let it write all the code for me, and I realized I wasn't learning nearly as much as I hoped I would. I started doing that once I typed it out myself. But it gave me the confidence that, you know what, if I need to do some iOS programming myself—I haven't done that in probably 6 years, the last time I dabbled in it—I feel highly confident now that I could sit down with AI and have something in the App Store by the end of the week.

I would not have that confidence unless I had a pair-programming buddy like AI. I don't actually use it very much for Ruby code. I'm occasionally impressed whenever I try it. I'm like, “Oh, it got this one thing right. That is truly remarkable, and it's actually pretty good.” And then I'll ask it 2 more questions, and I'll go, “Oh, yeah. Okay. If you were my junior programmer, I'd start tapping my fingers and going, ‘You got to shape up.’”

The great thing, of course, is that we can just wait 5 minutes. The Anthropic CEO seems to think that 90% of all code by the end of the year is going to be written by AI. I'm more than a little bit skeptical about that, but I'm open-minded about the prospect that programming could potentially turn into a horse when done manually—something we do recreationally.

It's no longer a mode of transportation to get around L.A. You're not going to saddle up, go to the grocery store, and pick up stuff from Whole Foods in your saddlebags. That's just not a thing anymore. That could be the future for programming—for manual programming. Entirely possible.

I also don't care. Even though we have great renditions of all the best songs, as I said, there are millions of people who love to play the guitar. It may no longer have as much economic value as it once did. I'm quite convinced that we perhaps have seen the peak. I understand the paradox: when the price of something goes down, the overall usage goes up, and total spend on that activity goes up. That could also happen, maybe.

But what we're seeing right now is that a lot of the big shops, a lot of the big companies, are not hiring like they were 5 years ago. They're not anticipating they're going to need tons more programmers. Controversially, Tobi actually put out a memo inside Shopify asking everyone who's considering hiring someone to ask the question, “Could this be done by AI?”

He's further ahead on this question than I am. I look at some of the coding trenches and go, “I'd love to use AI more, and I see how it's making us more productive, but it's not yet at the level where I just go, ‘Oh, we have this project. Let me just give it to the AI agent, and it's going to go off and do it.’”

Lex Fridman

But let's just be honest. You're like a Clint Eastwood-type character, a cowboy on a horse, seeing cars going around, and you're like, “Well...”

David Heinemeier Hansson

That's part of it. I think it is important to have that humility—that what you are good at may no longer be what society values. This has happened a million times in history. You could have been exceptionally good at saddle-making, for example. That's something that a lot of people used to care about because everyone rode a horse, and then suddenly riding a horse became this niche hobby that some people care about, but not nearly as many. That's okay.

The other thing is that I've had the good fortune to have been a programmer for nearly 30 years. That was a great run. I try to look at life in this way: I've already been blessed with decades of economically viable, highly valuable ways of translating what I like best in the working world into writing Ruby code. That was so valuable that I could make millions and millions of dollars doing it.

If that's over tomorrow, I shouldn't look at that with regret. I should look at it with gratitude.

Lex Fridman

But you're also a highly experienced, brilliant, and opinionated human being. So, it's really interesting to get your opinion on the future of the craft, because there are a lot of young people listening to this who love programming or who are excited by the possibility of building stuff with software, with Ruby on Rails, that kind of language, and now the possibility of building more and more with AI.

Is it a career? And if indeed a single person can build more and more with the help of AI, how do they learn that skill? Is this a good skill to learn? To me, that's the real mystery here, because I think it's still absolutely true that you have to learn how to program from scratch currently.

David Heinemeier Hansson

Yes.

Lex Fridman

But how do you balance those 2 skills? Because, as I'm thinking now, there is a scary slipping away of skill that happens in a matter of really minutes on a particular piece of code. It's scary. It's not like driving, you know, when you have a car drive for you. It doesn't quite slip away that fast, so that really scares me.

When somebody comes up to me and asks me, “How do I learn to program?” I don't know what the advice is, because I think it's not enough to just use Cursor or Copilot to generate code.

David Heinemeier Hansson

It's absolutely not enough. Not if you want to learn. Not if you want to become better at it. If you just become a tap monkey, maybe you're productive for a second, but then you have to realize: can anyone just tap if that's all we're doing, sitting around all day tapping? Yes. Yes. Yes. Yes. Yes. That's not a marketable skill.

I always preface this, both to myself and when I speak to others about it, with rule number one: nobody fucking knows anything. No one can predict even 6 months ahead. Right now, we're probably at peak AI-future hype, because we see all the promise, because so much of it is real, and so many people have experienced this mind-boggling thing themselves: that the silicon is thinking in some way that feels eerily reminiscent of humans.

I'd actually say the big thing for me wasn't even ChatGPT. It wasn't even Claude. It was DeepSeek. Running DeepSeek locally and seeing the think box, where it converses with itself about how to formulate the response, I almost wanted to think, “Is this a gimmick? Is it doing this as a performance for my benefit?” But is that actually how it thinks? If this is how it actually thinks, okay, I'm a little scared.

Lex Fridman

Yeah.

David Heinemeier Hansson

This is incredibly human, how it thinks in this way.

Lex Fridman

But where does that go?

David Heinemeier Hansson

In 1995, one of my favorite B movies came out: The Lawnmower Man. Incredible movie about virtual reality, being an avatar, and living in VR. The story was a mess, but the aesthetics—the world that it built up—were incredible.

I thought, “We're 5 years away. I'm going to be living in VR now. I'm just going to be floating around. I'm going to be an avatar. This is where most humans can spend most of their day.” That didn't happen. We're 30 years later, and VR is still not here. It's here for gaming. It's here for some specialized applications.

My oldest loves playing Gorilla Tag. I don't know if you've tried that. That's basically the hottest VR game.

Lex Fridman

Wonderful. That's great.

David Heinemeier Hansson

It's really hard to predict the future because we just don't know. When you factor in AI, you have even the smartest people going, “I don't think we fully understand how this works.”

Lex Fridman

But then, on the flip side, you have Moore's law, which seems to have worked for many, many, many years in decreasing the size of transistors, for example. So, like—

David Heinemeier Hansson

You know, Flash didn't take over the internet, but Moore's law worked. So we don't know which one AI is—

What it is. And this is what I find so fascinating, too. I forget who did this presentation, but someone in the web community did this great presentation on the history of the airplane.

You go from the Wright brothers flying in 1903 or something like that, and 40 years later you have jet flight—just an unbelievable amount of progress in 4 decades. Then, in 1956, I think it was, the hull design for the Boeing 747's essential precursor was designed, and basically nothing has happened since—just minor tweaks and improvements on the flying experience since the '50s.

If you were to predict where flying was going to go, and you were sitting in '42, and you'd seen—remember, the Wright brothers flying in '03—and you were seeing those jet engines coming, you'd be like, “We're going to fly to the stars in another 2 decades. We're going to invent super-mega-hypersonic flights that are going to traverse the Earth in 2 hours.” And then that didn't happen. It tapped out.

This is what's so hard about predicting the future. We can be so excited in the moment because we're drawing a line through early dots on a chart, and it looks like those early dots are just going up and to the right. Sometimes they just flatten out.

This is also one of those things where we have so much critical infrastructure, for example, that still runs on COBOL, and about 5 humans around the world really understand it truly deeply. There's a possibility for society to lose a competence it still needs because it's chasing the future. COBOL is still with us.

This is one of the things I think about with programming. Ruby and Rails is at such a level now that, 50 years from now, it's exceedingly likely that there's still a ton of Ruby and Rails systems running around. It's very hard to predict what that exact world is going to be like, but yesterday's weather tells us that if there's still COBOL code from the '70s operating Social Security today, and we haven't figured out a clean way to convert that, let alone understand it, we should certainly be humble about predicting the future.

I don't think any of the programmers who wrote that COBOL code back in the '70s had any damn idea that in 2025, checks were still being cut from the business logic that they had encoded back then.

But that just brings me to the conclusion on the question of what a young programmer should do. You're not going to be able to predict the future. No one's going to be able to predict the future. If you like programming, you should learn programming. Now, is that going to be a career forever? I don't know. But what's going to be a career forever? Who knows?

A second ago, we thought that it was blue-collar labor that was going to be abstracted first. It was the robots that were going to take over. Then GenAI comes out, and all the artists suddenly look like, “Holy shit, is this going to do all animation now? It's going to do all music now.” They get real scared. And now I see the latest Tesla robot going, “Oh, maybe we're back now to blue-collar being in trouble, because if it can dance like that, it can probably fix a toilet.”

So no one knows anything, and you have to position yourself for the future in such a way that it doesn't matter if you pick a profession or path where, if it turns out that you have to retool and reskill, you're not going to regret the path you took. That's a general life principle for me. How I look at all endeavors I involve myself in is that I want to be content with all outcomes.

When we start working on a new product at 37signals, I set up my mental model for its success. And I go, “Do you know what? If no one wants this, I will have had another opportunity to write beautiful Ruby code, to explore a greenfield domain, to learn something new, to build a system I want, even if no one else wants it. What a blessing. What a privilege. If a bunch of people want it, that's great. We can pay some salaries, we can keep the business running, and if it's a blowaway success, wonderful, I get to impact a bunch of people.”

Lex Fridman

I think one of the big open questions to me is how far you can get with vibe coding, whether the approach for a young developer is to invest most of their time into vibe coding or into writing code from scratch. So, vibe coding—I'm leaning into the meme a little bit—but vibe coding means you generate code. You have this idea of a thing you want to create, you generate the code, and then you fix it, both with natural language through the prompts and manually. You learn enough to manually fix it.

So that's the learning process: how you fix code that's generated. Or you write code from scratch and have the LLMs kind of tab, tab, tab, tab, add extra code. Which part do you lean on?

David Heinemeier Hansson

I think, to be safe, you should find the beauty and the artistry and the skill in both. Right from scratch, there should be some percentage of your time just writing from scratch and some percentage of the time vibe coding. There should be more of the time writing from scratch.

If you're interested in learning how to program, unfortunately, you're not going to get fit by watching fitness videos. You're not going to learn how to play the guitar by watching YouTube guitar videos. You have to actually play yourself. You have to do the sit-ups. Programming—understanding and learning almost anything—requires you to do. Humans are not built to absorb information in a way that transforms into skills by just watching others from afar.

Now, ironically, it seems AI is actually quite good at that. But humans are not. If you want to learn how to become a competent programmer, you have to program. It's really not that difficult to understand.

Now, I understand the temptation. The temptation is there because vibe coding can produce things, perhaps in this moment, especially in a new domain you're not familiar with, with tools you don't know perfectly well, that are better than what you could do or that you would take much longer to get at. But you're not going to learn anything. You're going to learn in this superficial way that feels like learning but is completely empty calories.

And secondly, if you can just vibe code it, you're not a programmer. Then anyone could do it, which may be wonderful. That's essentially what happened with the Access database. That's what happened with Excel. It took the capacity of accountants to become software developers because the tools became so accessible to them that they could build a model for how the business was going to do next week. That required a programmer prior to Excel. Now, it didn't, because they could do it themselves. Vibe coding enables non-programmers to explore their ideas in a way that I find absolutely wonderful, but it doesn't make you a programmer.

Lex Fridman

I agree with you, but I want to allow room for both of us to be wrong. For example, vibe coding could actually be a skill that, if you train it—and by vibe coding, let's include the step of correction, the iterative correction—it's possible, if you get really good at that, that you're outperforming the people who write from scratch, that you can come up with truly innovative things, especially at this moment in history, while the LLMs are a little bit too dumb to create super-novel things and a complete product, but they're starting to creep close to that.

So, if you're investing time now into becoming a really good vibe coder, maybe this is the right thing to do, as if it's indeed a skill. We kind of meme about vibe coding, just like sitting back, and it's in the name. But if you treat it seriously, a competitive vibe coder can get good at riding the wave of AI and get good at the skill of editing code versus writing code from scratch. It's possible that you can actually get farther in the long term.

Maybe editing is a fundamentally different task than writing from scratch if you take that seriously as a skill that you develop.

David Heinemeier Hansson

I see. To me, that's an open question. I just think that, personally—and now you're on another level—but just me, personally, I'm not as good at editing the code that I didn't write.

Lex Fridman

No one of this generation is good at that. But maybe that's a skill. Maybe if you get on the same page as the AI, because there's a consistency to the AI—it's like, it really is a pair programmer with a consistent style and structure and so on. Plus, with your own prompting, you can control the kind of code you write. I mean, it could legitimately be a skill.

David Heinemeier Hansson

That's the dream of the prompt engineer. I think it's a complete pipe dream. I don't think editors exist who aren't good at writing. I've written a number of books. I've had a number of professional editors. Not all of them wrote their own great books, but all of them were great writers in some regard.

You cannot give someone pointers if you don't know how to do it. It's very difficult for an editor to be able to spot what's wrong with a problem if they couldn't make the solution themselves. Editing, in my opinion, is the reward. The capacity to be a good editor is the reward you get from being a good doer. You have to be a doer first.

Now, that's not the same as saying that vibe coding and prompt engineering won't be able to produce fully formed, amazing systems even shortly. I think that's entirely possible. But then there's no skill left, which maybe is the greatest payoff of all. Wasn't that the whole promise of AI anyway? That it was just all natural language, that even my clumsy way of formulating a question could result in a beautiful, succinct answer?

That, to me, is a much more appealing vision than that there are going to be these special prompt-engineering wizards who know how to tickle the AI just right to produce what they want. The beauty of AI is to think that someone who doesn't know the first thing about how AI actually works is able to formulate their idea and their aspirations for what they want, and the AI could somehow take that messy clump of ideas and produce something that someone wants.

That's actually what programming has always been. There have very often been people who didn't know how to program, who wanted programs, who then hired programmers who gave them messy descriptions of what they wanted and then, when the programmers delivered that back, said, “Oh, no, actually that's not what I meant. I want something else.” AI may be able to provide that cycle.

If that happens to the fullest extent of it, yeah, there's not going to be as many programmers around, right? But hopefully, presumably, someone still, at least for the foreseeable future, will have to understand whether what the AI is producing actually works or not.

Lex Fridman

As an interesting case study, maybe a thought experiment: if I wanted to vibe code Basecamp or HEY, and some of the products you've built, what would be the bottlenecks? Where would I fail along the way?

David Heinemeier Hansson

What I've seen when I've been trying to do this, trying to use vibe coding to build something real, is that you actually fail really early. Vibe coding is able to build a veneer, at the present moment, of something that looks like it works, but it's flawed in all sorts of ways.

There are the obvious ways, the meme ways: it's leaking all your API keys; it's storing your password in plain text. I think that's ultimately solvable. It's going to figure that out, or at least it's going to get better at that. But its capacity to get lost in its own labyrinth is very great right now.

You let it code something, and then you want to change something, and it becomes a game of whack-a-mole real quick. Pieter Levels, who's been doing this wonderful flight simulator, was talking about that—where, at a certain scale, the thing just keeps biting its own tail. You want to fix something, and it breaks 5 other things, which I think is actually uniquely human, because that's how most bad programmers are at a certain level of complexity with the domain. They can't fix one thing without breaking 3 other things.

So, in that way, I'm actually, in some ways, almost positive that the AI is going to figure this out, because it's on an extremely human trajectory right now. The kind of mistakes it's making are the kind of mistakes that junior programmers make all the time.

Lex Fridman

Yeah. Can we zoom out and look at the vision, the manifesto, the doctrine of Rails? What are some of the things that make a programming language, a framework, great, especially for web development? So, we talked about happiness.

David Heinemeier Hansson

Yes.

Lex Fridman

The underlying objective of Ruby—what else?

David Heinemeier Hansson

So, you're looking at the 9 points I wrote out in, I think, 2012. Before we dive into them, I want to say the reason I wrote them down is that if you want a community to endure, you have to record its values and you have to record its practices. If you don't, eventually you're going to get enough new people coming in who have their own ideas of where this thing should go. And if we don't have a guiding light helping us make decisions, we're going to start flailing. We're going to start actually falling apart.

I think this is one of the key reasons that institutions of all kinds start falling apart. We forget why Chesterton's fence is there. We just go, "Why is that fence there? Let's yank it out." Oh, it was to keep the wolves out. Now we're all dead. Oops.

So I wanted to write these things down. If we just take them quickly, one by one, you talked about optimizing for programmer happiness. I put that at number 1 in homage to Matz. And that's a lot about accepting that there is occasionally a trade-off between writing beautiful code and other things we want out of systems. There can be a runtime trade-off. There can be a performance trade-off, but we're going to do it nonetheless.

We're also going to allow ambiguity in a way that many programmers, by default, are uncomfortable with. I give the example here of the interactive Ruby shell, where you can play with the language or even interact with your domain model. You can quit it in 2 ways, at least that I found. You can write exit—boom, you're out of the program. You can write quit—boom, you're out of the program. They do the same thing. We just wrote both exit and quit, or the people who built that wrote both exit and quit, because they knew humans were likely to pick one or the other.

Python is the perfect contrast to this. In the Python interactive prompt, if you write exit, it won't exit. It'll give you a fucking lesson. It'll basically tell you to read the fucking manual. It says, "Use exit() or Ctrl-D, i.e., end-of-file, to exit." I'm like, one is very human and the other is very engineer. And I mean that both of them in the best possible way.

Lex Fridman

Python is pedantic. Python's stated value from the start is that there should be preferably one and only one way to do a certain thing. Ruby goes the complete opposite. No, we want the full expression that fits different human brains, such that it seems like the language is guessing just what they want. And part of that is also the principle of least surprise, which is difficult to engineer into a language because it's a subjective thing. What is—

David Heinemeier Hansson

Which is why you can't do it in one way, which is why I use the example of both exit and quit. The principle of least surprise for some people would be, "Oh, exit—that's how I get out of the prompt." For other people, it would be quit. Why don't we just do both?

Lex Fridman

Okay, so what's the convention over configuration? That's a big one.

David Heinemeier Hansson

That's a big one. That's a huge one, and it was born out of a frustration I had in the early days, especially with Java frameworks, where, when you were setting up a web application framework for Java back in the day, it was not uncommon to literally write hundreds, if not thousands, of lines of XML configuration files.

"Oh, I need this. I want the database to use the foreign keys as post_id." No, no, no. "I want it as postID." Oh, no, no, no. "You have to do a capital P ID." There are all these ways where you can configure how foreign keys should work in a database, and none of them matter. We just need to pick one, and then that's fine. And if we pick one and we can depend on it, it becomes a convention. And if it's a convention, we don't have to configure it. And if we don't have to configure it, you can get started with what you actually care about much quicker.

So convention over configuration is essentially taking that idea that the system should come 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. You can change it. It's still built out of Legos. You can still take some pieces off and put in some other pieces, but I'm giving you the final product.

This cuts against the grain of what most programmers love. They love a box of Legos. They love to put everything together from scratch. They love to make all these detailed little decisions that just don't matter at all. And I want to elevate that up such that, hey, I'm not trying to take the decisions away from you. I just want you to focus on decisions that actually matter, that you truly care about. No one cares about whether it's post_id, postID, or PostID. Great defaults. It's just a wonderful thing.

You have all these aspirations. You're going to do some kind of custom, most beautiful Lego castle that nobody's ever built from these pieces. But in reality, to be productive in most situations, you just need to build the basic thing, and then on top of that is where your creativity comes.

Lex Fridman

Absolutely. And I think this is one part of the doctrine that a lot of programmers who get to use Ruby and Rails begrudgingly will acknowledge is a nice thing, even if they don't really like it. It's hard to beat the attraction to building with Legos from scratch among programmers. That's just what we like. This is why we're programmers in the first place: because we like to put these little pieces together. But we can direct that instinct toward a more productive end of the stack.

Okay, what are some of the other ones?

David Heinemeier Hansson

The menu is omakase. It actually comes out of the same principle that great defaults really matter. If you look at everything that's wrong with the JavaScript ecosystem right now, for example, it is that no one is in charge of the menu. There are a billion different dishes, and you can configure just your tailored, specific configuration of it, but no one has done the work to make sure it all fits together.

So you have all these unique problems in the JavaScript ecosystem. For example, there's probably 25 major ways of just doing the controller layer, and then as many of how to talk to the database. So you get this permutation of N × N × N: no one is using the same thing, and if they are using the same thing, they're only using the same thing for about 5 minutes. So we have no retained wisdom. We build up no durable skills.

Rails goes the complete opposite way of saying, "Do you know what? Rails is not just a web framework. It is a complete attempt at solving the web problem. It's a complete attempt at solving everything you need to build a great web application." And every piece of that puzzle should ideally be in the box, preconfigured, preassembled. If you want to change some of those pieces later, that's wonderful. But on day 1, you'll get a full menu designed by a chef who really cared about every ingredient, and you're going to enjoy it.

And that's again one of those things where many programmers think, "I know better," and they do in some hyperlocal sense of it. Every programmer knows better. This is what Ruby is built on: that every programmer knows better in their specific situation. Maybe they can do something dangerous. Maybe they think they know better and then they blow their foot off, and then they truly will know better because they've blown their foot off once and won't do it again. But the menu is that.

Lex Fridman

So you, in general, see the value in the monolith.

David Heinemeier Hansson

Yes. The integrated system.

Lex Fridman

Integrated.

David Heinemeier Hansson

Someone thought of the whole problem. This is one of the reasons why I've been on a crusade against microservices since the term was coined. Microservices was born out of essentially a good idea. What do you do at Netflix scale when you have thousands of engineers working on millions of lines of code? No one can keep that entire system in their head at one time. You have to break it down.

Microservices can be a reasonable way to do that when you're at Netflix scale. When you apply that pattern to a team of 20 programmers working on a codebase of half a million lines of code, you're an idiot. You just don't need to turn method invocations into network calls. It is the first rule of distributed programming: do not distribute your programming. It makes everything harder. All the failure conditions you have to consider as a programmer just become infinitely harder when there's a network cable involved.

So I hate the idea of premature decomposition, and microservices is exactly that. The monolith says, "Let's try to focus on building a whole system that a single human can actually understand," and push that paradigm as far as possible by compressing all the concepts such that more of it will fit into the memory of a single operating human. Then we can have a system where I can actually understand all of Basecamp. I can actually understand all of HEY.

Both of those systems are just over 100,000 lines of code. I've seen people do this at maybe twice, maybe 3 times that scale, and then it starts breaking down once you get north of certainly half a million lines of code. No individual human can do it. And that's when you get into maybe some degree of microservices can make sense.

Lex Fridman

Basecamp and HEY are both 100,000—

David Heinemeier Hansson

100,000 lines of code.

Lex Fridman

Oh, that's small.

David Heinemeier Hansson

It is, considering the fact that Basecamp, I think, has something like 420 screens, different ways and configurations.

Lex Fridman

Do you include the front end in that?

David Heinemeier Hansson

No, that's the Ruby code. Well, it's front end in the sense that some of that Ruby code is beneficial to the front end, but it's not JavaScript, for example. Now, the other thing we might talk about later is we write very little JavaScript, actually, for all of our applications.

HEY, which is a Gmail competitor, Gmail ships, I think, 28 megabytes of uncompressed JavaScript. If you compress it, I think it's about 6 megabytes.

28 megabytes. Think about how many lines of code that is. When HEY launched, we shipped 40 kilobytes.

Lex Fridman

It's trying to solve the same problem. You can solve the email client problem with either 28 megabytes of uncompressed JavaScript or with 40 kilobytes if you do things differently.

David Heinemeier Hansson

But that comes to the same problem, essentially. This is why I have fiercely fought splitting the front end and back end apart. That, in my opinion, was one of the great crimes against web development—

Lex Fridman

—that we're still atoning for.

David Heinemeier Hansson

We separated and divided what was and should be a unified problem-solving mechanism. When you're working on both the front end and back end, you understand the whole system, and you're not going to get into these camps that decompose. Eventually, you end up with shit like GraphQL.

Lex Fridman

Okay, let's fly through the rest of the doctrine. No one paradigm.

David Heinemeier Hansson

“No one paradigm” goes to the fact that Ruby is a fiercely object-oriented programming language at its core, but it's also a functional programming language. These blocks I've told you about—you can essentially do these anonymous function calls, and you can chain them together, very much in the spirit of how true functional programming languages work. Ruby has even moved closer toward the functional programming end of the scale by making strings immutable. There are ideas from all different disciplines and all different paradigms of software development that can fit together.

Smalltalk, for example, was only object-oriented, and that was just it. Ruby tries to be mainly object-oriented, but borrow a little bit of functional programming and a little bit of imperative programming, and be able to do all of that. Rails tries to do the same thing. We're not just going to pick one paradigm and run it through everything. Object orientation is at the center of it, but it's okay to invite all these other disciplines in. It's okay to be inspired. It's okay to remix it.

I actually think one of the main benefits of Rails is that it's a remix. I didn't invent all these ideas. I didn't come up with Active Record. I didn't come up with the MVC way of dividing an application. I took all the great ideas that I had learned and picked up from every different camp, and I put them together—not because there was going to be just one single overarching theory of everything, but because I was going to have a cohesive unit that incorporated the best from everywhere.

Lex Fridman

Is that idea a bit in tension with the beauty of the monolith system? I think the monolith can be thought of as quite roomy, quite a big tent. The monolith needs actually to borrow a little bit of functional programming for the kinds of problems that that discipline excels at solving, or that paradigm excels at solving, if you also want object orientation as its core. I actually think when I've looked at functional programming languages, there's a lot to love. Then I see some of the crazy contortions they have to go through when part of the problem they're solving calls for mutating something, and you go, “Holy shit, this is a great paradigm for 90% of the problem.” And then you're twisting yourself completely out of shape when you try to solve the last 10%.

Oh, excellent. “Beautiful code” is the next one.

David Heinemeier Hansson

We've talked about that at length. Here's a great example that really summarizes the domain-specific language quality of Ruby and Rails: You can make code actually pleasant to write and read, which is really funny to me because, as we talked about, when I started learning programming, it wasn't even a consideration. I didn't even know that could be part of the premise, that it could be part of the solution—that writing code could feel as good as writing a poem.

Class Project < ApplicationRecord. Belongs to account. Has many participants. Class Person < ApplicationRecord. Validates presence of name.

Lex Fridman

See, you could read it out. You didn't even change anything.

David Heinemeier Hansson

It's a haiku or something.

Lex Fridman

Right? Isn't that beautiful?

David Heinemeier Hansson

Yeah, it's nice. It's really nice. There's an intuitive nature to it.

Lex Fridman

Okay. So, I have specific questions there. Active Record, just to take that tangent, has to be your favorite feature.

David Heinemeier Hansson

It's the crown jewel of Rails. It really is. It is the defining characteristic of how to work with Ruby and Rails.

And it's born in an interesting level of controversy because it actually uses a pattern that had been described by Martin Fowler in Patterns of Enterprise Application Architecture, one of the greatest books for anyone working on business systems. If you have not read it, you must pick it up immediately. Patterns of Enterprise Application Architecture—I think it was published in 2001. It is one of the very few programming books that I have read many times over. It's incredible. In it, Martin describes a bunch of different patterns for how to build business systems, essentially. Active Record is a little bit of a footnote in there. The pattern is literally called Active Record. You can look it up. It's called Active Record. I wasn't even creative enough to come up with a name of my own, but it allows the creation—the marriage—of database and object orientation in a way that a lot of programmers find a little off-putting.

They don't actually want to pollute the beautiful object-oriented nature of that kind of programming with SQL. There was a rant by Uncle Bob the other day about how SQL is the worst thing ever. Blah, blah. Okay, fine. Whatever. I don't care. This is practical.

We are making CRUD applications. You're taking things out of an HTML form and sticking them into a damn database. It's not more complicated than that. The more abstractions you put in between those two ends of the spectrum, the more you're just fooling yourself. This is what we're doing. We're talking to SQL databases.

By the way, a quick aside: SQL was one of those things that endured the onslaught of NoSQL databases and unstructured data for the better part of a decade, and still reigns supreme. SQL was a good thing to invest your time in learning. Every programmer working with the web should know SQL to a fair degree. Even if they're working with an ORM, an object-relational mapper such as Active Record, you still need to understand SQL.

What Active Record does is not so much try to abstract the SQL away behind a different kind of paradigm as just make it less cumbersome to write. It makes it more amenable to building domain models on top of other domain models, in a way that means you don't have to write every damn SQL statement by hand.

We just say that Active Record is an ORM, which is a layer that makes it intuitive and humanly interpretable to communicate with a database. Even simpler than that, it turns tables into classes and rows into objects. I actually think SQL is very easy to understand. Most of it, you can write some SQL golf, too. That's very hard to understand.

But SQL, at its base, was written for human consumption. It's actually quite verbose, especially if you're doing things like inserts over and over again. It's quite verbose: “Insert into table,” enumerate every column; you want to insert values, parentheses, every value that fits with that column. It gets tedious to write SQL by hand, but it's actually very humanly readable.

Active Record just takes that tediousness away. It makes it possible to combine things in a way that a humanly describable language just doesn't. It composes things into methods, and you can combine these methods and build structures around them.

So, I don't dislike SQL. I dislike a lot of things in programming. I try to get rid of them. SQL wasn't really one of them. It was just a sense of, “I don't want to write the same thing over and over again.” It was, “Can we be a little more succinct? Can we match it just slightly better to the object orientation without trying to hide away the fact that we're persisting these objects into a database?”

That's where I think a lot of ORM went wrong. They tried to live in the pure world of objects, never considering that those objects had to be persisted into a SQL database. Then they came up with convoluted ways of translating back and forth. Active Record says, “You know what? Just accept it. This record, this object, is not going to get saved into some NoSQL database. It's going to be saved into a SQL database. So just structure the whole thing around that.”

It's going to have attributes. Those attributes are going to correspond to columns in the database. It's not more complicated than that. Stop making it so.

Lex Fridman

Yeah, but I should say, I personally love SQL because I'm an algorithms person, and so I love optimization. I love to know how the databases actually work so I can match the SQL queries and the design of the tables such that I can squeeze the optimal performance out of the table, based on the actual way that table is used. I think that pushes to the point that there is value in learning and understanding SQL.

I wonder, because I started looking at Active Record and it looks really awesome: Does that make you lazy? Not you, but a person who rolls in and starts using Rails—you can probably get away with never really learning SQL, right?

David Heinemeier Hansson

As long as you want to stay at the entry level of competence. This is actually my overarching mission with Rails: to lower the barrier of entry so far down that someone can start seeing stuff in the browser without basically understanding anything.

They can run Rails new blog, run a couple of generators, and have a whole system. They don't understand anything, but it's an invitation to learn more. Where I get fired up, and this ties back to the AI discussion, is when that's turned into this meme that programmers no longer have to be competent. They can just—I mean, the AI is going to figure it out.

The generators are going to figure it out. I don't need to know SQL. Active Record is going to abstract it away from me. No, no, no, dude. Hold up. The path here is competence. I'm trying to teach you things. I understand I can't teach you everything in 5 minutes. No one who's ever become good at anything worthwhile could be taught everything in 5 minutes.

If you want to be a fully well-rounded web application developer, that takes years, but you can actually become somewhat productive in a few days. You can have fun in a few days, for sure. You can have fun in a few minutes and a few hours. And over time, I can teach you a little more. Active Record says, “Yeah, yeah, all right. Start here, and then next week we'll do a class on SQL.” You have this beautiful expression that I love: a great programming language like Ruby has a soft ramp; the ramp goes to infinity.

Lex Fridman

That's exactly right.

David Heinemeier Hansson

So yeah, it's super accessible, super easy to get started.

Lex Fridman

And it never stops.

David Heinemeier Hansson

Yeah, it never stops. There's always more to learn. This is one of the reasons I'm still having fun programming, that I'm still learning new things. I can still incorporate new things. The web is deep enough as a domain. You're never going to learn all of it.

Lex Fridman

“Provide sharp knives.” This is a good one, because another way of saying this—the opposite way of saying it, the Java way—is, “Do not provide foot guns,” right? I don't want to give you sharp knives. You're a child. You can't handle a sharp knife. Here's a dull butter knife. Cut your damn steak, right? That's a very frustrating experience.

You want a sharp knife, even though you might be able to cut yourself. I trust humans in the same way that Matz trusts humans. Maybe you cut off a finger. All right, you're not going to do that again. Thankfully, it was a virtual finger. It's going to grow back. Your competence is going to grow. It's more fun to work with sharp tools.

David Heinemeier Hansson

And that actually contributes to the ramp that goes to infinity.

Lex Fridman

To the learning value. Integrated systems.

David Heinemeier Hansson

We kind of hit on that one. Rails is trying to solve the whole problem of the web, not just one little component. It's not leaving you a bunch of pieces you have to put together yourself.

Lex Fridman

Progress over stability.

David Heinemeier Hansson

You know what? If there's one that's dated, it's probably that one. At this stage, Rails has been incredibly stable over many, many generations. The last major release, Rails 8, was basically a no-op upgrade for anyone running Rails 7. Rails 7 was almost a no-op upgrade for anyone running Rails 6.

I used to think it required more churn to get progress, to stay on the leading edge of new stuff. And I wrote this before I experienced the indignity of the 2010s in the JavaScript community, where it seemed like stability was not just unvalued; it was actually despised. That churn in and of itself was a value we should be pursuing—that if you were still working with the same framework 3 months later, you were an idiot.

I saw that and actually recoiled. If I was going to write the doctrine today, I'd write that differently. I wouldn't say “progress over stability.”

Lex Fridman

Well, maybe that'd be a function of the age of the programming language also.

David Heinemeier Hansson

Maybe, or a deeper understanding of the problem.

Lex Fridman

I think part of what's so fascinating about technology is that we have this perception that everything constantly moves so fast. No, it doesn't. Everything moves at a glacial pace. There is occasionally a paradigm shift, like what's happening with AI right now, like what happened with the introduction of the iPhone in 2007, like what happened with the internet in 1995. That's basically the total sum of my career: 3 things changed everything. Everything else in between was incremental, small improvements.

You can recognize a Rails application written in 2003. I know, because the Basecamp I wrote back then is still operating, making millions of dollars in ARR, serving customers on the initial version that was launched back then. It looks like the Rails code, if I squint a little, that I would write today.

So most things don't change, even in computing, and that's actually a good thing. We saw with the JavaScript ecosystem what happens when everyone gets just mad about constant churn. Things don't change that often.

By the way, on that small tangent, you just sort of visibly, verbally changed your mind with the you of 15 years ago.

David Heinemeier Hansson

Yes.

Lex Fridman

That's interesting. Have you noticed yourself changing your mind quite a bit over the years?

David Heinemeier Hansson

I would say, “Oh, yes,” and then also, “Oh, no,” in the sense that there are absolutely fundamental things—both about human nature, about institutions, about programming, about business—that I've changed my mind on.

And then I've also had experiences that are almost even more interesting, where I thought I had changed my mind, tried it a new way, realized why I had the original opinion in the first place, and then gone back to it. So it happens both ways.

An example of the latter part, for example, was managers at 37signals. For the longest time, I would rail against engineering managers as an unnecessary burden on a small or even medium-sized company. And at one point, I actually started doubting myself a little bit. I started thinking, “You know what? Maybe all programmers do need a one-on-one therapy session every week with their engineering manager to be a whole individual.”

So, we tried that for a couple of years, where we hired some very good engineering managers who did engineering management the way you're supposed to do it, the way it's done all over the place. And after that, I thought, “No, no, I was right. This was correct. We should not have had managers.”

Not every programmer needs a therapy session with an engineering manager every week. We don't need these endlessly scheduled huddles. We don't need all these meetings. We just need to leave people the hell alone to work on problems that they enjoy for long stretches of uninterrupted time. That is where happiness is found. That's where productivity is found. And if you can get away with it, you absolutely should. Engineering management is a necessary evil when that breaks down.

Lex Fridman

What's the case for managers, then?

David Heinemeier Hansson

The case for managers is that if you do have a lot of people, there's a bunch of work that kind of just crops up. The one-on-one is one example: programmers need someone to check in with. There's another idealized version, that someone needs to guide the careers of juniors, for example, to give them redirecting feedback and all this other stuff.

And it's not that, in the abstract, I don't agree with some of those things, but in practice I've found that they often create more problems than they solve. And a good example here is: can you get feedback from someone who's not better at your job than you are?

You can get some feedback. You can get feedback on how you show up at work. Are you being courteous to others? Are you being a good communicator? Okay, yes. But you can't get feedback on your work. And that's more important. It's more important that you work under and with someone who's better at your job than you are if you wish to progress in your career.

Every single programmer I've ever worked with was far more interested in progressing in their career on that metric—getting better at their craft—than they were in picking up pointers that a middle manager could teach them.

That's not saying that there isn't value in it. It's not saying there isn't value in being a better person or a better communicator. Of course, there is, all those things. But if I have to choose one or the other, I value competence higher.

Right? Again, I caveat this a million times because I know what people sometimes hear. They hear, “The genius asshole is just fine, and that's great, and you should excuse all sorts of malicious behavior because someone is just really good at what they do.” I'm not saying that at all.

What I am saying is that the history of competence is a history of learning from people who are better than you. And that relationship should take precedence over all else. And that relationship gets put aside a bit when engineering managers are introduced.

Now, the funny thing is this conversation ties back to the earlier things we were talking about. Most engineering managers are actually former programmers. They at least know programming to some extent. But what I've seen time and again is that they lose their touch, their feel with it, very, very quickly and turn into pointy-haired bosses very, very quickly, who are really good at checking for updates, just seeing where we are on project A, whether you need anything, or whether we're ready to deliver.

Okay, yes—and also no. Just shut up. Leave me the hell alone. Let me program, and then I'll come up for air. I'll talk with other programmers who I can spar with, who I can learn something with, who I can turn the problems over with, and we can move forward.

If you look back on the history of the computer industry, all the great innovation that's happened, it's all been done by tiny teams with no engineering managers, just full of highly skilled individuals. You've had John Carmack on here. I used to look up to id Software so much, not just because I loved Quake, not just because I loved what they were doing, but because he shared a bit about how the company worked.

There were no managers, or maybe they had one business guy doing some business stuff, but that was just to get paid. Everything else was basically just designers and programmers, and there were about 8 of them, and they created a goddamn Quake 2. So why do you need all these people again? Why do you need all these managers again?

I think, again, at a certain scale, it does break down. It's hard to just have 100,000 programmers running around wild without any product mommies or daddies telling them what to do. I understand that. And then, even as I say that, I also don't understand it, because if you look at something like Gmail, for example, there was a side project done by Paul Buchheit at Google at the time.

So much of the enduring, long-term value of even all these huge companies was created by people who didn't have a goddamn manager. And that's not an accident. That's a direct cause and effect.

So I've turned, in some way, even more militant over the years against this notion of management, at least for myself and knowing who I am and how I want to work, because the other part of this is I don't want to be a manager. Maybe this is just me projecting the fact that I'm an introvert who doesn't like to talk to people in one-on-one calls every week. But it also encapsulates how I was able to progress my career. I did not really go to the next level with Ruby or otherwise until I had a door I could close and no one could bother me for 6 hours straight.

So, in companies, probably one of the reasons is it's very easy to hire managers. Managers also delegate responsibility from you. If you just have a bunch of programmers running around, you're kind of responsible. It's work. It's intellectual work to have to deal with the first principles of every problem that's going on.

Lex Fridman

So managers, like—

Jason Fried

You can relax. You can be like, “Oh, it'll be taken care of.” But then they hire their own managers, and it just multiplies and multiplies and multiplies.

I've essentially run that branch at 37signals for 20 years, and I've experimented with forking back on the other side. I've experimented with having a full-time lawyer on staff. I've experimented with having engineering managers. And I can tell you, life is much better at 50–60 people when none of those individuals—or none of those roles—are in your organization full-time.

It's never about the individuals. It's about the roles. None of those roles are in your organization full-time. Occasionally, you need a manager. Occasionally, you need a lawyer. I can play the role of manager occasionally, fine, and then I can set it back down to zero. It's almost like a cloud service. I want a manager service I can call on for 7 hours this week, and then I want to take it down to zero for the next 3 months.

Lex Fridman

Yeah, I read—I don't know if this is still the case—that Basecamp is an LLC and doesn't have a CFO, like a full-time accountant. Is that the case?

David Heinemeier Hansson

What's funny is these days we do have a head of finance. We did not for the first 19 years of our life, I think. We got away with basically just having an accountant do our books in the same way you do a small ice cream shop, except over time we would have done hundreds of millions of dollars in revenue.

The scale seemed quirky, and at some point you can also fall in love with your own quirkiness to a degree that isn't actually healthy. I've certainly done that over time. We should have had someone count the beans a little more diligently, a little earlier, which was part of the blessing of just being wildly profitable and selling software that can have infinite margins. Basically, you can get away with a bunch of stuff that you perhaps shouldn't.

What partially taught me this lesson was when we realized we had not been collecting sales tax in different U.S. states where we had nexus. It took us about 2 years and $5 million in settlements and cleanups to get out of that mess. After that, I went, “Okay, fine. We can hire a finance person.”

Lex Fridman

Okay.

David Heinemeier Hansson

And we now have a wonderful finance person, Ron, who actually ended up replacing something else we used to have. We used to have a full-time data analytics person who would do all sorts of insight mining for why people are signing up for this thing. We ran that for 10 years and realized, “You know what? If I can have either a data analytics person or an accountant, I'm picking the accountant.”

Lex Fridman

I love this so much on so many levels. Can we just linger on that advice that you've given, that small teams are better? I think that's really—less is more. What did you say before? “Worse is better.”

David Heinemeier Hansson

Okay, I'm sorry.

Lex Fridman

Worse is better on adoption with technology a lot of times. Yeah.

David Heinemeier Hansson

And I think it actually comes out of the same thing. It comes out of the fact that many of the great breakthroughs are created by not even just tiny teams but individuals. Individuals writing something—and an individual writing something, in some parameters, what they do is worse.

Of course, it's worse when one person has to make something that a huge company has hundreds, if not thousands, of developers working on. But in so many other parameters, that worseness is the value. That less is the value.

In Getting Real, which we wrote back in 2006, we talk about this notion of less software. When we first got started with Basecamp back in 2004, people would ask us all the time, “Aren't you petrified of Microsoft? They have so many more resources. They have so many more programmers. What if they take a liking to your little niche here and they show up and just throw 1,000 programmers at the problem?”

And my answer, perhaps partly because I was 24, was, first of all, “No, no care in the world.” But the real answer was, they're not going to produce the same thing. You cannot produce the kind of software that Basecamp is with a team of 1,000 people. You will build the kind of software that 1,000 people build, and that's not the same thing at all.

So much of the main breakthroughs in both end-user systems and open-source systems, in fundamental systems, are done by individuals or very small teams. Even all these classical histories of Apple have always been like, “Well, it was a big organization, but then you had the team that was actually working on the breakthrough. It was 4 people. It was 8 people. It was never 200.”

Lex Fridman

And a large team seems to slow things down.

David Heinemeier Hansson

Yes.

Lex Fridman

It's such a fascinating thing, and part of it is the manager thing.

David Heinemeier Hansson

Because humans don't scale. Communication between humans certainly doesn't scale. You basically get the network cost effect. Every time you add a new node, it goes up exponentially. This is perhaps the key thing of why I get to be so fond of having no managers at Basecamp, because our default team size is 2.

One programmer, one designer, one feature. When you're operating at that level of scale, you don't need sophistication. You don't need advanced methodologies. You don't need multiple layers of management because you can just do. The magic of small teams is that they just do. They don't have to argue because we don't have to set direction. We don't have to worry about the roadmap. We can just sit down and make something and then see if it's good.

When you can get away with just making things, you don't have to plan. And if you can get out of planning, you can follow the truth that emerges from the code, from the product, from the thing you're working on in the moment. You know far more about what the great next step is when you're 1 step behind rather than if you try 18 months in advance to map out all the steps.

How do we get from here to very far away? You know what? That's difficult to imagine in advance because humans are very poor at that. Maybe AI one day will be much better than us. But humans can put 1 foot in front of the other. That's not that hard.

And that allows you to get away without all that sophistication. So the process just becomes much simpler. You need far fewer people. It compounds. You need much less process. You need to waste less time in meetings. You can just spend these long, glorious days and weeks of uninterrupted time solving real problems you care about and that are valuable.

And you're going to find that that's what the market actually wants. No one is buying something because there's a huge company behind it. Most of the time, they're buying something because it's good. And the way you get something good is you don't sit around and have a meeting about it. You try stuff. You build stuff.

Lex Fridman

It really is kind of incredible what 1 person—honestly, 1 person—can do in 100 hours of deep work, of focused work, even less.

David Heinemeier Hansson

So, I'll tell you this. I tracked exactly the number of hours I spent on the first version of Basecamp. I was doing this because at the time I was working on a contract basis for Jason. He was paying me—I was going to say $15 an hour. That's what I got paid when we first got started. I think he had bumped my pay to a glorious $25.

But I was billing him, and I know that the invoice for the first version of Basecamp was 400 hours. That's what it took for 1 individual in 2004 to create an entire system that has then gone on to gross hundreds of millions of dollars and continues to do extremely well. One person, just me, setting up everything.

Part of that story is Ruby, part of that story is Rails, but a lot of it is also just me plus Jason plus Ryan plus Matt. That was the entire company at the time. And we could create something of sheer, sustaining value with such a tiny team because we were a tiny team.

Small is not a stepping stone. This is the other thing that people get into their heads. This is one of the big topics of Rework, that it gave entrepreneurs permission to embrace being a small team—not as a waypoint, not as, like, “I'm trying to become 1,000 people.” No, I actually like being a small team. Small teams are more fun.

If you ask almost anyone—

Lex Fridman

I'm sure Tobi would say this too, even at his scale. The sheer enjoyment of building something is in the enjoyment of building it with a tiny team. Now, you can have impact at a different scale when you have a huge company. I fully recognize that, and I see the appeal of it.

David Heinemeier Hansson

But in the actual building of things, it's always small teams. Always.

Lex Fridman

How do you protect a small team? Basecamp has successfully stayed small. What has been the dragon you had to fight off? Basically, you make a lot of money, and there's a temptation to grow. So how do you not grow?

David Heinemeier Hansson

Don't take venture capital.

Lex Fridman

Okay, that's step one.

David Heinemeier Hansson

Point number one.

Lex Fridman

First of all, everybody takes venture capital. So you already went.

David Heinemeier Hansson

I mean, that's been the answer for the longest time, because the problem isn't just venture capital. It's other people's money. Once you take other people's money, completely understandably, they want a return, and they would prefer to have the largest return possible because it's not them sitting in the code. It's not them getting the daily satisfaction out of building something, chiseling beautiful code poems out of the editor, right? They don't get that satisfaction.

They get the satisfaction, maybe, of seeing something nice put into the world. That's fair. But they certainly also get the satisfaction of a higher return. And there is this sense, certainly stated in venture capital, that the whole point of you taking the money is to get to a billion dollars or more.

Now, the path to that usually does go through running established playbooks. When it comes to software, the enterprise sales playbook is that playbook. If you're doing B2B software, SaaS, you will try to find product-market fit, and the second you have it, you will abandon your small and medium-sized accounts to chase the big whales with a huge sales force. By then, you're a thousand people, and life sucks.

Lex Fridman

That said, people are just curious about this. I've gotten a chance to get to know Jeff Bezos. He invested in Basecamp, non-controlling. He bought secondaries.

This is the funny thing: investing has these two dual meanings. Normally, when people think about investing, they think you're putting in growth capital because you want the business to hire more people to do more R&D so they can grow bigger. Bezos didn't do that, actually. He bought an ownership stake directly from Jason and me, and 100% of the proceeds of that purchase went into Jason's and my personal bank accounts. Not a single cent went into the account of the company because we didn't need the money to grow.

What we needed, or what we certainly enjoyed, was, to some extent, maybe the vote of confidence, but more so the security of taking a little bit off the table. We dared to turn down the big bucks from venture capitalists. It was essentially a vaccine against wanting to take a larger check from people who then wanted to take the company to something enormous that we didn't want to go with it.

So Jeff gave Jason and me just enough money that we were comfortable turning all those people down in a way where, if it had turned belly-up 6 months later, we wouldn't have been kicking ourselves and calling, “We had something here that was worth millions, and now we have nothing, and I have to worry about rent and groceries again.”

It is a vote of confidence. I'd love to hear Jeff's side of the story. He doesn't need the money, so it's really, I think, just believing in people and wanting to have cool stuff be created in the world and make money off of it, but not—

David Heinemeier Hansson

100%. The motivation for Jeff wasn't a return, because he actually has a team—his private office—that runs these investments. They did the calculus on the investment pitch we gave him, which was so ridiculous that Jason and I were laughing our asses off when we were writing down our metrics.

I was like, “No one's going to pay this. No one is going to give us this multiple of this amount of revenue.” And that's fine. We took the call essentially out of a kind of awe that Jeff Bezos even wanted to look at us. We thought, “You know what? We don't want venture capital. We don't need other people's money, but let's just give him a bullshit number that no sane person would actually say yes to. Then we can each go our own way.”

His investment team said, “Jeff, no way. This makes no economic sense at all. They're asking for way too much money with way too little revenue.” And Jeff just went, “I don't care. I want to invest in these guys.”

Because to him, at the time, it was chump change, right? Jason and I each got a few million dollars. Whatever the currency swing between the yen and the dollar was that day probably moved 10 times that in his net worth than our investment did.

Jeff seemed genuinely interested in being around interesting people and interesting companies, helping someone go the distance. And I actually look back on that relationship with some degree of regret, because I took that vote of confidence for granted in ways that I'm a little bit ashamed of over the years. I've been more critical about some of the things that Amazon had done that I feel now are somewhat justified. So that's just part of processing it.

But in an economic sense, he gave us that confidence. He gave us the economic confidence, but then he also gave us the confidence of a CEO running, perhaps at the time, the most important internet business in the U.S., showing up to our calls, which we would have with him once a year, and basically just going, “Yeah, you guys are doing awesome stuff. You should just keep doing awesome stuff. I read your book. It's awesome. You launched this thing. It's awesome. You should just do more of that. I don't actually know how to run your business. You guys know.”

Lex Fridman

So the big question is—from a fan perspective, I'm curious about how Jeff Bezos was able to see that. To me, you and Jason are special humans in the space of tech, and the fact that Jeff was able to see that, right? How hard is it to see that?

David Heinemeier Hansson

He certainly saw it very early, and I think this is something that Jeff does better than almost anyone else. He spots that opportunity so far in advance of anyone else even opening their eyes to it, or certainly he's willing to bet on it far earlier and far harder than anyone else is. He's just right time and again.

We were not the only investment that he made, and certainly Amazon had an extremely long-term vision, far longer than I have ever had the gumption to keep. I think of myself as a long-term thinker. I'm playing a child's game compared to the game that Jeff is playing.

When I looked at Amazon's economics around the dot-com boom and bust, they looked ridiculous. They were losing so much money. They were so hated by the market. No one believed that it was going to turn into what it is. But Jeff did, in a way that I really aspire to.

I think that's one of the main things I've taken away from that relationship: you can just believe in yourself to that degree against those odds. That's ridiculous. He did that at so many times our level that it's pathetic if I'm doubting myself.

Lex Fridman

Yeah, I think Amazon is one of those companies. I mean, it's come under a bunch of criticism over the years. This is something about humans: they don't appreciate so much that we take for granted the positive that a thing brings real quick, and then we just start criticizing the thing. It's with Wi-Fi and airplanes.

David Heinemeier Hansson

That's exactly it.

Lex Fridman

But I think there could be a case made that Amazon is one of the greatest companies in the last 100 years.

David Heinemeier Hansson

For sure. I think it's an easy case to make. What I also think is that the price you pay to be one of the greatest companies in the last 100 years is a lot of detractors, a lot of pushback, and a lot of criticism. This is actually order restored in the universe.

One of my favorite teachers in all the time I've been on the internet is Kathy Sierra. I don't know if you know her work, but she was around for only a few short years before the cruel internet ran her off. She wrote a blog called Creating Passionate Users, and she carved into my brain this notion of balance in the universe.

If you're creating something of value that a lot of people love, you must create an equal and opposite force of haters. You cannot have people who love what you do without also having people who hate what you do. The only escape from that is mediocrity.

If you are so boring and so uninteresting that no one gives a damn whether you exist or not, yeah, you don't get the haters, but you also don't get the impact of people who really enjoy your work. And I think Amazon is that, just at a massive scale. They've brought so much value and change to technology and commerce that they must simply have a black-hole-sized group of haters. Otherwise, the universe is simply going to tip over.

Lex Fridman

Let me ask you about small teams. You mentioned Jason a bunch of times. Jason Fried—you have been partners for a long, long time. Perhaps it's fair to say he's more on the design-business side, while you're the tech and engineering wizard. How have you guys, over all these years of creating so many amazing products, not murdered each other?

It's a great story of partnership. What can you say about collaboration? What can you say about Jason that you love, that you've learned from? Why does this work?

David Heinemeier Hansson

So first, I'll say we have tried to murder each other several times over the years, but far less, I think, in the last decade. In the early days, our product discussions were so fierce that when we were having them in the office and there were other employees around, some of them were legitimately worried that the company was about to fall apart because the volume coming out of the room would be so high and sound so acrimonious that they were legitimately worried the whole thing was going to fall apart.

But you know what's funny? It never felt like that in the moment.

It always felt like just a peak, vigorous search for something better, and that we were able to stomach that level of adversity on the merits of an idea because it was about the idea. It wasn't about the person. It didn't get personal. It wasn't like, “Jason, you're an asshole.” It was like, “Jason, you're an idiot, and you're an idiot because you're looking at this problem the wrong way, and let me tell you the right way to do it.”

Lex Fridman

As a small tangent, let me say that some people have said—we'll probably return to this—that you sometimes can have flights of temper on the internet and so on. I never take it that way because it is the same kind of ilk. Maybe I haven't seen the right traces of temper, but usually it's about the idea, and it's just excited, passionate, human.

David Heinemeier Hansson

That's exactly what I like to think of it as. It doesn't always come across as that. I can see why spectators in particular sometimes would see something that looks like I'm going after the man rather than the ball. I do think I've tried to get better at that.

But in my relationship with Jason Fried, I think it's worked so well because we have our own distinct areas of competence where we fully trust each other. Jason trusts me to make the correct technical decisions. I trust him to make the correct design and product-direction decisions, and then we can overlap and share on the business, on marketing, on writing, and on other aspects of it.

So that's one thing: if you're starting a business with someone where you do exactly the same as they do and you're constantly contesting who is the more competent person, I think that's far more difficult and far more volatile. If you're starting a business and you're both programmers and you both work on the same kind of programming, good luck. I think that's hard.

I tried to pick an easier path, working with a designer where I knew that at least half of the time I could just delegate to his experience and competence and say, “You know what? I may have an opinion—I have an opinion all the time on design—but I don't have to win the argument because I trust you.”

Now, occasionally, we would have overlaps on business or direction where we'd both feel like we had a strong stake in the game and we both had a claim to competence in that area. But then, for whatever reason, we also both had a long-term vision where I would go, “Do you know what? I think we're wrong here.” But as I learned from Jeff Bezos, by the way, I'm going to disagree and commit.

That was one of those early lessons he gave us that was absolutely crucial, and perhaps even instrumental in ensuring that Jason and I have been working together for a quarter of a century. Disagree and commit is one of the all-time Jeff Bezos greats.

Lex Fridman

I'm just surprised that Yoko Ono hasn't come along. You know what I mean? There's so many Yokos in this world.

David Heinemeier Hansson

It might have happened, if not in part because we don't sit on each other's lap all the time. Most of our careers, we haven't even lived in the same city. I lived in Chicago for a couple of years while we were getting going, after I'd moved to the US in 2005. But then I moved to Malibu, and then I lived in Spain, and then I lived in Copenhagen.

Jason Fried, from the foundation of our relationship, learned how to work together in a remarkably efficient way where we didn't have to actually talk that much on any given week. I'd be surprised if Jason and I spent more than 2 hours of direct exchange and communication.

Lex Fridman

Yeah. Sometimes it's the basic human frictions that just come from being up against another person. That person damn well better be your spouse if it's too much for too long.

David Heinemeier Hansson

Yeah. But even there, COVID has really tested the relationship. It's fascinating to watch.

Lex Fridman

It has.

David Heinemeier Hansson

I do think that having some separation—which is kind of counterintuitive, because I think a lot of people think the more collaboration you can have, the better, and the more ideas they can bounce back and forth, the better—both Jason and I, for whatever reason, came to the conclusion early on in our careers: absolutely not. That's complete baloney.

This is why we were huge proponents of remote work. This is why I enjoy working in my home office, where I can close the door and not see another human for like 6 hours at a time. I don't want to bounce ideas off you all the time. I want to bounce ideas off you occasionally, and then I want to go off and implement those ideas. There's way too much bouncing going on and not enough scoring, not enough dunking.

Lex Fridman

And I think this is one of the great traps of the executive role. Once a founder elevates themselves all the way up to an executive, what they're doing is just telling other people what to do. That's the realm they live in 24/7. They just live in the idea realm: “Oh, I can just tell more people more things what to do, and we can just see it happen.”

If you actually have to be part of implementing that, you slow your roll. You think, “I had a good idea last week. I'm going to save the rest of my good ideas until next month.” There is a temptation for the managers and for the people in the executive layer to do something, which usually means a meeting.

David Heinemeier Hansson

Yes.

Lex Fridman

Right. And so that's why you say—

David Heinemeier Hansson

Their job is telling other people what to do.

Lex Fridman

Yeah. And the meeting—so this is one of the big things you're against—is—

David Heinemeier Hansson

Meetings are toxic.

Lex Fridman

Yeah.

David Heinemeier Hansson

And this really, I think, ties into this with Jason Fried. If I had to count out the total number of meetings we've had in 24 years of collaboration where we, in person, sat in front of each other and discussed a topic, it'd be less than 3 months at a FAANG company.

One of these funny metaphors that Trump came up with at one point was that a human has a limited number of steps in their life, right? That's the longevity argument here. You can do so much activity, and then you run out. There's some kernel in that idea that can be applied to a relationship. There's some amount of exchange we can have. There's some amount of time we can spend together where you can wear it out.

Jason and I were diligent about not wearing each other out, and I think that is absolutely key to the longevity of the relationship, combined with that level of trust and with the fact that we really like the work itself. We don't just like the brainstorming, the sessions where we just come up with good ideas. No, we like to do the ideas, and we like to be part of that process directly ourselves.

I like to program. He likes to do design. We could go off and do our little things for long stretches of time, occasionally come together, and go, “Hey, let's launch a great product.”

This might sound like I'm asking you to do therapy, but I sometimes find myself wanting or longing for a meeting because I'm lonely. With remote work, just sitting by yourself—I don't know—it can get really lonely for long stretches of time.

Lex Fridman

Let me give you a tip.

David Heinemeier Hansson

Uh-huh.

Lex Fridman

Get a wife.

David Heinemeier Hansson

God damn it.

Lex Fridman

Get a couple kids.

David Heinemeier Hansson

All right.

Lex Fridman

Family really is the great antidote to loneliness. I mean that as sincerely as I can possibly say it. I certainly had exactly that feeling you described earlier in my career when I was working remotely.

I was just living in an apartment, a total stereotype, where for the longest time when I first moved to Chicago, all I had on the floor was a mattress. Then I bought this big TV and I didn't even mount it. Then I had a stack of DVDs, and I was working a lot of the time, and then I would just go home and I'd do that. It wasn't great. It really wasn't. I do think that humans need humans.

David Heinemeier Hansson

And if you can't get them at work—and I actually sort of don't want them at work, at least. I don't want them for 40 hours a week. That's not what I prefer—you need something else. You need other relationships in your life.

There is no greater depth of relationship if you can find someone that you actually just want to spend a lot of time with. That's key to it. I think it's key for both Jason and me that we've had families for quite a long time. It grounds you, too, in a way where the sprint of a startup can get traded in for the marathon of an enduring company, and you get settled in a way.

We talked briefly about sometimes I get fired up. A lot of times, maybe even most of the time, I get fired up about topics, but I don't get fired up in the same way now as I used to when I was 24. I'm still extremely passionate about ideas and trying to find the right things, but having a family, meeting my wife, and building a life around that has just mellowed everything out in a completely cliché way. I think it's actually key.

I think if we could get even more young people not to wait until they were in their late goddamn 30s or early 40s to hitch up with someone, we'd be better off, and we'd have more stable business relationships as well because folks would get that nurturing human relationship somewhere else.

Now, when I say all of that, I also accept that there are plenty of great businesses that have been built over the years that have not been built remotely, that have been built by a gang of hooligans sitting in an office for immense hours of time.

Both John Carmack and Tim Sweeney talked about that in the '90s with their careers: it was basically work, sleep, and hang out with the guys at the office, right? Totally fair. That never appealed to me.

Both Jason and I saw eye to eye on the idea that 40 hours a week dedicated to work was enough. If we were going to go the distance, not just for the 5–7 years it takes to build a VC case up to an exit, but for potentially 10 years, 20 years, or further.

We needed to become whole humans, because only that wholeness was going to go the distance. That included building up friendships outside of work, having hobbies, finding a mate, and having a family. That entire existence—the legs of the stool, where work is not the only thing in life—is completely related to the fact that we've been around for 25 years.

There's way too much, especially in America, of false trade-offs. “Oh, you want to build a successful business? Well, you can either have money, enjoyment, family, or health. Pick one.” What? Why do we have to give up all of this?

Now, again, I'm not saying that there aren't periods in life where you can sprint, but I am saying if that sprint turns into a decade, you're going to pay for it. And you're going to pay for it in ways I've seen time and again. It seems like a very bad trade, even if it works—and, by the way, most of the time it does not.

Most of the time, startups go bust. Most of the time, people spend 5 or 7 years on something that does not pan out, and they don't get the payout. Then they just sit with regret, like, “What the fuck happened to my 20s?”

Early on, Jason and I basically made a pact that working together was not going to lead to that kind of regret. We were going to allow ourselves and each other to build a whole life outside of work. And the fact that that worked is something I feel is almost like forbidden knowledge.

Certainly in technology circles in the US, it's something that we've tried to champion for 20 years, and we still get flak for it. Just 2 days ago, I had another Twitter beef with someone saying, “Oh, well, okay, maybe it worked, but you didn't turn into Atlassian, so you're a failure. Basecamp isn't Jira, so why are you even bothering?”

It's such a fascinating winner-takes-all mentality that unless you dominate everyone else in all the ways, you've lost, when so much of life is far more open to multiple winners. We can end up with a business that has made hundreds of millions of dollars over the years, and we've kept much of that to do whatever we want. That's enough. That's good. That's great. That's actually something worth aspiring to.

Certainly, it should be a path for someone to consider choosing, rather than the VC unicorn-and-bust mentality that dominates everything.

Lex Fridman

Yeah. I'd love to ask you about this exchange so you can explain the whole saga. But just to build on that a little bit, I think there's a notion that success for a tech founder is to work for a few years all-out and then exit—sell your company for, I don't know, hundreds of millions of dollars. That's success.

When you look at people like you—really smart, creative humans—who they actually are and what happiness entails, it actually entails working your whole life a little bit. You love programming, you love building, you love designing, and you don't want to exit. That's something you've talked about really eloquently.

You actually want to create a life where you're always doing the building, and doing it in a way that's not completely taking over your life.

David Heinemeier Hansson

Mojito Island is a mirage. It always was. There is no retirement for ambitious people. There is no just sitting back on the beach and sipping a mojito for what? For 2 weeks before you go damn crazy and want to get back into the action.

That's exactly what happens to most people who have the capacity to build those kinds of exits. I've never seen—I shouldn't say never. I've almost never seen anyone be able to pull that off. Yet so many think that that's why they're doing it. That's why they're sacrificing everything: because once I get to the finish line, I'm golden. I've won. I can retire. I can sit back. I can just relax.

And you find out that that kind of relaxation is actually hell.

Lex Fridman

Yeah.

David Heinemeier Hansson

It's hell for creative people to squander their God-given creative juices and capacities. I was really lucky to read the book Flow by Mihaly Csikszentmihalyi early on.

Lex Fridman

Nice—the pronunciation.

David Heinemeier Hansson

You know what? I had to practice that with AI over the last few days because I knew I was going to cite him, and I butchered his name several times. So AI taught me how to pronounce that at least somewhat correctly.

His main work over his career was essentially the concept of flow that came out of a search for understanding happiness. Why are some people happy? When are they happy? And what he learned was quite illuminating.

He learned that people aren't happy when they sit on Mojito Island. They're not happy when they're free of all obligations and responsibilities. No, they're happy in those moments where they're reaching and stretching their capacities just beyond what they can currently do.

In those moments of flow, they can forget time and space. They can sit in front of the keyboard, program a hard problem, think 20 minutes have passed, and suddenly it's been 3 hours. They look back upon those moments with the greatest amount of joy. And that is what peak happiness is.

If you take away the pursuit of those kinds of problems, if you eliminate all the problems from your plate, you're going to get depressed. You're not going to have a good time. Now, there are people who can do that, but they're not the same kind of people who built these kinds of companies.

So you have to accept the kind of individual you are. If you are on this path, don't bullshit yourself. Don't bullshit yourself into thinking, “I'm just going to sacrifice everything—my health, my family, my hobbies, my friends—but in 10 years I'm going to make it all up, because in 10 years I can do it.”

It never works out like that. It doesn't work out on either end of it. It does not work out if you're successful and you sell your company, because you'll get bored out of your mind after 2 weeks of retirement. It doesn't work out if the company is a failure and you regret the last 10 years spent for nothing. It doesn't work out if it all works and you stay in the business, because it never gets any easier.

So you're going to fail on all metrics if you just go, “There's only work and nothing else.” I didn't want that. I wanted the happiness of flow. I understood that insight was true, but I wanted to do it in a way where I could sustain the journey for 40 or 50 years.

Lex Fridman

There's another interesting caveat that I've heard you say: if you do exit, sell your company, and you want to stay in—you want to do another company—that's usually not going to be as fulfilling.

David Heinemeier Hansson

Yes, because really, your first baby—you can't do it again, or most people can't do it again.

A, your second idea is not going to be as good as the first one. It is so rare to capture lightning in a bottle, like we have, for example, with Basecamp. I know this from experience because I've been trying to build a lot of other businesses since, and some of them have been moderate successes, even good successes. None of them have been Basecamp. It's really difficult to do that twice.

But founders are arrogant pricks, including myself, and we like to think, “You know what? We succeeded in large part because we're just awesome. We're just so much better than everyone else.” In some ways, that's true some of the time. But you can also be really good at something that matters for a hot moment. That door is open, and then the door closes. Now you're still good at the thing, but it doesn't matter. No one cares.

There's that part of it. And then there's the part of it that going back to experiencing things for the first time only happens the first time. You can't do it again. I don't know if I have it in me to go through the bullshit of the early days again. And I say “bullshit” in the most endearing sense. It's all great to do it. I know too much.

This is one of the reasons why, whenever I'm asked the question, “If you could tell your younger self something, what would you say to your younger self?” I would fucking not say a thing. I would not rob my younger self of all the life experiences that I've been blessed with due to the ignorance of how the world works.

Building up the wisdom about how the world works is a joy. You've got to build it one brick at a time. If you just handed over all the results, it's like, “Oh, should we watch your movie? Here's how it ends.” I don't want to fucking watch the movie now. You spoiled it. I don't want you to spoil my business experience. I don't want you to spoil any of my ignorance.

The greatest blessing, half the time when you're starting something new, is, A, you don't know how hard it's going to be, and B, you don't know what you don't know. The adventure is the payoff. The responsibility is the payoff.

This is something Jordan Peterson has really taught me to articulate: this notion that responsibility is actually key to meaning. Man's Search for Meaning—Viktor Frankl talks about this as well—that we can endure any hardship if there is a reason why.

He talked about it in truly life-altering concentration-camp ways, but you can also apply it at a smaller scale, with less criticality, even to your daily life. All that hardship in building the original business—that is responsibility you take upon yourself. The appeal, the reason you take that on, is in part because you don't know fully what it entails.

If you had known up front—if I'd known up front—how hard it would be, how much frustration there'd be along the way, if you told me that in a narrative before I got started, I would have been like, “Ah, maybe I should just go get a job.”

Lex Fridman

You said so many smart things there. Just to pick one, it's funny that sometimes the advice-givers, the wisdom-givers, have gone through all the bullshit. And so there is a degree to which you want to make the mistake.

I think I would still give the advice: you want to have a stretch of your life where you work too hard, including at a thing that fails.

David Heinemeier Hansson

I don't think you can learn the lesson of why that's a bad idea in any other way except by doing it.

Lex Fridman

I think you should stretch. Should you have to stretch for a decade? I'm not so sure.

David Heinemeier Hansson

Yeah. The decade thing is that your 20s are a special time. It's a lot to trade. You don't get your 20s back. You don't get your 30s back. You don't get your 40s back.

I really would have regretted it personally if I hadn't done the other things I did in my 20s—if I hadn't had the fun I had, if I hadn't had the friends I had, if I hadn't built up the hobbies that I did, if I hadn't started driving race cars at an early enough age to actually get really good at it. If I had just gone all in on business, I would have gotten the same outcome in the end.

This is something Derek Sivers really taught me. He has this great essay about how, when he went for a bike ride, he could go really hard, all out, and do the ride in, I think, 19 minutes. Or he could enjoy the ride, go 5% slower, do the ride in 21 minutes, and realize there's only 2 minutes between them. Either I go all in all the time, and there's nothing else—I’m completely exhausted at the end—or I travel the same distance and arrive maybe 2 minutes later, but I get to enjoy the scenery, listen to the birds, and smell the flowers. That journey is also valuable.

Now, I say that while accepting and celebrating that if you want to be the best at one thing in the world, you have to sacrifice everything. You have to be obsessed with just that thing. There is no instance of someone who's the best in the world at something who's not completely obsessed with it.

I didn't need to be the best at anything. This was a blessing—a rare blessing of humility I had early on. I thought, "You know what? I'm not that smart. I'm not that good. I'm not that talented. I can do interesting things by combining different aspects and elements that I know, but I'm not going to be the best at anything."

That released me from this singular obsession of thinking, "I'm going to be the best programmer in the world." I know I'm not. I fucking failed at it twice before I even understood how conditionals worked. I'm not smart enough to be the best at anything. I'm not dedicated enough to do that. That's a bit of a blessing.

I think as a society we have to straddle both celebrating peak excellence, which we do all the time, and celebrating the peak intensity of mission it takes to become that. Then we also have to say, "You know what? We don't all need to be Michael Jordan. There's only going to be one of those."

There are certain pursuits where a singular obsession is required. Basketball is one of them, by the way. Probably racing. If you want to be the best in Formula 1 in the world—

Lex Fridman

If you want to be Senna, you've got to be a maniac.

David Heinemeier Hansson

But I would argue that in most disciplines, like programming, if you want to be quote-unquote the best, whatever that means, I think that's judged at the end of your life. Usually, if you look at that path, it's going to be a nonlinear one.

You're not going to have a life like that of an Olympic athlete with a singular focus. There's going to be some acid in your 20s, or there are going to be several detours. The true greats are going to have detours, and sometimes they're not going to be Steve Jobs acid-trip-type situations. They'll just be different companies you worked for, different careers, or different efforts you allocated your life to. It's going to be nonlinear. It's not going to be a singular focus.

The way I think about this sometimes is that I want a good bargain on learning. I can become in the top 5% of whatever I define as being good at much more easily. Perhaps it's 20 times easier, 100 times easier, to get into the top 5% than it is to get into the top 0.1%. That's almost impossibly hard to achieve.

But if I'm content just being in the top 5%, I can be in the top 5% at five things at once. I can get really good at writing, become decent at driving a race car, become pretty good at programming, run a company, and have a family. I can do a lot of things at the same time.

That gives me the sort of variety that an idealized Karl Marx had in mind: "I'm going to fish in the morning, hammer in the evening, and paint on the weekends." There's a sense, for me at least, where his diagnosis of alienation was true. That tunnel vision—there's just this one thing I'm going to focus on—gives me a sense of alienation I can't stomach.

When I'm really deep into programming, and sometimes I go deep for weeks, maybe even in a few cases months, I have to come up for air and go do something else. I'm like, "All right, that was programming for this year. I've done my part. I'm going to go off riding, annoy people on the internet, drive some race cars, or do something else." Then I can do the programming thing with full intensity again next year.

Lex Fridman

Speaking of annoying people on the internet, you've got to explain this drama to me. What is this guy who said, "Imagine losing to Jira, but boasting that you have a couple million dollars per year"?

This had to do with this almost-now-meme decision to leave the cloud. DHH left the cloud. I think that's literally a meme, but it's also a fascinating decision. Can you talk through the full saga of DHH leaving the cloud?

David Heinemeier Hansson

Yes.

Lex Fridman

Leaving AWS, saving money. And I guess the case this person is making—

David Heinemeier Hansson

No.

Lex Fridman

—is that we wasted our time optimizing a business that could have been 100 times bigger if we'd just gone for the moon. Going for the moon includes venture capital and other things, including not caring about cost. But also, because AGI is around the corner, you should have been investing in AI, right? Is this just part of—

David Heinemeier Hansson

—sort of a tangent? I think it's a bit of a muddy argument, but if we just take it at its peak ideal, which I actually think is a reasonable point, it's that you can get myopically focused on counting pennies when you should be focused on getting pounds.

I've optimized our spend on infrastructure by getting out of the cloud, and that took some time. I could have taken that time and spent it on making more features that would have attracted more customers, spent even more time with AI, or done another thing. Opportunity cost is real. I'm not denying that.

I'm pushing back on the idea that, for a company of our size, saving $2 million a year on our infrastructure bill—which is about somewhere between half and two-thirds and goes directly to the bottom line, meaning it's returned to Jason and me as owners and to our employees through our profit-sharing plan—isn't totally worth doing.

This idea that costs don't matter is a very Silicon Valley way of thinking. I understand it at a certain scale, maybe, but I also think it's aesthetically unpleasing. I find an inefficient business, just as I find an inefficient program full of line noise, to be a splinter in my brain. I hate looking at an expense report and seeing disproportionate waste.

When I was looking at our spend at 37signals a few years back, I saw bills that did not pass my smell test. I remembered how much we used to spend on infrastructure before the cloud, and I saw numbers I could not recognize in proportion to what we needed.

The fact that computers have gotten so much faster over time—shouldn't things be getting cheaper? Why are we spending more and more money servicing more customers? Yes, but with much faster computers. Moore's law should be lowering the cost, and the opposite is happening. Why is that happening?

That started a journey of unwinding why the cloud isn't as great a deal as people like to think it is.

Lex Fridman

Yeah. Can we look at the specifics, just for people who don't know the story, and then generalize to what it means about the role of the cloud in a tech business? The specifics are that you were using AWS S3 for—

David Heinemeier Hansson

We were using AWS for everything. HEY launched as an entirely cloud app. It was completely on AWS for compute, databases, all of it. We were using all the systems as they were prescribed to us.

Our total spend with AWS was, I think, $3.2 million or $3.4 million at its peak. That's kind of a lot of money. $3.4 million. I mean, we have a ton of users and customers, but still, that just struck me as unreasonable.

The reason why it was so unreasonable was because I had the pitch for the cloud ringing in my ears: "Hey, this is going to be faster. This is going to be easier. This is going to be cheaper. Why are you trying to produce your own power?"

Lex Fridman

Like, do you have your own power plant? Why would you do that? Leave the computers to the hyperscalers. They're much better at it anyway.

David Heinemeier Hansson

I actually thought that was a compelling pitch. I bought into that pitch for several years and thought, "You know what? I'm done ever owning a server again. We're just going to rent our capacity, and Amazon is going to be able to offer us services much cheaper than we could buy them ourselves because they're going to have these economies of scale."

I was thinking of Jeff's words ringing in my ears: "My competitor's margin is my opportunity." That was something he used to drive Amazon.com with. If he could just make 2% when the other guy was trying to make 4%, he would end up with all the money, and on volume he would still win.

So I thought that was the operating ethos for AWS. It turns out that's not true at all. AWS, by the way, operates at almost 40% margin.

Lex Fridman

So, just in that, there's a clue that competitors are not able to do the competitive thing we like about capitalism, which is to lower costs and so forth. So the cloud pitch, in my optics, is fundamentally false. It did not get easier. First of all, I don't know if you've used AWS recently.

David Heinemeier Hansson

It is hella complicated. If you think Linux is hard, you've never tried to set up IAM rules or access parameters or whatever for AWS.

Lex Fridman

Yeah, AWS was always difficult. It was always clunky.

David Heinemeier Hansson

Well, I think it's gotten even more difficult. But yes, now some of that is because it's very capable and you have a bunch of capacity on tap. There are reasons. I don't think they're good enough to justify how complicated the whole thingamajig has become.

But what's certainly true is that it's no longer easier to use AWS than it is to run your own machines, which we learned when we pulled out of the cloud and didn't hire a single extra person. Even though we operate all our own hardware, the team stayed exactly the same.

So, you have this three-way pitch, right? It's going to be easier. It's going to be cheaper. It certainly wasn't cheaper. We've just proved that by cutting our spend on infrastructure by half to 2/3.

And it's going to be faster. The last bit was true, but way too many people overestimated the value of that speed. If you need a thousand computers online in the next 15 minutes, nothing beats the cloud. How would you even procure that?

If we just need another 20 servers, it's going to take a week or two to get boxes shipped on pallets, delivered to a data center, and unwrapped and racked and all that stuff, right? But how often do we need to do that? And how often do we need to do that if buying those servers is way, way cheaper, such that we get vastly more compute for the same amount of money?

Could we just buy more servers and not even care about the fact that we're not hyper-optimized on compute utilization? We don't have to use things like automatic scaling to figure things out because we have to reduce cost. Yes, we can.

So, we went through this journey over a realization in early 2023 when I had finally had enough with our bills. I wanted to get rid of them. I wanted to spend less money. I wanted to keep more of the money ourselves.

And in just over 6 months, we moved 7 major applications out of the cloud—in terms of compute, caching, databases, the works—onto our own servers. A glorious, beautiful new fleet bought from the king of servers, Michael Dell, who really, by the way, is another icon of mine. I saw he just celebrated 41 years in business.

41 years this man has been selling awesome servers that we've been using for our entire existence. But anyway, these pallets arrive in a couple of weeks, and we rack them up and get everything going, and we were out, at least with the computer part.

We then had a long, multi-year commitment to S3 because the only way to get decent pricing in the cloud, by the way, is not to buy on a day-to-day basis, not to rent on a day-to-day basis, but to bind yourself to multi-year contracts. With compute, it's often a year. That was the case for us. And with storage, it was 4 years.

We signed a 4-year contract to store our petabytes of customer files in the cloud to be able to get something just halfway decent and affordable. So, all of these projects came together in the sense that we're now saving literally millions of dollars, projected at about $10 million over 5 years. It's always hard—how do you do the accounting exactly?—and this, that, and the other thing, but it's millions of dollars.

But it's not just that. It's also the fact that getting out of the cloud meant returning to more of an original idea of the internet: that the internet was not designed such that 3 computers should run everything. It was a distributed network such that the individual nodes could disappear and the whole thing would still carry on.

DARPA designed this such that the Russians could take out Washington and they could still fight back from New York, that the entire communication infrastructure wouldn't disappear because there was no hub and spoke. It was a network.

I always found that an immensely beautiful vision: that you could have this glorious internet and no single node was in control of everything. And we've returned to much more of a single-node-controlling-everything idea with these hyperscalers.

When us-east-1, the main and original region for AWS, goes offline, which has happened more than a few times over the years, seemingly 1/3 of the internet is offline. That in itself is just an insult to DARPA's design.

It doesn't detract from the fact that what AWS built was marvelous. I think the cloud has moved so many things so far forward, especially around virtualization, automation, and setup. It's all those giant leaps forward in system administration that are allowing us now to run things on-prem in a way that smells and feels much like the cloud, just at half the cost or less, and with the autonomy and the satisfaction of owning hardware.

I don't know when was the last time you looked at an actual server and took it apart and looked inside, but these things are gorgeous. I posted a couple of pictures of our racks out in the data center, and people always go crazy for them because we've gotten so abstracted from what the underlying metal looks like in this cloud age that most people have no idea.

Lex Fridman

They have no idea how powerful a modern CPU is. They have no idea how much RAM you can fit into a 1U rack.

David Heinemeier Hansson

Progress in computing has been really exciting, especially, I'd say, in the last 4 to 5 years after TSMC, with Apple's help, really pushed the envelope. We kind of sat still there for a while while Intel was spinning its wheels, going nowhere, and then TSMC, with Apple propelling them, really moved things forward, and now servers are exciting again.

You're getting jumps year over year in the 15–20% range rather than the single digits we were stuck with for a while. And that all means that owning your own hardware is a more feasible proposition than it's ever been, that you need fewer machines to run ever more, and that more people should do it because, as much as I love Jeff and Amazon, he doesn't need another whatever 40% margin on all the tech stuff that I buy to run our business.

And this is just something I've been focused on both because of the ideology around honoring DARPA's original design, the practicality of running our own hardware, seeing how fast we can push things with the latest machines, and then saving the money. And that has all been so enjoyable to do, but also so counterintuitive for a lot of people because it seemed, I think, for a lot of people in the industry, that we'd all decided that we were done buying computers, that that was something we would just delegate to AWS, Azure, and Google Cloud, that we didn't have to own these things anymore.

So, I think there's a little bit of whiplash for some people that, "Oh, I thought we agreed we were done with that." And then along come us and say, "Yeah, do you know what? Maybe you should have a computer."

Lex Fridman

Are there some pain points to running your own servers?

David Heinemeier Hansson

Oh, plenty. There's pain points to operating computers of all kinds. Have you tried just using a personal computer these days? Half the time when my kids or my wife have a problem, I go, "Have you tried turning it just off and on?"

Again, computers are inherently painful to humans. Owning your own computer, though, kind of makes some of that pain worth it. There's a responsibility that comes with actually owning the hardware that, to me at least, makes the burden of operating that hardware seem slightly more enjoyable.

Now, there are things you have to learn, certainly at our scale, too. I mean, we're not just buying a single computer and plugging it into Ethernet. We have to have racks and racks of them, and you have to set it up with network cabling, and there is some specialized expertise in that.

But it's not like that expertise is like building nuclear rockets. It's not like it's not widely distributed. Literally, the entire internet was built on people knowing how to plug a computer into the internet, right? Oh, Ethernet cable goes here, power cable goes here. Let's boot up Linux. That's how everyone put anything online until 10, 12 years ago, when the cloud sort of took over.

So, the expertise is there and can be rediscovered. You, too, can learn how to operate a Linux computer. Yeah. And when you get a bunch of them, there's a bunch of flashing LEDs and it's just so exciting.

Lex Fridman

Beautiful, calming, amazing.

David Heinemeier Hansson

Computers are really fun. This is actually something I've gotten into even deeper after we moved out of the cloud. Now, my next kind of tingle is that if you could move out of the cloud, can you also move out of the data center?

Personal servers have gotten really scarily quick and efficient, and personal internet connections rival what we connected data centers with just a decade or two ago. So there's a whole community around this concept of homelabbing, which is essentially installing server hardware in your own apartment, connecting it to the internet, and exposing that directly to the internet.

That harks back to those glorious days of the '90s when people building for the internet would host the actual website on their actual computer in the closet. And I'm pretty fired up about that. I'm doing a bunch of experiments. I've ordered a bunch of home servers for my own apartment.

I marvel at the fact that I can get a 5-gigabit fiber connection now. I think, do you know what 5 gigabits could have taken Basecamp to? Multiple millions of MRR, in the way that back then I ran the whole business on a single box with 2004 technology and probably a 100-megabit cable.

The capacity we have access to, both in terms of compute and connectivity, is something that people haven't readjusted to, and this happens sometimes in technology where progress sneaks up on you. This happened with SSDs. I love that, by the way.

We designed so much of our technology and storage approach and database design around spinning metal discs that had certain seek-time properties. And then we went to NVMe and SSDs. And it took quite a while for people to realize that the systems had to be built fundamentally differently now.

The difference between memory and disk was now far smaller when you weren't spinning these metal plates around with a little head that had to read off them. You were essentially just dealing with another type of memory. I think we're a little bit in that same phase when it comes to the capacity of new businesses to be launched literally out of your damn bedroom.

Lex Fridman

So, you can get pretty far with a large user base with home labbing.

Jason Fried

Absolutely.

Lex Fridman

That's exciting. That's really exciting. It's bringing back the startup in the garage in the literal, physical sense of the word.

David Heinemeier Hansson

Hell yes, we need to. The feeling of doing that by yourself, of seeing LED lights in your own home, there's nothing like that.

Lex Fridman

There's just an aesthetic to it that I am completely in love with, and I want to try to push on. Now, is that going to be the same thing as getting out of the cloud?

David Heinemeier Hansson

I'm not sure. Our exit out of the cloud was not the exit out of the data center. We basically just bought hardware and shipped it to a professionally managed data center that we didn't even actually touch.

This is the other misconception people have about moving out of the cloud: that we have a bunch of people who are constantly driving to a data center somewhere to rack new boxes and change dead RAM. That's not how things happen in the modern world at all.

We have a company called Summit, previously Deft, that is what we call white-glove service. They just work in the data center. When we need something, it's, "Hey, Deft, can you go down and swap the dead SSD in box number 6?" They do it.

What we see is akin to what someone working with the cloud would see. You see IP addresses coming online. You see drives coming online. It's not that different, but it is a whole heck of a lot cheaper when you're operating at our scale.

Of course it's cheaper to own things if you need those things for years rather than to rent them. In no other domain would we confuse those two things. It's cheaper to own something for the long duration than it is to rent it.

Lex Fridman

There is some gray area. I've gotten a chance to interact with the xAI team a bunch. I'll probably be going back out there in Memphis to do a big podcast associated with the Grok release.

Those folks, in order to achieve the speed of building up the cluster and to solve some of the novel aspects that have to do with the GPU and the training, have to be a little bit more hands-on. It's less white-glove.

David Heinemeier Hansson

Oh, and I love that. They're dealing with a frontier problem, and they're dealing with it not by renting a bunch of GPUs at a huge markup from their main competitor. They're going, "No, screw that. We're going to put 100,000 GPUs in our own tents and build it in absolute record time."

I think, if anything, this is testament to the idea that owning hardware can give you an advantage at the small scale, at the medium scale, and at the pioneer levels of computing.

Lex Fridman

By the way, speaking of teams, xAI and Tesla are large companies, but all those folks—I don't know what it is about this. You said Jeff is really good at finding good people, at seeing strength in people. Elon is also extremely good at that. I don't know what it is. I've never really seen anything like it. Maybe you could speak to that. He's good at finding greatness.

David Heinemeier Hansson

I don't think he's finding as much as he's attracting. He's attracting the talent because of the audaciousness of his goals and his mission, and the clarity with which he states it. He doesn't have to go scour the earth to find the best people. The best people come to him because he is talking about Elon here, one of the singularly most invigorating figures in the modern order of the universe.

Haters and lovers, right? He's having such an impact at such a scale that, of course, he's going to have literally millions of people think he's the worst person in the world. He's also going to have millions of people thinking he's the greatest gift to humanity, depending on the day. I'm somewhere in between, but I'm more on the greatest-gift-to-humanity end of the scale than on the other end of the scale.

I think that really inspires people in a way that we've almost forgotten. That level of audacity is so rare.

Lex Fridman

When we see it, we don't fully know how to analyze it. We think of Elon as finding great talent, and I'm sure he's also good at that. But I also think that this beacon of the mission—"We're going to fucking Mars. We're going to transform transportation into using electricity. We're going to cover the Earth in internet"—is so grand that there are days where I wake up and go, "What the fuck am I doing with these to-do lists?"

Like, Jesus, should I go sign up for something like that? That sounds invigorating, in a sense I can only imagine, like a Viking back in 1050 going, "Should we go to Normandy? You may die along the way, but oh boy, does that sound like a journey and an adventure?"

There's a few components there. One is definitely this bigger-than-life mission and really believing it. Every other sentence is about Mars—really believing it. It doesn't really matter what anybody else says, the criticism or anything. There's a very singularly focused, big mission.

But I think it also has to do with a bunch of the other components, like being able to hire well once the beacon attracts people. I've seen people who don't necessarily, on paper, have a résumé with a track record. I've seen people who turned out to be legendary. He basically tosses them the ball of leadership, sees something in them, and says, "You go." He gives them the ownership, and they run with it.

That happens at every scale. There's a real meritocracy, and you can see the flourishing of human intellect in these meetings, in these groups getting together. The energy is palpable. It's exciting for me just to be around that, because there aren't many companies where I've seen it.

When a company becomes successful and larger, it somehow suffocates that energy that you see in startups at the early stages. It's cool to see it at a large company that's actually able to achieve scale.

David Heinemeier Hansson

I think part of the secret there is that Elon actually knows things. When you know things, you can evaluate the quality of work products. When you can evaluate the quality of work products, you can very quickly tell who's full of shit and who will actually take you to Mars. You can fire the people who are full of shit, and you can bet on the people who get us to Mars.

That capacity to directly evaluate the competency of individuals is actually a little bit rare. It's not widely distributed among managers and hiring managers. It's not something you can easily delegate to people who are not very skilled at the work itself.

Elon obviously knows a lot about a lot, and he can smell who knows stuff for real. This is something I've tried to do at our tiny scale, too. When we hire programmers, it's going to be interesting now with AI as a new challenge, but up until this point, the main pivot point for getting hired was not your résumé, the schooling you've had, your grades, or your pedigree.

It was how well you did on 2 things. First, your cover letter, because I can only work with people remotely if they're good writers. If you can't pen a proper cover letter and can't bother to put in the effort to write it specifically for us, you're out.

Second, you have to be able to program really well, to the degree that I can look at your code and go, "Yeah, I want to work with that person." Not only do I want to work with that person, I want to work on that person's code when I have to see it again in 5 years to fix some damn bug.

We're going to give you a programming test that simulates the way we work for real, and we're going to see how you do. I've been surprised time and again. I thought for sure a candidate was a shoo-in. They sounded just right, the CV was just right, and then I saw the code they turned in. I was like, "No way. No way are we hiring this person."

The other way has been true as well. I've thought, "I don't know about this guy or this woman," and then they turn in their coding stuff, and I'm like, "Holy shit. Can that person be on my team tomorrow?" The capacity to evaluate work product is a superpower when it comes to hiring.

Lex Fridman

There's a step that I've seen Elon do really well, which is being able to show up and say, "This can be done simpler."

David Heinemeier Hansson

Yes.

Lex Fridman

But he knows what he's talking about. The engineer's first reaction—you can kind of tell—is almost like rolling your eyes if your parent tells you something. "This is not—no, I've been working on this for a month. You don't know."

But when you have that conversation a little more, you realize, no, it can be done simpler. Find the way. When 2 engineers are talking, one might not have perfect information, but if the senior engineer has good instinct that's been battle-earned, then you can say, "Simplify," and it actually will result in simplification.

David Heinemeier Hansson

I think this is the hallmark of the true greats: they not only have the insight into what's required to do the work, but they also have the transcendent vision to go beyond what the engineer or programmer would do.

If we're looking at these rarities, obviously the myth of Steve Jobs was also this. Even though perhaps he was less technical than Elon is in many ways, he had the same capacity to show up to a product team and really challenge them to look harder for simplification, or for making things greater in a way that would garner disbelief from the people who were supposed to do it.

Like, this guy is full of shit. This is crazy. We can never do it, and then 2 months later, it is. There is something to this where you need the vision, but you need it anchored by the reality of knowing enough about what's possible. You need to know enough about physics and enough about software that you're not just building bullshit.

There are plenty of people who can tell a group of engineers, “No, just do it faster.” That's not a skill. It's got to be anchored in something real, but it's also got to be anchored in—it’s a tired word—a passion for the outcome to a degree where you get personally insulted if a bad job is done.

This is what I've been writing about lately with Apple. They've lost that asshole who would show up and tell engineers that what they did was not good enough in ways that would perhaps make them feel a little small in the moment, but would spark that zest to really fix it. Now they have a logistics person who's very good at sourcing components and lining up production Gantt charts, but you're not getting that magic.

What's interesting with that whole scenario was that I actually thought, “How well Tim Cook ran things, and has run things, at Apple for so long—maybe we were wrong. Maybe we were wrong about the criticality of Steve Jobs to the whole mission. Maybe you could get away with not having it.” I think the bill was just going to come later, and now it has. Apple is failing in all these ways that someone who would blow up Steve's ghost and really exalt him would say, “See, this is what's happening now.”

So, the other thing here, too, of course, is it's impossible to divorce your perception of what's a critical component of the system from the messy reality of a million different moving parts in the reality of life. You should be skeptical about your own analysis and your own thesis at all times.

Lex Fridman

Since you mentioned Apple, I have to ask. Somebody on the internet submitted the question: Does DHH still hate Apple? I believe the question is—there was a time when Basecamp went to war with Apple over the 30%. Can you tell the saga of that battle?

David Heinemeier Hansson

Yes. But first, I'll tell you how I fell in love with Apple, which was all the way back in the early 2000s, when Microsoft was dominating the industry in a way we now see Apple and Google dominate mobile phones. Microsoft was just everything when it came to personal computers, and I really did not like the Microsoft of the ’90s. The Microsoft of the ’90s was the “cut off the air supply to Netscape” kind of character. It was Bill Gates sitting defiant in an interview with the DOJ, asking about the definition of what is, and just overall unpleasant. I think you can have respect for what was achieved, but I certainly didn't like it.

As we've talked about, I came begrudgingly to the PC after Commodore fell apart and I couldn't continue to use the Amiga. I already had a bit of a bone to pick with PCs, just over the fact that I loved my Amiga so much. But then, in the early 2000s, Apple emerged as a credible alternative because they bet the new generation of Macs on Unix underpinnings, and that allowed me to escape from Microsoft. Suddenly, I became one of the biggest boosters of Apple.

I was in my graduating class at the Copenhagen Business School. I started with the first white iBook, the first person using a Mac. By the time we were done and graduating, I had basically converted half the class to using Apple computers because I would evangelize them so hard and demonstrate them and do all the things that a superfan would do. I continued that work over many years.

Jason and I actually did an ad for Apple in, I think, 2004 or 2005 that they posted on the developer site. We were all about how Apple was so integral to everything that we did, how we looked up to them, and how we were inspired by them. That love relationship actually continued for a very long time. I basically just became a Mac person for 20 years. I didn't even care about looking at PCs. Whatever Microsoft was doing seemed irrelevant to me, which felt like such a relief, because in the ’90s I felt like I couldn't escape Microsoft. Suddenly, I had found my escape, and now I was with Apple. It was glorious.

They shared so many of my sensibilities and my aesthetics, they kept pushing the envelope, and there was so much to be proud of and so much to look up to. Then that sort of started to change with the iPhone, which is weird because the iPhone is what made modern Apple. It's what I lined up for in 2007 together with Jason for 5 hours to buy—a first-generation product where Apple staff would clap at you when you walked out of the store. I don't know if you remember that. It was a whole ceremony, and it was part of that myth and mystique and awe of Apple.

I just wasn't in the market for other computers. I wasn't in the market for other computer ideas. I thought perhaps I'd be with the Mac until the end of days. But as Apple discovered the gold mine that it is to operate a toll booth where you don't have to innovate, where you don't actually even have to make anything, where you can just take 30% of other people's business, there was a rot that crept into the foundation of Apple. That started all the way back with the initial launch of the App Store.

I don't think we saw it at the time—I didn't see it at the time—just how critical the mobile phone would become to computing in general. I thought when the iPhone came out, “Oh, it's like a mobile phone. I've had a mobile phone since the early ’90s.” Well, it wasn't a mobile phone. It was a mobile computer. Even more than that, it was the most important computer—or it would become the most important computer—for most people around the world.

David Heinemeier Hansson

That meant that if you liked to make software and wanted to sell it to people, you had to go through that computer. If going through that computer meant going through Apple's toll booth and not just having to ask them permission, which in and of itself was an indignity when you're used to the internet, where you don't have to ask anyone permission about anything, that always sat wrong with me. You buy a domain and launch a business, and if customers show up, boom, you're successful. If they don't, well, you're a failure. Now, suddenly, before you could even launch, you'd have to ask Apple for permission.

That always sat wrong with me, but it wasn't until we launched HEY in 2020 that I saw the full extent of the rot that had snuck into Apple's App Store.

Lex Fridman

For people who don't know, HEY is this amazing email attempt to solve the email problem.

David Heinemeier Hansson

Yes. I like to pitch it as what Gmail would have been with 20 years of lessons applied in a way where they could actually ship. Gmail was incredible when it launched in 2004, and it still is a great product, but it's also trapped in its initial success. You can't redesign Gmail today; it just has way too many users.

So, if you want fresh thinking on email—and I wanted fresh thinking on email—I needed to build my own email system, not just my own email client. That's what a lot of people have done over the years: They build a client for Gmail. But you're severely constrained if you don't control the email server as well. If you really want to move the ball forward with email, you have to control both the server and the client. That was the audacious mission we set out to do with HEY.

What's funny is, I thought our main obstacle here would be Gmail. It's the 800-pound gorilla in the email space. Something like 70% of all email in the US is sent through Gmail.

Lex Fridman

I think their worldwide rates are probably in that neighborhood as well. They're just absolutely huge, and trying to attack an enormous, established competitor like that—who's still actually loved by plenty of people and is free—seems like a suicide mission.

David Heinemeier Hansson

It was only a mission we signed up for because we had grown ambitious enough after making Basecamp for 20 years that we thought we could tackle that problem. So, I thought, “Hey, this is dumb. I would not advise anyone to go head-to-head with Gmail. That seems like a suicide mission. We're going to try anyway because, you know what? If we fail, it's going to be fine.”

We're just going to build a better email experience for me and Jason and the people at the company and our cat, and that'll be okay because we can afford to do so. But when we got ready to launch after spending 2 years building this product and investing millions of dollars in it, we obviously needed mobile apps. You're not going to be a serious contender with email if you're not on a mobile phone, and you need to be there with a native client.

We had built a great native client for both iOS and Android. As we were getting ready to launch, we submitted both of them to the app stores and got both of them approved—I think on Friday afternoon for the iOS app. We then went live on Monday, and we were so excited: “Hey, world, we've been working on this new thing. I'd love for you to check it out.”

Of course, as with anything, when you launch a new product, there are some bugs. We quickly found a few in the iOS client and submitted a new build to Apple: “Hey, here's our bug fixes. Can you please update?”

That's when all hell broke loose. Not only were they not going to approve our update, they said, “Oh, wait a minute. We gave you permission to be in the App Store, but I'm sorry, that was a mistake. We see that you're not using our in-app payment system, which means that we don't get 30% of your business. You will have to rectify that, or you can't be in the App Store.”

At first, I thought, “Well, it got approved already. We're running on the same model we've run Basecamp on in the App Store for a decade. If you're not signing up through the app, and we're signing up our own customers on our own website, and they're just going to the App Store to download their companion app, we're going to be fine.” That was the truth, right? That was why I never got so fired up about the App Store, even as Apple started tightening the screws: My business was okay.

Now suddenly, my business wasn't okay. Apple was willing to destroy HEY if we did not agree to give them 30% of all the signups that came through the iOS app. And it wasn't just about the 30%. It was also about splitting and no longer having a direct relationship with our customers.

When you sell an app in the App Store, you're not selling an app to a customer. You're selling an app to an entity at Apple, and then Apple sells an app to that customer. That customer has a purchasing relationship with Apple. So if you want to give discounts or refunds or whatever, it's complete hell. If you want to easily support multiplatform, that's complete hell.

If someone signs up for HEY on their iPhone and they want to switch to Android, but the billing relationship is tied to Apple, it's complete hell. For a million reasons, I did not want to hand my business over to Apple. I did not want to hand 30% of our revenue over to Apple.

So we decided to do something that seemingly Apple had never heard before. We said, “No, we're not going to add the in-app payment. I don't care if you're threatening us. This is not fair. This is not reasonable. Please approve.” And, of course, they didn't. It escalated.

After a couple of days, we realized, you know what? This isn't a mistake. This isn't going away. We're going to be dead if they go through with this. If we're not going to yield and give them the 30%, they're going to kick us off—unless we make such a racket, such noise, that they will regret it.

We were blessed by the fact that we launched HEY one week before the WWDC, their Worldwide Developers Conference, where Apple loves to get up onstage and harp on how much they do for developers, how much they love them, and why you should build for their new devices, and so on and so forth. We also just happened to have a platform on the internet, which is very convenient when you need to go to war with a $3 trillion company.

So I started kicking and screaming and essentially turning it up to 11 in terms of the fight, going public with our denial to be in the App Store. That turned into a prolonged two-year battle with Apple that essentially ended in the best possible outcome we could have gotten as David fighting Goliath, which was a bit of a truce.

We wouldn't hand 30% over to Apple. They wouldn't kick us out of the App Store. But we had to build some bullshit dummy account such that the app did something when you downloaded it. That was a rule that Phil Schiller seemingly made up on the fly when pressed for the fifth time by the media about why we couldn't be in the App Store when a million other companion apps could.

But we just happened to be able to create so much pain and noise for Apple that it was easier for them to just let us be than to keep on fighting.

Lex Fridman

What do you think about Tim Sweeney's victory with Epic over Apple?

David Heinemeier Hansson

I think it is incredible, and the entire developer ecosystem—not just on iOS but on Android as well—owe Epic, Tim Sweeney, and Mark Rein an enormous debt of gratitude for taking on the only battle that has ever inflicted a serious wound on Apple in this entire sordid campaign of monopoly enforcement, and that is Epic's fight versus them. Tim recently revealed that it has cost well over $100 million in legal fees to carry on this battle against Apple.

We, for a hot moment, considered suing Apple when they were threatening to kick us out. We shopped the case around with a few law firms, and perhaps, of course, they would tell us, “You have a good case.” I mean, they're trying to sell a product here. But they would also tell us it's going to cost a minimum of $10 million, and it's going to take 5 to 7 years through all the appeals. Now we know the actual price tag was 10 times higher, right? Epic spent over $100 million.

It would have destroyed us to take on Apple in the legal realm. Only a company like Epic could do it. And only a company run by founders—

Lex Fridman

Mhm.

Jason Fried

—like Tim, like Mark, could risk the business in the way that they did, the audacity they had to provoke the fight in the first place, which I thought was just incredible, and to stick with it for the long term. No board would have signed off on this lawsuit with a professional CEO. No freaking way.

So, the fact that they've been able to beat Apple in also the most hilarious way possible, I think, is just incredible, because remember, their first victory in the case was actually not much of a victory. There were about 11 counts in the trial. Apple basically won 10 of them, and the judge awarded Epic this one little win: Apple couldn't tell them not to link out to the internet to do the payment processing.

So they won this one little thing, and Apple, instead of just taking the 10 out of 11 wins and going, “Fine, you can have your little links, but all these other rules stay in place,” decided to essentially commit criminal contempt of court, as they've now been referred for prosecution, and angered the judge to such a degree that the rule of law in the US now is that you can launch an app in the App Store and you don't have to use in-app payment, but you can have a direct billing relationship with a customer if you just link out to the open internet when you take the credit card and then hop back into the app.

And we owe all of that to Tim and Mark. We owe all of that to Epic. We're going to launch new apps any minute now—I hope, actually, next week—that take advantage of this, that revamp the HEY app such that people who download the HEY app off the Apple App Store can sign up in the app and can then use the web to put in their credit card.

So we don't have to pay 30%, so we have a direct billing relationship, and such that they can take that subscription to Android, to PCs, whatever, without any hassle. And we have Tim and Mark to thank for it.

Lex Fridman

Yeah, Tim—I mean, like you said, founders, but also a specific kind of founders, because I think maybe you can educate me on this, but Tim is somebody who maintains to this day sort of the unreasonableness of principles.

Jason Fried

Yes.

Lex Fridman

That's what I love. I think sometimes maybe even with founders you can get worn down. It's a large company.

David Heinemeier Hansson

There's a lot of smart, quote-unquote, people around you—

Lex Fridman

—lawyers who just whisper in your ear over time, and you're like, “Well, just be reasonable. This is a different thing,” and to be the sort of—I mean, Steve Jobs did this—maintain, “I'm still the asshole.”

Jason Fried

Yes.

Lex Fridman

Who says no—

David Heinemeier Hansson

This whole company—I'll sink this whole fucking company over this. That's the exact language basically I used in our original campaign: “I will burn this business down before I hand over 30% of it to Apple.”

And that sort of indignation, that actual rage, is something I try to be a little careful about tapping into because it is a little bit of a volatile compound. I mean, I have a bunch of employees. We have a bunch of customers. It would be pretty sad if the journey of 37signals after 25 years came to an end because Apple would burn us down, or I would burn the business down, over this fight with Apple.

But I think you also need that level of conviction to be able to even drive the day-to-day decisions.

One of the other Apple examples—I know I'm ragging on Apple a little bit here, and I don't actually hate them. I really don't. I am tremendously disappointed at the squandered relationship that did not need to be sold away for so little. Now, I understand that the App Store toll booth is actually pretty big business. It's multiple billions, but Apple is a trillion-dollar company, and I think, in the lens of history, this is going to come off as a tremendous mistake. I think it's already coming off as a tremendous mistake.

The flop that was the Vision Pro was partly because Apple had pissed off every other developer. No one was eager to come build the kind of experiences for their new hardware that would perhaps have made it a success. So when you're on top and you have all the cards, you can delude yourself into thinking that you can dictate all terms at all times and there are no long-term consequences.

Apple is learning, finally, the fact that there are long-term consequences and that developers actually are important to Apple's business, and the relationship is not entirely one-sided. We don't owe our existence to Apple and Apple alone. We've built our own customer bases. Apple has been beneficial to the industry. I'm glad the iPhone exists.

It's not that it doesn't go both ways, but Apple wants it only one way. And I think that is a mistake. And it's a mistake that was avoidable. And that's disappointing. Certainly disappointing for me.

I've literally spent 20 years evangelizing this shit, right? I've spent so much money buying Apple hardware, excusing a bunch of things they've done over the years, and then for what? For the fact that you wanted 30% of something that I created in the most unreasonable way possible. Couldn't we have found a better way to do this? I think they're going to get forced to do it a better way.

Lex Fridman

But did you also have to go through the indignity of having a criminal contempt charge against you, getting referred to prosecution? It just seems so beneath Apple. But it also seems so in line with what happens to huge companies that are run by quote-unquote professional managers rather than founders and unreasonable people.

Well, we should probably also say that the thing you love about Apple—the great spirit of Apple—I think still persists, and there's a case to be made that this 30% thing is a slice, a particular slice of a company, not a defining aspect of the company, and that Apple is still on top in the hardware that it makes and in a lot of things that it makes.

And, you know, this could be just a hiccup in a long story of a great company that does a lot of awesome stuff for humanity. So, like, Apple's a truly special company. We mentioned Amazon.

There is no company like Apple.

David Heinemeier Hansson

I agree. This is why the disappointment is all the greater: we had such high aspirations and expectations for Apple, that they were the shining city on the hill and they were guiding the industry in a million positive ways.

I think, as we talked about earlier, hardware is exciting again in large part because Apple bought PA Semi and pursued an against-all-odds mission to get Arm up to the level it is today. We have these incredible M chips now because of it. The design sensibilities that Apple brings to the table are unparalleled. No one has taste, certainly at the hardware level, like Apple does.

Even at the software level, I'd say there's a lot of taste left in Apple, but there's also some real sour taste now. They have to wash that off first, I think, before they find their way back.

Apple's been in a mire before. I mean, Wozniak and Steve Jobs started this thing in the garage and had great success with the Apple II. He hands the company over to a sugar-water salesman who tanks the company into the 1990s. He doesn't learn the lesson. He spends the next 20 years building up this amazing company. Then he hands the company over again to a logistics person who presumably had more redeeming qualities than the first guy who was put in charge, but still ends up leading the company astray.

Now, this is the norm. The norm is that great companies don't last forever. In the long arc of history, almost no company lasts forever. There are very few companies around that were here 100 years ago, even fewer 200 years ago, and virtually nothing that is 1,000 years old outside of a handful of Japanese sword makers or something like that.

So you can get deluded into thinking that something is forever when you're in the moment and it seems so large. Apple could absolutely stumble, and I think they have more reason to stumble now than ever. They're behind on AI, terribly behind. Their software quality is faltering in a bunch of ways.

The competition is catching up on the hardware game, in part because TSMC is not an Apple subsidiary, but a foundry that services AMD, NVIDIA, and others who are now able to use the same kind of advanced processes. This is something I learned after not looking at PC hardware for the longest time: holy smokes, AMD actually makes CPUs that are just as fast, if not faster, than Apple's. They're not quite as efficient yet because Arm has some fundamental efficiencies over x86, but they're still pretty good.

So Apple should have reason to worry. Apple's shareholders should have reason to be concerned, not just about all these stumbles, but also about the fact that Apple is run by old people. Apple's board has an average age of, I think, 75. Their entire executive team is above 60.

Now, that sounds horribly ageist, and in some ways it is a little bit, in the same way I'm ageist against myself. I'm 45 now, and I sort of have to force myself to really get into AI because it is such a paradigm shift. A lot of people, when they reach a certain age, are just happy to stay with what they know. They don't want to go back to being a beginner. They don't want to go back to having to relearn everything. I think this is a little hard for me at 45. How the hell do you do that at 75?

Lex Fridman

Mhm. I have to come back to what you mentioned earlier. You're a parent. Can you speak to the impact that becoming a father has had on your life?

David Heinemeier Hansson

I think what's funny about fatherhood is that, for me, I wasn't even sure it was something I wanted. It took meeting the right woman and letting her convince me that this was the right idea before we even got started.

I didn't have starting my own family on the list of priorities in my late 20s or even early 30s. It was really the impetus of meeting my wife, Jamie, and her telling me, “This is what I want. I want to have a family. I want to get married. I want to have kids. I want to have 3.” And me going, for a second, “Whoa.” Then, “All right, let's do it.”

I think that's the kind of happy accident where some parts of my life have been very driven, where I knew exactly what I wanted, how to push forward toward it, and what the payoff was going to be. But when it comes to having a family, that always felt like a very fuzzy, abstract idea: sure, someday, maybe.

Then it became very concrete because I met a woman who knew what she wanted. Looking back on it now, it almost seems crazy. There's this fork in the road of reality where, if that hadn't happened and I were sitting here now not being a father and not having a family, the level of regret, knowing what I know now about the joys of having that family, would have been existential. I don't know if it would have been devastating.

I think men have a little bit of a longer window to pursue these things than women do. There are just certain biological facts. But ending up with the family I have now, ending up with my 3 boys, has been a transformative experience, in the sense that here's something that turned out to be the most important thing.

It was an open truth throughout all of history. You listen to anyone who's ever had children, and they will all say, “My children are the most important to me.” Yet somehow that wisdom couldn't sink in until you were in the situation yourself.

I find those truths fascinating when you can't actually relay them with words. I can tell you, “Hey, Lex, what are you doing? Get a wife. Make some kids.”

Lex Fridman

Get a move on it.

Jason Fried

These are just words. They're not communicating the gravity of what it actually feels like to go through the experience, and you can't really learn it without going through it.

David Heinemeier Hansson

Now, of course, you can be influenced. We can all help contribute; little sparks and little seeds can grow in your mind about it. But it still has to happen.

And now that I am in this situation, there's just sheer joy on a daily basis. You think your level of life satisfaction is on a scale of 1 to 10.

Yeah. And then the satisfaction of seeing your children understand something, accomplish something, learn something, do something, just be, goes like, “Oh, my God, this scale doesn't go from 1 to 10. It goes from 1 to 100.” I've been playing down here in the 1-to-10 range all this time, and there's a 1-to-100 range.

That has been humbling in a way that is impactful in and of itself. This whole idea that I thought I had a fair understanding of the boundaries of life in my early 30s—what is this about? I've been on this Earth long enough now to know something. I didn't know. I did not know that the scale was much broader.

I've often talked about the joys of having kids and just seeing your own DNA, which is remarkable to me, because literally that's been the pursuit of humans since the dawn of time. I am here today because, whatever, 30,000 years ago, some Neanderthal had the same realization that I should procreate and I should continue my bloodline, and that all amounts to me sitting here now.

But it didn't become a practical reality to me before meeting the right woman.

Lex Fridman

I think that's sometimes not part of the conversation enough: there's something broken at the moment about how people pair up in the Western world.

David Heinemeier Hansson

Yeah, and it's at the source of why we're not having enough children, because there aren't enough couples. There's not enough marriage. There's not enough of all these traditional values that, even 50, 60, 70 years ago, were just taken for granted.

We're in this grand experiment of what happens if we just remove a bunch of institutions. What happens if we no longer value marriage as something to aspire to? What happens if parenthood is now seen in some camps as almost something weird or against your own self-expression? It's a grand experiment, and I'm curious how it turns out.

I'd prefer to watch it as a movie, like Children of Men. That was a good movie. I kind of wish that wasn't reality, but we're seeing that reality play out while I'm sitting here in a very traditional, two-parent, loving household with 3 children and going, “This is now at the top.”

I've done a lot of things in my life. I've built software. I've built companies. I've raced cars. I've done all sorts of things. I would trade all of it in a heartbeat for my kids.

That's just a really fascinating human experience. The depth of that bond is something you can't appreciate before you have it. But I also think there's a role to play in talking it up, because we're being bombarded constantly with reasons why not to: “Oh, it's too expensive.” “You could get divorced, and then you might lose half.”

There are all these voices constantly articulating the case against marriage, the case against having children. Those of us who've chosen to do the traditional thing—to get married and to have children—have an obligation to talk it up a little bit. It would have seemed ridiculous, again, 50 years ago that you'd have to talk up something so fundamental.

But I have become obligated in that sense to do just that: to talk it up, to say, “You know what? You can look at everything that I've done, and if you like some of those parts, realize that to me, in this situation, the kids, the family, the wife, are more important than all of it.”

It sounds like a cliché because you've heard it a thousand times before. By becoming a cliché, maybe you start believing it's not true, that it's just something people say. But it is reality. I know almost no parents I have a personal relationship with who don't consider their children to be the most important thing in their life.

Lex Fridman

So there's a lot of interesting things you said. Perhaps more interestingly, I know a lot of super-successful people who are parents, who really love their kids, and who say that the kids even help them to be more successful.

David Heinemeier Hansson

Now, the interesting thing, speaking to what you're saying, is that it does seem for us humans it's easier to articulate the negatives because they're sort of concrete and pragmatic: it costs more, it takes up time, they can be crying all over the place, they're tiny narcissists running around, or whatever.

Lex Fridman

Which is all true, by the way.

David Heinemeier Hansson

Yeah, pooping everywhere, that kind of stuff. But to articulate the thing you were speaking to—that there's this little creature that you love more than anything you've ever loved in your life—it's hard to convert that into words. You have to really experience it. I believe it, and I want to experience it. But I believe it because, just from a scientific method, I've seen a lot of people who are honestly not very capable of love fall completely in love with their kids.

Lex Fridman

Yes.

David Heinemeier Hansson

Let's just call it what it is: engineers that are very beep-boop.

Lex Fridman

Yes.

David Heinemeier Hansson

They just fall in love, and it's like, all right, people who, just like you said, don't really want, don't really care, or don't really think about having kids—that kind of stuff—once they do it, it changes everything. It's hard to convert into words.

One of the reasons I think it's also difficult is that I like kids. Not that I actively dislike them, but when I was around other people's kids, I didn't have an emotional reaction. Some women have that reaction: they see a baby and go, and I never had any emotion like that. I mean, I could appreciate it. I'm glad for you that you have children. It did not provoke anything in me.

The emotions that are provoked in me when I look at my own children—this doesn't exist in the same universe. So you don't have a complete parallel—or at least a lot of men, or at least me, I didn't have a framework to put it into: what would it be like to have my own child?

And then you experience it. It's like—and it happens so quickly, too. This is what I found fascinating: it happens before that little human is even able to return any words to you. The love you develop for an infant happens quite quickly, not necessarily immediately. I don't know; different people have different experiences, but it took me a little bit. Then, once it hit, it just hit like a kick from a horse.

Lex Fridman

And I love that it's also just such a universal experience: you can be the most successful person in the world, you can be the poorest person in the world, you can be somewhere in the middle, and we share this experience that being a parent, for most people, turns out to be the most important thing in their life.

David Heinemeier Hansson

But you know, it is really nice to have that kind of experience with the right partner. But I think, because I'm such an empath, the cost of having the wrong partner is high for me. But then I also realized, man, I have a friend of mine who's divorced happily, and he still loves the shit out of his kids. It's still a mess, but all of that love is still there and, you know, you just have to make it work. It's just that I don't know that kind of divorce would destroy me.

Lex Fridman

I would rather my children did not exist because a relationship turned sour. I mean, I think you should try very hard. And I think this is also one of those things where we didn't fully understand those fences, and when we pulled them up and celebrated how easy it is to get divorced, for example, that that wasn't going to have some negative consequences.

I'm not saying you shouldn't have divorces. I'm not saying return to times past. I am saying, though, that civilization, over thousands of years, developed certain technologies for ensuring the continuation of its own institutions and its own life that perhaps we didn't fully appreciate. I mean, again, this is something Jordan Peterson and others are far more articulate to speak about, and that I've learned a lot from to analyze my own situation.

Why is it that this incredible burden—it is to be responsible for someone else's life that you brought into this world—is also the most rewarding part of existence? That's just curious.

David Heinemeier Hansson

Before I heard Peterson articulate the value of taking on the greatest burden you know how to carry, I always thought about burdens as negative things. Why would I want the burden of a child? I might screw it up. I might be a bad parent. All the reasons why you shouldn't, and so few voices articulating why you should.

Lex Fridman

Yeah. But there I should also add, on top of that thing you mentioned, currently, perhaps in the West, the matchmaking process—

David Heinemeier Hansson

Is broken.

Lex Fridman

Is broken, and technology made it worse. It's fascinating, this whole thing that hasn't been solved. So hiring great teams—that's probably been solved the best out of matchmaking. Finding great people to hire—

David Heinemeier Hansson

Right?

Lex Fridman

Second, finding great friends. That's also not been solved, and it's breaking down.

David Heinemeier Hansson

It's breaking down. And third is matchmaking for relationships. That's the worst. In fact, technology made it even worse.

Lex Fridman

Yes.

David Heinemeier Hansson

It's fascinating.

Lex Fridman

It is. It's a great example, again, of how all the greatest intentions still led us straight to hell. I really enjoyed Louise Perry's analysis of the sexual revolution not being an unqualified good, which was something I hadn't thought about at all before she articulated it: that, of course, women should be able to have freedom to choose termination and abortions and all of these things.

David Heinemeier Hansson

I mean, this is really the point. It also applies to religion, for example. If you remove from society the software of religion—

Lex Fridman

Yes.

David Heinemeier Hansson

You better have a good replacement. And we've had a bunch of bad replacements, especially over the last few decades. Religion is one of those things I've struggled with a lot because I'm not religious, but I sort of wish I was. I can now fully appreciate the enormous value having an operating system like that brings, not just at the individual level, but rather at a societal level.

And it's not clear at all what the answer is. I think we've tried a lot of dead ends when it came to replacements, and people have been filling that void in a million different ways that seem worse than all the religions, despite their faults, in a myriad of ways, have been able to deliver.

Lex Fridman

Yeah. Religion is like COBOL code. It's just—

David Heinemeier Hansson

Yes.

Lex Fridman

It's the institutions where we don't fully understand the rules, why they're there, and what's going to happen if we remove them. Some of them seem obvious to me; they're just bullshit of the time. Oh, you shouldn't eat whatever shellfish because in that region of the world there was something, something, something. Okay, fine.

But there's a bunch of other things that are pivotal to keeping society functioning for the long term, and we don't fully understand which is which. What's the bullshit, and what are the load-bearing pillars of society?

Can you speak to the hit on productivity that kids have? Do they increase your productivity, decrease it, or is that even the wrong question to ask?

David Heinemeier Hansson

I think it's one of the reasons why ambitious people are often afraid of having children, because they think, "I have so much more to do, and I barely have enough time now. How would I possibly be able to accomplish the things I want to accomplish if I add another human into the mix?"

A, we've always worked 40 hours a week, not 80, 100, or 120. I think that's very beneficial. B, kids don't exist in this vacuum of just them alone being entered into your life. Hopefully, there's a partner.

In my life, I'm married to a wonderful woman who decided to stop working her corporate job when we got together and has been able to carry a huge part of that responsibility. I was just about to say "burden." And I think that's exactly how it often gets presented, especially from a feminist perspective: that caring for your own children is some sort of unpaid labor that has to be compensated for in some specific way beyond the compensation of what? Bringing life into this world, raising wonderful humans.

There's something screwy about that analysis that I actually think the modern trad movement is a reply against. Whether they have all the answers, I'm certainly not sure of either. But there's something that's just not right in the analysis that children are a burden and that if a woman chooses to stay at home with the kids, that's some sort of failure mode of feminist ambition.

I think that's actually a complete dead end. It depends on different people and different circumstances. I can just speak to my life, being married to a wonderful woman who has decided to be home with the kids, at least in their early years, and taken on a lot of those responsibilities.

That doesn't mean there aren't plenty of ways that I have to be part of that and chip in, but it's allowed me to continue to work the 40 hours a week that I've always worked. It's made those 40 hours more strict. I have a schedule where I wake up at around 6:30, and we have to get out of the door a little before 8. I usually have to play at least 1 or 2 rounds of Fortnite with my youngest, sometimes my middle child, then take the kids to school and get in and start work at, I don't know, 8:30 or 9.

Then I work until 5 or 5:30, sometimes 6, but then it's dinner, and I have to be there for that. Then I have to read to the kids, and by the time that's done, I don't want to go back to work. So my work time really is 9 to 5 or 9 to 6, depending on whatever is going on. Sometimes there are emergencies, and you have to tend to them, but it's made it more structured, and I've found some benefit in that. I've found some productivity in that: I can't goof around quite as much.

The day will end at around 5:30 or 6. If I didn't accomplish what I wanted to do today, that's just how it is. If I get to that time, it's done. I'm over. I have to try again tomorrow.

Lex Fridman

Whereas before having a family and before having kids, I could just not do it and make it up in the evening.

David Heinemeier Hansson

So, in that way, it's made me more structured, but it hasn't really changed my volume of work all that much. I still work about the same number of hours. And that's, by the way, enough.

This is one of the key points we make in It Doesn't Have to Be Crazy at Work, the latest book we wrote: there's enough time. Forty hours a week is actually a ton if you don't piss it away. Most people do piss it away. They piss it away in meetings. They piss it away on just stuff that doesn't matter, when even 3 or 4 hours of concentrated, uninterrupted time every day would move the goals they truly care about way down the field.

Lex Fridman

I think kids do make you more productive in that way for people who need it, especially people like me. They create urgency. If you have to be done by 5, it's a maybe counterintuitive notion, but for people like me who like to work, you can really fill the day with fluff of work.

Jason Fried

Yes.

Lex Fridman

And if you have to be done by 5, you're going to have to do the deep work and get it done—really focused, singular work.

Jason Fried

Yes.

Lex Fridman

And then you're just going to cut off.

David Heinemeier Hansson

It keeps you honest. It keeps you honest because you can squander 1 day, you can squander 2 days, but if I squander a whole week, I feel terrible.

That's just some drive I have in me, where I feel content and full of meaning if I actually do stuff that matters. If I can look back upon the week and go, "That was a nice week. Really, we moved forward. Maybe we didn't get everything done, but we moved forward. Everything got better."

I think kids really help time-box things in that way. A lot of people need that, because I find so much of the celebration of overwork to be tiresome. "I work 60 hours or 80 hours or 100 hours a week." First of all, no, you don't.

Lex Fridman

No, you don't. Those 80 hours are full of all sorts of fluff that you label work, but that I would laugh at, and that most people would laugh at if you actually did the analysis of where that time is going.

Jason Fried

Most of the important stuff that has to be done is done in these uninterrupted chunks of 2 hours here or 4 hours there or 5 hours there. The hard part is making sure you get them in one whole piece.

So don't give me that. There's time enough. And also, what's so important that it ranks above continuing your lineage? I think there's just some ancient honor in the fact that this DNA that's sitting on this chair traveled 30,000 years to get here, and you're going to squander all that away just so you can send a few more emails.

There's something that's also hard to convert into words about the kind of fun you can have just playing with your kids. On the surface, I think, "I could have that kind of fun just playing video games by myself." But no, there's something magical about it, right?

I have 1,000 hours logged in Fortnite since 2019, I think, all of it with my kids. I'd never be playing Fortnite—well, I don't know if I'd never be playing it, but I wouldn't be playing 1,000 hours of Fortnite if it wasn't for my kids. The enjoyment for me is doing something with them that I also happen to enjoy.

I really love Fortnite. It's a phenomenal game. I don't have to force myself to play it with them. I often ask, "Hey, do you want to play Fortnite?" But it's still an activity that I get to share with them. It's a passion that I get to share with them.

I've started doing go-karting with my oldest. I've been driving race cars for a long time, and now they're getting into go-karting. Just being at the go-kart track, seeing them go around, seeing them get faster, seeing them learn that skill—you just look at what else I would be doing with my life at my age, 45. I'm standing here truly enjoying the life I brought into this world. What else is so important at this stage that I would otherwise be spending my time on?

Lex Fridman

All right. Like you mentioned, you like to race cars, and you do it at a world-class competitive level, which is incredible. How did you get into it? What attracts you to racing? What do you love about it?

David Heinemeier Hansson

The funny thing about getting into racing is that I did not get my driver's license until I was 25.

I grew up in Copenhagen, Denmark, where the tax on cars is basically over 200%. So you pay for 3 cars and you get 1. I didn't even have the money for 1 car, let alone 3. I could not afford a car growing up. We did not have a car growing up.

Copenhagen is a nice city to get around on a bike or with a bus, or, as I did for a long period of time, on rollerblades. But when I was 25, I realized I wanted to spend more time in the US. I wasn't sure yet that I was going to move there—that turned out later to be true—but I knew that if I wanted to spend time in the US, I needed to have a driver's license. I wasn't going to get around very well if I didn't know how to drive a car.

So I got my driver's license at 25, then ended up moving to the US later that year. I'd always been into racing video games. Metropolitan Street Racer on the Dreamcast was one of those games that really sucked me in. It was the precursor to Project Gotham Racing, which was the precursor to essentially Forza Horizon, I think.

Lex Fridman

Oh, okay.

Jason Fried

I think that's how the lineage goes. It's just a great game. I actually fired it up on an emulator a few weeks ago, and it still sort of holds up because it has enough real-car dynamics that it smells a little bit like driving a real car. It's not just an arcade racer like Sega Rally or something like that.

I'd always been into that. Then I got my driver's license at 25 and moved to the US. Two years later, a friend that I'd met in Chicago took me to the Autobahn Country Club, which is this great track about 45 minutes from Chicago.

I sat in a race car and drove a race car for the first time. I had the same kind of pseudo-religious experience that I did when I started working on Ruby. I did maybe 20 laps in what was basically a Mazda race car from the '90s or something—a pretty cheap race car, but a real race car. It was a single-seater with a manual gearbox and exposed slick wheels, all that stuff.

David Heinemeier Hansson

After having that experience, first of all, it was just the most amazing thing ever. The physical sensation of driving a race car is really unique. If you're in a fast car, you have maybe a 2% taste of it. The exposure to the elements that you get in a single-seat race car, especially one like that where your head is actually out in the elements, is completely different. You can see the individual wheels, and your sensation of speed is so much higher. It's at a completely different level.

Lex Fridman

Can you actually speak to that? Even in that Mazda, what can you feel? Can you feel the track reverberating? Can you feel the grip? You can not only see the bumps because you're literally looking straight at the wheel, you can feel all the bumps because you're running a slick tire. It's a really stiff setup. It's nothing like taking a fast street car out on a racetrack and trying to drive around a little bit.

So, can you feel the slipping?

David Heinemeier Hansson

That's a huge part of the satisfaction of driving a race car: driving it at the edge of adhesion, as we call it, where the car is actually sliding a little bit. A couple of degrees of slip angle is the fastest way to drive a race car. You don't want to slide too much. That looks great—lots of smoke—but it's not fast.

You want to drive it right at the limit of adhesion, rotating the car as much as your tires can manage and then slightly more than that, and playing at it, keeping it just at that level. When you're at the limit of adhesion, you're essentially just a tiny movement away from spinning out. It doesn't take much. Then the car starts rotating. Once it starts rotating, you lose grip and you're going for the wall.

That balance of danger and skill is what's so intoxicating. It's so much better than racing video games, too, because the criticality is taken up 2 notches. I often think about people who really like gambling, where I think, "Aren't you just playing poker?" And they're like, "No, the point is not poker."

Poker may be part of it, but the point is that I could lose my house, right? That's the addiction that some people get to gambling: there's something real on the line. When you're in a race car, there's something very real on the line. If you get it wrong, at the very least, you're going to spin out and probably hit a wall, and it's going to be expensive. At the very worst, you're not getting out alive.

Even if modern race cars have gotten way safer than they used to be, there is that element of danger that's real. There are people who still get seriously hurt or even killed in a race car. It's mercifully rare compared to what it used to be, when those maniacs in the '60s would do Formula 1, and 13% of the grid wouldn't make it to the end of the year because they would die in a fiery flaming fireball. But there's still some of it there.

I think that sense that there's something on the line really contributes to it. But it's more than that. There's also just a physical sensation. There's activation of all your forces. There's the flow, and I think that really cements why I got addicted, because I always loved that flow I got out of programming.

But getting flow out of programming is a very inconsistent process. I can't just sit down in front of a keyboard and go, "All right, let's get the flow going." It doesn't happen like that. The problem has to be just right. It has to meet my skills at just the right moment. It's a bit of a lottery.

In a race car, it's not a lottery at all. You sit down in that car, you turn the ignition, you go out on track, and I get flow virtually guaranteed, because you—or I, at least—need 100% of my brain's processing power to be able to go at the speed I go without crashing. So there's no time to think about dinner tonight, the meeting next week, or the product launch. It's completely Zen, in actually the literal sense of the word.

I think of someone who's really good at meditation. That's probably the kind of state they get into, where it's just clear you're in the now. There's nothing but you and the next corner. That's a really addictive experience.

So after I've had that, I couldn't get enough. I just kept going to the track. Every opportunity I got, every single weekend for about 4 years, I would go to the track. By the end of that time, I finally worked up enough skill and enough success with the company that I could afford to go quote-unquote real racing.

I started doing that. I started driving these Porsches. Then, as soon as I got into quote-unquote real competition, I thought, "I wonder how far you can take this?"

My great hero in racing is Tom Kristensen, fellow Dane, Mr. Le Mans, as they call him. The greatest endurance race in the world, the 24 Hours of Le Mans, has been won more times than any other by Tom Kristensen. He won the race 9 times.

Tom really turned me on to Le Mans. I've been watching Le Mans since, I think, the '80s. I have my earliest memories of watching that on TV. The race has been going since, I think, the '20s, but in the '80s I got into it. Then, in the late '90s and early 2000s, when Tom started winning, I, like pretty much every other Dane, started watching the race almost religiously.

So I thought, "You know what? I want to get to Le Mans." This is the magic thing about racing: if I get into basketball, I can't set a realistic expectation that I'm going to play in the NBA or go to the finals. If I get into tennis, I'm not going to play at Wimbledon. That just doesn't happen.

But racing is special in this way because it requires a fair amount of money to keep these cars running. It's really expensive. It's like having a small startup. You need to fly a bunch of people around the world and buy expensive equipment and so forth, so you need a bunch of capital. I had some through the success of the company, so I could do it, which meant that I could get to Le Mans.

I set that as my goal. I wanted to get to Le Mans. I started racing in real competition in 2009, and 3 years later, in 2012, I was at the grid of Le Mans for the first time.

Lex Fridman

We should say, the Le Mans 24-hour endurance race—I mean, this is insane.

David Heinemeier Hansson

There are 3 drivers, mind you, so it's not like one guy is driving for 24 hours straight, but still, it's a pretty tough race, both physically and mentally, especially mentally, when you've been up for 24-plus hours. You're not quite as sharp as when you first wake up.

This is funny about Le Mans, too: it starts at around 4:00 in the afternoon. You've already been up for half a day by the time the race starts, and then there's 24 hours to go before you're done. You'll be in the car for anywhere from usually an hour and a half to a maximum of 4 hours. The regulations say 4 out of 6 is the maximum you can do.

I've spent perhaps 2 and a half hours in a single stint at Le Mans. It's pretty taxing. You're going 200 kilometers an hour into some of these turns, and there's another 60 cars on track whenever I'm in my normal category, which is the LMP2 category. I have GT cars, which are more like Ferraris and Porsches, that I have to overtake. Then I have these hypercars, which are the top class, overtaking me.

So you've got a lot going on, and you've got to stay sharp for 2 and a half hours straight to do that. That is just a guaranteed way to get incredible flow for long, long stretches of time. That's why you get addicted to it.

Lex Fridman

You've got to talk me through this video. This video of you in these LMP2s—this is such a cool—this is so cool.

David Heinemeier Hansson

Yeah. This was probably my favorite battle of my career.

And Hansson has been fighting.

Lex Fridman

You're on the outside here.

David Heinemeier Hansson

I'm on the outside, in the blue and white.

Lex Fridman

And we go a whole track around with basically a piece of paper between us.

David Heinemeier Hansson

See, down this back straight, I get so close to him because I want to force him over on the other side of the track, such that he can't just box me in. We've been fighting already at this point for basically 40 minutes straight. I've been managing to keep this professional driver behind me for 40 minutes, and he finally passes me. But we just keep the battle on for the whole time.

It really just shows both these kinds of cars, the Le Mans prototypes. We don't actually ever touch.

Lex Fridman

We get within about an inch.

David Heinemeier Hansson

We keep going around the Shanghai circuit, too.

Lex Fridman

How did you get so good? I mean, that's a fascinating story, right? That you were able to get so good.

David Heinemeier Hansson

I'm pretty good for the kind of driver I am, which is called a gentleman driver. That means I'm not a professional driver. Like many good gentleman drivers, when we're at our very best, we can be quite competitive with even professional drivers who have been doing this their whole life.

The difference between us and the professionals is that the professionals can do it every time, or more or less every time. I can't be this good all the time. When everything is just right, I can be competitive with professional drivers, but that's not how you win championships. That's not how you get paid by factories to drive. You've got to be good every time you go out. That's a huge difference.

Some of it was also just that I really put my mind to it. By the time I realized race cars were what I wanted to do as my serious hobby, I had put in thousands of hours.

Lex Fridman

Have you crashed? What's the worst crash?

David Heinemeier Hansson

I've had a lot of crashes, but thankfully—knock on wood—I haven't had any crashes where I've gotten seriously hurt.

Lex Fridman

Have you wrecked the car?

David Heinemeier Hansson

Oh, yes. Oh, yes. I've wrecked many a car.

Lex Fridman

So what does that feel like? You just wreck a car. How does it feel?

David Heinemeier Hansson

It feels like total shit if you're in a real race and other people depend on you. It's not even so much the car, although it's also sometimes that these cars are expensive to repair, and that sucks. It feels so wasteful in a way when you crash some of these cars.

But the sense that you're letting a team down—that's what really gets to you. Endurance racing is a team sport. Not only do you have your mechanics, you usually have co-drivers. So when I crash, I just feel like, "Damn it, I could have avoided this."

Lex Fridman

Yeah, but also, you could have died.

David Heinemeier Hansson

Do you know what's funny? I never think about that. I don't think you can, because I think the moment you start thinking about being able to die, you can't do it. You can't go fast.

Lex Fridman

Well, I'm sure—not to go all Carl Jung and Freud here—but that's always present in the back of your mind somewhere. You're just not bringing it to the surface.

David Heinemeier Hansson

It is, in the sense that it's part of the appeal. It's part of the sense that there's something on the line, that this isn't just virtual. I can't just hit reset, restart, reboot.

Lex Fridman

If I crash this car—

David Heinemeier Hansson

We're going to be out, or we're going to be disadvantaged, or it's going to get destroyed, or I might get hurt. I've gotten lightly hurt a few times.

The year we won the 24 Hours of Le Mans in our class, I'd been training in this Formula Renault 3.5 car. It's a really fast car. It's a really nice exercise to do, but it also doesn't have power steering.

Some of these race cars, especially the open-seaters, don't have power steering, which means that the steering wheel is basically directly connected to the front wheels. If you crash one of those cars and the front wheels suddenly turn, you're really going to hurt your hands if you don't get your hands off the wheel.

I hadn't raced enough of those cars to know that I had to get my hands off the wheel, or to have developed the instinct to do so. So I didn't, and I really hurt my hand. This was just, I think, a month before the 24 Hours of Le Mans.

So I thought, “Oh, man, I’m going to have to miss it this year.” It wasn’t a cast; it was just seriously sprained. Then, somehow, miraculously, a week before the event, I was like, “Yeah, actually, it’s okay now.” So I got to do it, and that would have been grave regret if I had seen my team go on to win the race and had to sit on the sidelines.

But I really have been quite fortunate in the sense that most of my crashes have just been expensive or sportingly inconvenient. They’ve never been something where I got seriously hurt. But I’ve seen plenty of people who have.

In fact, my co-driver this year and for several years, Pietro Fittipaldi, drove a race car at Spa. Spa is one of the great racetracks of all time, and it has this iconic corner called Eau Rouge, which is probably the most famous corner in all of motorsports. It has a great compression before you climb uphill. It’s an extremely fast, very difficult corner.

Just as he does the compression, his car basically steps out, he loses his power steering, and he drives straight into the wall and breaks both his legs, basically facing the prospect that maybe his career was over. I’ve had other teammates and people I know have serious injuries that have really hurt them.

And yet, what’s funny is, you’d think that would sink in. The year before we won in 2014, that same car had a Danish driver in it at Le Mans, at the race I was driving in, who died. He lost control of the car when there was a bit of rain on the track, and the track was unfortunately designed in such a poor way that there was a very big tree right behind the railing. He hit that tree at full speed, pulled 90 Gs, and was dead on the spot, which was just such an extremely awful experience to go through.

I finished second that year, which should have been cause for a bunch of celebration, but it was just tainted by the fact that not only did a driver die, a fellow Dane died—a guy I knew died. That was pretty tough. So that throws that into the pile of things that have to be considered: the weather conditions on the track, whether it’s dry or wet. It’s a huge part of it.

Even just last year at Le Mans, it was raining and I was out, and I hadn’t made a serious mistake at the 24 Hours of Le Mans since I did the first race in 2012, where I put it in the gravel trap with about 4 hours to go. We lost a couple of laps getting pulled out, but it didn’t actually change anything for our result because that was just how the field was spread out. I’d made minor mistakes over the years, but nothing that really set us out.

At the race last year, when it was raining, I first clobbered a Ford Mustang when I made an overambitious pass on a damp part of the track and couldn’t stop in time. I felt absolutely awful as I sat in the gravel trap for 2 laps and knew that our race was over—a race where we were highly competitive. You’re not blessed with a competitive car, a competitive team, and a competitive setup every year. I know how rare that is.

So to know that we had a chance that year and I sort of squandered it felt really bad, but that got compounded. I got back on track, barely made it another stint, and then put it in the gravel trap again when it started raining on the entrance into Porsche.

Lex Fridman

So this is part of why racing is so addicting, too, because the highs are very, very high. When you win a race like the 24 Hours of Le Mans, it feels just incredible. There’s so much emotion, but if you fuck it up, the lows are very, very low.

What are the things you’re paying attention to when you’re driving? What are the parameters? What are you loading in? Are you feeling the grip? Are you basically increasing the speed and seeing what effect it has on the grip—a constant feedback system? You’re trying to manage that, trying to find that optimal slip angle.

Are you looking around using your eyes? Are you smelling things? Are you listening? Are you feeling the wind? Are you looking at the field, too? How did you not hit that guy at all? You get close within inches, right? So you have to pay attention to that, too.

David Heinemeier Hansson

It’s really interesting about that specific battle where we’re literally a few inches apart. I can’t fully explain it, but humans can develop an incredible sense of space. I can’t see the edge of the back of my car, but I can know exactly where it is. I can have a mental model in my head that gives me the exact dimensions of this car, such that I can run within a few inches of a competitor’s car or within a few inches of the wall and not hit either when things go well.

The car is about 2 m wide and it’s quite long, 5 m, and you can’t see everything. The mirrors are actually kind of shit. There’s no rearview mirror in these cars. You can’t see out the back; you can only see through your 2 side mirrors. But you form this intuitive mental model when you get good enough at this.

What I actually pay attention to most is that I run a program. What I try to do when I go to a racetrack is load up the best program I know how for every single corner. What’s my brake point? What’s my acceleration point? What’s my brake-trailing curve? I try to pick up that program in part just by finding it myself and seeing how fast I can go, but even more so by copying my professional co-drivers.

I usually race with a pro, and modern race cars produce an absolutely enormous amount of data. You can analyze all that data after each outing. You can see an exact trace of how much you pushed the brake pedal, how much you did in terms of steering inputs, and when you got on the gas. You can see that every millisecond you’re losing is evident in those charts.

So what I try to do is look at the chart and then load that in. That’s what I’ve got to do. In corner 17, I actually have to be 10 bar lighter on the brake. So I try to load that program in and then repeat it.

Then there are all the things that change. Your tires change quite a lot. These tires are made to only last 40 minutes in many cases. At some tracks, they’ll last as little as 40 minutes before they really fall off. So you’ve got to manage that—the grip is constantly changing. Your program has to suddenly fit those changing circumstances.

And then in endurance racing, you’re constantly interacting with other cars because you’re passing slower classes or getting passed by a faster class. So that’s part of the equation. Then you’re trying to dance the car around the limit of adhesion. You’ve got all those factors playing at the same time.

But above all else for me is to try to become a robot. How can I repeat this set of steps exactly as I’m supposed to for 2.5 hours straight without making 100 milliseconds’ worth of mistakes?

Lex Fridman

Yeah. Low-latency algorithm.

David Heinemeier Hansson

That’s really a huge part of it, actually. Your latency is enormously important in terms of being able to catch when the car starts slipping. You get this sensation in your body that the G-forces are a little off, the slip angle is a little off, and then you have to countersteer.

Obviously, the best race car drivers just feel it intuitively. I have some intuition; I don’t have all of it. So I do occasionally spin my car, but that’s the challenge.

Lex Fridman

From everything you’ve studied and understand, what does it take to achieve mastery in racing? What does it take to become the best race car driver in the world?

David Heinemeier Hansson

Obsession is part of it. When I read and hear about Senna and the other greats, they were just singularly focused. Max Verstappen is the current world champion, and he is the same kind. Max has been fascinating to watch. He’s a phenomenal race car driver, but he also literally does nothing else. When he’s not at the racetrack, he’s doing sim racing. He’s literally in video games doing more racing when he’s not doing all the racing he’s already doing.

Lex Fridman

Is there a specific skill they have that stands out to you as supernatural through all that obsession? What is it? Is it a bunch of factors, or are they actually able to, like you said, develop a sense? Is it that they’re able to get to the very edge of the slip?

David Heinemeier Hansson

They’re able to develop very finely tuned sensibilities for when the car is sliding. They can feel just these tiny moments or movements in the chassis that transmit up, usually through their ass. That’s why you call it a butt meter, and you feel like the car is loose or that you’re just about to lock up. You can really hone that tuning.

Then the other thing is, you have to have really good reaction time. When you look at great Formula 1 drivers, they generally have a reaction time of just under 200 milliseconds, which is awesome. Even a 10-millisecond difference makes a huge difference.

You’ll see it when, on the Formula 1 grid, for example, they do a standing start and you see the 5 red lights come on. When the last light goes out, they’re supposed to release the clutch and get going. They can time this, so you can see exactly who has the best reaction time. Even being off by 20 milliseconds can make the difference between whether you’re in front or behind at the first corner.

Lex Fridman

How much of winning is also just the strategy of jostling for position?

David Heinemeier Hansson

There’s some of that, and some of it is also just nerve. Who wants it more? That’s exactly when that sense of danger comes in.

There’s a great quote from Fernando Alonso when he was driving at Suzuka against Schumacher. I think they were coming up to this incredibly fast corner. It’s very dangerous. Alonso basically recounts, “I was going to make the pass because I knew he had a wife and kids at home.”

Lex Fridman

That’s so gangster.

David Heinemeier Hansson

Just absolutely rude. Right?

Lex Fridman

Wow.

David Heinemeier Hansson

I knew he valued life more than I did. So there’s a bit of poker sometimes in that.

Who's going to yield? There's a bit of a chicken race in that regard. Sometimes it doesn't work: no one yields, and you both crash. But very often, one person will blink first.

Lex Fridman

Can the pass be both on the inside and the outside, or is—

David Heinemeier Hansson

You can pass wherever you want, as long as you have just a slight part of the car on the racetrack.

Lex Fridman

And then you just improvise and take risks. What a sport. And then Senna, of course, is a legendary risk-taker.

David Heinemeier Hansson

Yes. Even before him—by the time we got to the 90s, racing was already a lot safer than it was when Niki Lauda raced in the 70s. That level of danger is no longer there. There's still just a remnant of it, and it is still dangerous, but nothing like that.

It's a little hard to compare through the ages, like who's the greatest driver of all time. I think there's a fair argument that Senna is, but we don't have the data. We don't know who he was up against. How would he fare if we pitted him against Max Verstappen today?

I do think sometimes that you can have a bit of nostalgia for the all-time greats, but the world moves forward and new records are being set all the time. The professionalism keeps improving, sometimes to the detriment of the sport. I think there are a lot of professional drivers who are not only very good at driving, but are also very good at being corporate spokespeople.

It used to be quite different. There used to be more characters in racing who had a bit more personality and were allowed to shine, because there weren't a billion sponsorships on the line that they were afraid to lose.

Lex Fridman

Ridiculous question: what's the greatest car ever made? Or maybe, what's the most fun one to drive?

David Heinemeier Hansson

The greatest car for me of all time is the Pagani Zonda S.

Lex Fridman

Okay, I'm looking this up. Pagani Zonda.

David Heinemeier Hansson

The Pagani Zonda S was made by this wonderful Argentinian called Horacio Pagani.

My God, that's a beautiful car. Wow.

It's a gorgeous car. You can look up mine. It's the Pagani Zonda HH.

So, that's a car I had made in 2010 after we visited the factory in Modena and, by sheer accident, ended up with this car. But it became my favorite car in the world, basically, when I watched an episode of Top Gear, I think in 2005, where one of the presenters was driving the Pagani Zonda F around. I just thought, “That's the most beautiful car in the world. It is the most incredible-sounding car in the world. If I one day have the option, this is what I want.”

Then I had the option in 2010. I've had the car ever since. I'm never, ever going to sell it. It's truly a masterpiece that has stood the test of time. There are some great cars from history that are recognized as being great in their time. This car is still great.

Lex Fridman

Have you taken it on the racetrack?

David Heinemeier Hansson

I have. It's terrible at that, but I don't want to say it's terrible at that. That's not what it's designed for. It's designed for the road, and that's why it's great.

There are a lot of fast cars that are straddling the line between a race car and a road car. You don't actually want a race car for the road. A race car for the road is a pain in the ass. It's way too stiff, way too loud, and way too uncomfortable. You can't actually take it on a road trip.

Lex Fridman

So, this actually feels good driving.

David Heinemeier Hansson

Totally.

Lex Fridman

And you, of course, always go to the speed limit.

David Heinemeier Hansson

Always. This is why I love having this car in Spain, because they're a little more relaxed. Not entirely relaxed, but more relaxed than they are in a lot of places. In Denmark, I kid you not, if you're on the highway and you go more than twice the speed limit, they confiscate your car and keep it.

Lex Fridman

You're not getting it back. They don't even care if it's your car or not. If you were borrowing my car and you went twice the speed limit, it's gone.

David Heinemeier Hansson

They don't do that in Spain. In most places, except for the German Autobahn, they get pissy if you go twice the speed limit, for all sorts of fair reasons. I'm not advocating that you should be going much more than that. But there are certain special roads where you can open things up and no one's in harm's way. That's an incredible sensation.

I do think that some of those speed limits are actually kind of silly, and I'm not just saying that in a vacuum. In Germany, they have the glorious Autobahn. On the Autobahn, there is no speed limit in a bunch of segments, and they're so committed to their speed-limitless Autobahn, which is, by the way, very weird of Germans. They usually love rules. They're usually very precise, and then they have this glorious thing called the Autobahn.

There was a great case a couple of years ago where a guy took out a Bugatti Chiron, went 400 kilometers an hour on the Autobahn, filmed it, and put it on YouTube. A case was brought against him because, even though they don't have a speed limit, they do have rules that you can't drive recklessly. He won the case. He wasn't driving recklessly; he was just going very, very fast.

I've done the Autobahn a couple of times. My wife and I went on a road trip in Europe, and I got the Lamborghini Gallardo. We were driving up to 200 miles an hour. I'd driven 200 miles an hour, or close to it, on a racetrack before. That feels like one thing. Driving on a public road at 200 miles per hour feels really, really fast.

Lex Fridman

Scary.

David Heinemeier Hansson

Actually, a little scary. Yes, because you constantly think, on a racetrack, you know the road and you know the surface. You can walk the track most of the time. You can know if there's a dip. On a public road, you can't know if there's suddenly a pothole.

Presumably, there's not going to be a pothole on the German Autobahn, but it does feel a little scary and also exhilarating. Speed is just intrinsically really fun. I don't know anyone I've taken out in a fast car—well, actually, I do know a few people. Most people that I take out in a fast car grin. It's just a human reaction to grin when you go really fast.

Lex Fridman

Do you know what the fastest you've ever gone is?

David Heinemeier Hansson

It was probably at Le Mans. When the LMP2s were at their maximum power and had 600 horsepower and really sticky tires, we were going 340 kilometers an hour, which is just over 200 miles per hour. A bit over 200 miles per hour. That does feel fast.

It's really interesting with speed: the difference between going, let's say, 150 and 160 doesn't feel that much—actually, those 10 miles per hour—but the difference between going 190 and 200 feels crazy faster. As a percentage change, that's actually less than going from 150 to 160, but there's some sense of exponentiality once you get up to those limits, where it's just on a completely different level.

Lex Fridman

Yeah, because to me, 110 or 120 feels fast. 200—that's crazy. It really is crazy.

I've got to ask you about the details of your programming setup—the IDE, all that kind of stuff. Let's paint a picture of the perfect programming setup. Do you have a programming setup that you enjoy, or are you very flexible? How many monitors? What kind of keyboard, chair, and desk?

David Heinemeier Hansson

It's funny, because if you'd asked me a year and a half ago, I would have given you the same answer as I would have given anyone for basically 20 years: I want a Mac. I like the Magic Keyboard. I like the single monitor.

Apple makes an awesome 6K, 32-inch XDR screen that I still haven't found anyone who's beaten. I still use it, even though I switched away from Apple computers, because it's just fantastic. I've always been a single-screen kind of guy. I do like a big screen, but I don't want multiple screens. I've never found that it really works with my perception. I want to be able to focus on a single thing. I don't want all of it spread out all over the place.

I've always used multiple virtual desktops and been able to switch back and forth between those things. But the setup I have today is Linux, which I switched to a little over a year ago after I finally got fed up with Apple enough that I couldn't do it anymore.

I use this low-profile mechanical keyboard called the Lofree Flow 84, which is just the most glorious-sounding keyboard I've ever heard. I know there are a lot of connoisseurs of mechanical keyboards who will probably contest me on this: “It's too thocky, or too clicky, or too clacky,” or whatever. But for me, the Lofree Flow 84 is just a delight that I didn't even know existed.

It's so funny, because I've been programming for a long time. Mechanical keyboards have been a thing for a long time. When you look at the keyboard like this, it just looks plain. It doesn't look extravagant, but the tactile sensation you get from pushing those keys and the thocky sound you hear when the keys hit the board is just sublime.

I'm kicking myself that I was in this Mac bubble for so long that I wasn't even in the market to find this. I knew mechanical keyboards existed, but, to be blunt, I thought it was a bit of a nerd thing that only real nerds who were much more nerdy than me would ever care about.

Then I got out of the Apple bubble and suddenly I had to find everything again. I had to find a new mouse, a new keyboard—I had to find everything. I thought, “All right, let me give mechanical keyboards a try.” I tried quite a few of them.

Keychron is one of the big brands in that space. I didn't like that at all. I tried a bunch of other keyboards, and then I finally found this keyboard and just went, “Angels are singing. Where have you been my whole life?”

We spend so much of our time as programmers interacting with those keys. It really matters in a way I didn't fully appreciate. I used to defend the Apple Magic Keyboard. It's a great keyboard. For what it is—this ultra-low-profile, ultra-low-travel keyboard—it's actually a really nice keyboard.

But once you've tried a longer-travel mechanical keyboard, there's no going back.

Lex Fridman

You do have to remember, in many ways, both on the software side and the hardware side, that you do spend a lot of hours—

David Heinemeier Hansson

Yes.

Lex Fridman

—behind the computer. It's worth—

David Heinemeier Hansson

It's worth investing in.

Lex Fridman

And also worth exploring until you find the thing where the angel starts singing, or whatever.

David Heinemeier Hansson

That's exactly right. And I actually do regret that a little bit, especially with this damn keyboard. I could have been listening to these beautiful, thocky keys for years and years, but sometimes you have to get really pissed off before you open your eyes and see that something else exists.

I feel the same way about Linux. I've been using Linux on the server since the late 1990s, probably. We ran servers on Linux back then. I never seriously considered it as a desktop option. I never ran Linux directly myself.

I always thought, "You know what? I just want to focus on programming. I don't have time for all these configuration files and all this setup bullshit and whatnot." Apple is close enough. It's built on Unix underpinnings. Why do I need to bother with Linux?

Again, it was one of those things where I needed to try new things and try something else to realize that there are other things besides Apple. It's not because I hate Apple. I think they still make good computers. I think a lot of the software is still also pretty okay, but I have come to realize that, as a web developer, Linux is just better.

Lex Fridman

Yeah.

David Heinemeier Hansson

Linux is just better. It's closer to what I deploy on. The tooling is actually phenomenal. If you spend a bit of time setting it up, you can create a reproducible environment. I've now done that with this Omakub concept or project that I've done, and I can set up a new Linux machine in less than 30 minutes and it's perfect.

It's not pretty good. It's not like I still need to spend 2 hours on it. It's perfect, because you can encode all aspects of the development environment into this. I didn't even know, to be fair, that Linux could look as good as it can.

If you look at a stock Ubuntu or Fedora, not that it's ugly, but I'd pick the Mac any day of the week. You look at—I mean, I'm biased here, of course, because I built it with my own sensibilities—but I look at that and go, "This is better. This is beautiful."

Then you look at some of those true Linux ricing setups, where people go nuts with everything, and you go, "Oh yeah, I remember when computers used to be fun in this way, when there was this individuality and this setup, and it wasn't just all bland sameness."

I think that's a flip side sometimes of something like Apple, where they have really strong opinions and they have really good opinions. They have very good taste, and it looks very nice, and it also looks totally the same. Linux has far more variety and far more texture and flavor. Sometimes also annoyances and bugs and whatever.

But I run Linux now. It's Ubuntu-based with the Omakub stuff on top. The low-profile keyboard. I use a Logitech MX Master 3S mouse, which I love how it feels in my hand. I don't love how it looks.

I actually was a Magic Mouse stan for the longest time. I thought it was genius that Apple integrated the trackpad into a mouse, and I used that. I always thought it was ridiculous that people would slag it just because you had to charge it by flipping it over, because the battery would last for 3 months and then you charge it for half an hour.

I thought, "That's a perfect compatibility with my sensibilities." I don't mind giving up a little inconvenience if something is beautiful, and that Magic Mouse is beautiful. But it wasn't going to work on Linux, so I found something else. The MX Master 3S is nice, but I sometimes do wish the Magic Mouse was pretty good.

Lex Fridman

Yeah, Linux is really great for customizing everything—for tiling, for macros, for all of that. I also do the same in Windows with AutoHotkey, or just customize the whole thing to your preferences.

David Heinemeier Hansson

If you're a developer, you should learn how to control your environment with the keyboard. It's just faster. It's more fluid. I think one of the silly things I've come to truly appreciate about my Omakub setup is that I can, in whatever time it takes to refresh the screen—probably 5 milliseconds—switch from one virtual desktop to another.

Lex Fridman

Even on Windows, you can't get it that smooth.

David Heinemeier Hansson

You can get close; you can't get it that smooth. On macOS, for whatever reason, Apple insists on having this infuriating animation when you switch between virtual desktops, which makes it so you don't want to run full-screen apps because it's too cumbersome to switch between the virtual desktops.

The kind of immediacy that you can get from a wonderful Linux setup in that regard is just next level.

Lex Fridman

Yeah. It seems like a subtle thing, but the difference in milliseconds and latency between switching the virtual desktops, for example, I don't know—it changes—

David Heinemeier Hansson

It changes how you use the computer. It really does.

Lex Fridman

Similar thing with VR right there. If there's some kind of latency or—

David Heinemeier Hansson

It just completely takes you out of it.

Lex Fridman

It's funny, I actually had to watch—I think it was ThePrimeagen on YouTube—when he was showing off his setup, and I was seeing how quickly he was switching between those virtual desktops. I'd always been using virtual desktops, but I didn't like switching too much because of that latency. It's like, "Oh, you can do that on Linux. Oh, that's pretty cool."

David Heinemeier Hansson

Yeah. So I run that. And then my editor of choice now is Neovim.

Lex Fridman

Oh, good. All right. Well, we're out of time. No. All right. You did, for many, many years, use—what is it?—TextMate.

David Heinemeier Hansson

Yes, TextMate. That was actually the main blocker of moving away from Apple.

Everything else I thought, "Do you know what? I can swing it." But TextMate was and is a wonderful editor, one I helped birth into this world. The programmer Allan Odgaard is a good friend of mine, all the way back from those party days when we were lugging our computers around. He was a big Mac guy, and in 2005 he was writing this editor.

I helped him with the project management of keeping him on track, keeping him focused on getting something released, because I really wanted it for myself. I thought this was the last editor. I thought I was never going to switch.

Lex Fridman

Forgive me for not knowing, but how featureful is this editor? Is this—

David Heinemeier Hansson

It's quite featureful, but it's a GUI-driven editor in some regards. It was really early on with ways of recording macros and having sophisticated syntax highlighting, and it did a bunch of firsts. It was just a really pleasant editing experience.

I think these days a lot of people would just use VS Code. VS Code exists in the same universe as TextMate in some ways, and actually I think it's compatible with the original TextMate bundles, the original TextMate format. So it really trailed a path there, but it also just didn't evolve.

A lot of people saw a huge problem with that. They were like, "Oh, it needs to have more features. It needs to have all these things." I was like, "I'm happy with this text editor that hasn't changed at all," basically when Allan stopped working on it for a decade or more.

I don't need anything else because, as our original discussion went, I don't want an IDE. I don't want the editor to write code for me. I want a text editor. I want to interact with characters directly.

Neovim allows me to do that in some ways that are even better than TextMate. I love TextMate. But Vim, as you know, once you learn the commands—and it sounds, I sometimes feel like Vim fans overplay how difficult it is to learn because it makes them perhaps seem more awesome that they were able to do it.

It's not that difficult, and it doesn't take that long, in my opinion, to learn just enough combo moves to get that high of, "Holy shit, I could not do this in any other editor."

Lex Fridman

How long did it take you? And by the way, I don't know. I'm still—I haven't yet. Well, I know intellectually, but just like with kids, I haven't—

David Heinemeier Hansson

You haven't—

Lex Fridman

I haven't gone all the way in. I haven't used them.

David Heinemeier Hansson

You have a treat in store. Well, when I switched about a year ago, I had 3 days of cursing where I thought it was absolutely terrible and it was never going to happen. I had 3 days of annoyance, and already the next week I was like, "This is sweet. I'm not going anywhere."

Lex Fridman

Oh, wow.

David Heinemeier Hansson

But I also had a bit of a head start about 20 years ago, in the early 2000s. I tried Vim for a summer and it didn't stick. I didn't, for whatever reason, love it at the time. But Neovim is really good.

The key to Neovim is to realize that you don't have to build the whole damn editor yourself. A lot of Neovim stans are like, "Here's how to write the config from scratch over 17 episodes. It's going to take you 3 weeks."

I don't care that much. I love a great editor. I love to tailor it a little bit, but not that much. So you have to pair Neovim with this thing called LazyVim.

Lex Fridman

LazyVim.org is a distribution for Neovim that takes all the drudgery out of getting an amazing editor experience right out of the box.

Ridiculous question. We talked about a bunch of programming languages. You told us how much you love JavaScript. It's your second-favorite programming language. Would TypeScript be the third, then?

David Heinemeier Hansson

TypeScript wouldn't even be in this universe. I hate TypeScript as much as I like JavaScript.

Lex Fridman

So, what do you hate? Oh, man. I'm not smart enough to understand the math of that. Okay. Before I ask about other programming languages, if you can encapsulate your hatred of TypeScript into something that could be human-interpretable, what would be the reasoning?

David Heinemeier Hansson

JavaScript smells a lot like Ruby when it comes to some aspects of its metaprogramming, and TypeScript just complicates that to an infuriating degree when you're trying to write that kind of code.

Even when you're trying to write the normal kind of code, none of the benefits that accrue to people who like it—like autocompletion—is something I care about. I don't care about autocompletion because I'm not using an IDE. Now, I understand that that is part of what separates it and why I don't see the benefits.

I only see the costs. I see the extra typing. I see the type gymnastics that you sometimes have to do, where a bunch of people give up and just do `any` instead, right? They don't actually use the type system because it's too frustrating to use.

I've only ever felt the frustration of TypeScript and the obfuscation of TypeScript in the code, which gave me no payoff. Again, I understand that there is a payoff. I don't want the payoff. For my situation, I'm not willing to make the trade, and I'm not willing to take a language that underneath is as dynamic as Ruby and turn it into this pretend statically typed language. I find that intellectually insulting.

Lex Fridman

Do you think TypeScript will die, and do you think it should die?

David Heinemeier Hansson

I don't want to take something away from people who enjoy it. So, if you like TypeScript, all the more power to you. If you're using TypeScript because you think that's what a professional programmer is supposed to do, here's my permission: you don't have to use TypeScript.

Lex Fridman

There's something deeply enjoyable about a brilliant programmer such as yourself, DHH, talking shit. It's just one of my favorite things in life. What are the top 3 programming languages everyone should learn, if you're talking to a beginner?

David Heinemeier Hansson

I would 100% start with Ruby. It is magic for beginners in terms of understanding the core concepts of conditionals and loops and whatever because it makes it so easy. Even if you're just making a shell program that's outputting to the terminal, getting “Hello, world!” running in Ruby is basically `puts "Hello, world!"`. You're done, right? There's no fluff. There's nothing to wrap your head around.

There are other languages that do that—Perl or Python would be rather similar—but Go would not. Java would not. There are a lot of other languages that have a lot more ceremony and boilerplate. Ruby has none of it, so it's a wonderful starting language. There's a book called Learn to Program by Chris Pine that uses Ruby to teach basic programming principles. I've seen it heavily recommended, so that's a great language.

Lex Fridman

How quickly would you go to Rails?

David Heinemeier Hansson

It depends on what you want to do. If you want to build web applications, go to Rails right away. Learn Ruby along with Rails, because I think what really helps power through learning programming is to build programs that you want. If you're just learning it in the abstract, it's difficult to motivate yourself to actually do it well.

Some people learn languages just for the fun of them. Most people do not. Most people learn them because they have a mission. They want to build a program. They want to become a programmer. So, you've got to use it for something real. I actually find that it's easier to learn programming that way, too, because it drives your learning process.

You can't just learn the whole thing up front. You can't just sit down and read the language specification, then go, “Ooh, like Neo, now I know kung fu. Now I know Ruby.” It doesn't download that way. You actually have to type it out in anger on a real program.

Lex Fridman

Yeah. Yeah. For sure.

David Heinemeier Hansson

So I would start there. Number 2 would probably be JavaScript, because JavaScript is the language you need to know if you want to work with the web. The web is the greatest application platform of all time. If you're making business software, collaboration software, and all this kind of stuff, you need to know JavaScript.

If you're making video games, you should probably go off and learn C++, C, or something else like that. But if you're in the realm of web applications, you've got to learn JavaScript. Regardless of what else you learn, you've got to learn JavaScript.

Lex Fridman

So, if you're learning Ruby, what does Ruby not have in terms of programming concepts that you would need other languages for?

David Heinemeier Hansson

I don't know if there are any concepts missing, but it doesn't have the speed or the low-level access and memory manipulation that you would need to build a 3D gaming engine, for example. No one's going to build that in Ruby. You can build quite low-level stuff when it comes to web technologies in Ruby, but at some point you're going to hit the limit and you should use something else.

I'm not someone who prescribes just Ruby for everything. Once you reach the level of abstraction that's involved with web applications, Ruby is superb. But if you're writing, for example, an HTTP proxy, Go is great for that. We've written quite a few HTTP proxies lately at the company for various reasons, including our cloud exit and so forth. Kevin, one of the programmers I'm working with, writes all of that in Go.

Go just has the primitives, and it has the performance and the speed to do that really well. I highly recommend it. If you're writing an HTTP proxy, do it in Go. Great language for that. Don't write your business logic in Go. I know people do, but I don't see the point in that.

Lex Fridman

So, what would you say the 3 are? Go, Ruby plus Rails, and JavaScript?

David Heinemeier Hansson

Yeah, if you're willing or interested in working with the web, I'd probably pick those 3: Go, Ruby, and JavaScript.

Lex Fridman

Go, Ruby, and JavaScript. Okay. Functional languages. Someone's talking about OCaml.

David Heinemeier Hansson

They're always going to show up. There must be some kind of OCaml industrial complex or something like this, but they always mention OCaml. I love that there are people who love functional languages to that degree. Those people are not me. I don't care at all.

I care about functional principles when they help me in these isolated cases where that's just better than everything else. But at heart, I'm an object-oriented guy. That's just how I think about programs. That's how I like to think about programs. That's how I carve up a big problem space into a domain language. Objects are my jam.

Lex Fridman

Yeah, me too. I programmed in Lisp a bunch for AI applications, basically chess engines and that kind of stuff. I did try, just to force myself, to program a very basic Game of Life simulation. Lisp is just parentheses everywhere. It's actually not readable at all.

David Heinemeier Hansson

That's my beef with Lisp. OCaml is very, very intuitive, very readable.

Lex Fridman

I really should pick up a language like that at some point. I've been programming long enough that it's a little embarrassing that I haven't actually done anything real in anger in a fully functional programming language.

David Heinemeier Hansson

Yeah, but I have to figure out—I'm sure there's an answer to this—what can I do that would be useful for me?

Lex Fridman

Like, that I actually want to build?

David Heinemeier Hansson

That's my problem.

Lex Fridman

That a functional language is better suited for.

David Heinemeier Hansson

That's right.

Lex Fridman

Because I really want to experience the language properly.

David Heinemeier Hansson

That's right.

Lex Fridman

Yeah, because I'm still—at this point, I'm very object-oriented.

David Heinemeier Hansson

Yes.

Lex Fridman

And that's my problem, too. I just don't care as much about these low-level problems in computer science. I care about the high level. I care about writing software. I care about the abstraction layer that really floats well with web applications and business logic. I've come to accept that about myself.

Even though, as we talked about, when I was a kid I really wanted to become a games programmer, I saw what it took to write a collision-detection engine and thought, “Yeah, that's not me at all. I'm never going to be into vector-matrix manipulation or any of that stuff. It's way too much math. I'm more of a writing person than I am a math person.”

I mean, just in the way you were speaking today, you have a poetic, literary approach to programming.

David Heinemeier Hansson

Yes.

Lex Fridman

Yeah.

David Heinemeier Hansson

That's actually exactly right. I did a keynote at RailsConf 10 years ago where I called myself a software writer. I'm not the first person to say that; “software writer” has been in the vernacular for a long time. But the modern identity that most programmers adopt when they're trying to be serious is “software engineer,” and I reject that label.

I'm not an engineer. Occasionally I dabble in some engineering, but the vast majority of the time I'm a software writer. I write software for human consumption and for my own delight.

I can get away with that because I'm working in a high-level language like Ruby, working on collaboration software and to-do lists and all the other stuff. Again, if I was trying to apply my talent to writing 3D game engines, no, that's not the right mindset. That's not the right identity.

I find that the software-engineering identity flattens things a little bit. I'd like to think that we have software writers and software mathematicians, for example. Those are actually richer ways of describing the abstraction level that you're working at than “engineer.”

Lex Fridman

Yeah. And I think if AI becomes more and more successful, I think we'll need software-writer skills more and more, because it feels like that's the realm where it's not writing.

David Heinemeier Hansson

You're going to have to do the software. You're going to have to be a computer person. But there is a more—I don't know, I don't want to romanticize it—but it's more poetic. It's more literary. It feels more like writing a good blog post.

Lex Fridman

I actually wish that AI had a bit higher standards for writing. I find the fact that it accepts my sloppy, incomplete sentences a little offensive. I wish there were a strict mode for AI where it would slap my fingers if I was just feeding it keywords and say, “Speak properly. Do pronunciation. Do punctuation.”

I love that. I love crafting just the right sentence, one that hasn't been boiled down until it has no meat on it or character in it. It's succinct. It's not overly flowery. It's just right. That writing phase, to me, is addictive. I find that when programming is at its best, it's almost exactly equivalent to that.

You also have to solve a problem. You're not just communicating a solution; you actually have to figure out what you're trying to say. Even writing has that. Half the time, when I start writing a blog post, I don't know exactly which arguments I'm going to use. They develop as part of the writing process, and that's how writing software happens, too. You know roughly the kind of problem you're trying to solve; you don't know exactly how you're going to solve it, and as you start typing, the solution emerges.

Actually, as far as I understand, you and Jason are working on a new book. It's in the early days, and it's about that kind of topic. I think he tweeted that it's going to be titled something like “We Don't Know What We're Doing Up Front,” or something like that—that kind of topic, where you figure it out along the way.

David Heinemeier Hansson

That's a big part of it: trying to give more people permission to trust their own instincts and their own gut, and realizing that developing that supercomputer in your stomach is actually the work of a career. You should not discard those feelings in preference to overcomplicated analytics or even intellectualism.

Very often, when we look at the big decisions we've had to make, they've come from the gut, where you cannot fully articulate, “Why do I think this is the right thing?” Well, because I've been in this business for 20 years, I've seen a bunch of things, and I've talked to a bunch of people. That is percolating into this being the right answer.

A lot of people are very skeptical about that in business or unable to trust it because it feels like they can't rationalize why they're doing something. “Why are we doing something?” “Because I feel like it. Damn it.” That's a great privilege of being a bootstrapped, independent founder who doesn't owe their business to someone else and doesn't have to produce a return, because I feel like a lot of the bullshit really creeps in when you're trying to rationalize to other people why you do the things you do and why you make the decisions that you do.

If you don't have anyone to answer to, you're free to follow your gut. That's a hell of an enjoyable way to work, and it's also very often the correct way to work. Your gut knows a lot. You can't articulate it, but it's spot-on more times than not.

Lex Fridman

Yeah. Having to make a plan can be a paralyzing thing. I mean, I suppose there are different kinds of brains. First of all, I can't wait to read that book if it materializes. I often feel like, in the more interesting things I do in my life, I really don't know what I'm doing up front.

I think there are a lot of people around me who care for me and really want me to know what I'm doing. They're like, “What's the plan? Why are you doing this crazy thing?” If I had to wait until I had a plan, I'm not going to do it.

People have different brains on this kind of stuff. Some people really are planners, and maybe it energizes them. But I think most creative pursuits, most really interesting and novel pursuits, are like that. You kind of have to just take the leap and then figure it out as you go.

David Heinemeier Hansson

My favorite essay in Rework is the last one, and it's entitled “Inspiration Is Perishable.” I think that captures a lot of it: if you take the time to do a detailed plan, you may very well have lost the inspiration by the time you're done. If you follow the inspiration in that moment and trust your gut—trust your own competence that you will figure it out—you're going to get so much more back.

You're going to go on the adventure you otherwise wouldn't have. Whether that's just a business decision or a life decision, you have to seize that inspiration. There's a great set of children's books written by a Japanese author about chasing an idea and trying to get a hold of it.

It's beautifully illustrated as an idea, something that's floating around, as something you have to catch and latch onto. I really feel that captures this notion that inspiration is perishable. It'll disappear. If you just put it back on the shelf and say, “I have to be diligent about this. I have to line up a plan,” you may run out, and then there's no steam to keep going.

Lex Fridman

I have to ask you about open source. What does it take to run a successful open-source project? You've spoken about how it's a misconception that open source is democratic; it's actually meritocratic. I thought that was a beautiful way to put it. So there's often a kind of benevolent dictator at the top. Can you just speak to that, having run successful open-source projects yourself and being a benevolent dictator yourself—which is going to be a bit of a biased piece of evidence here?

David Heinemeier Hansson

I think you should definitely have dictators, and they should control everything, especially when the dictator is me. Well, I think I learned very early on that a quick way to burn out in open source is to treat it as a business, as though your users are customers, as though they have claims of legitimacy on your time, your attention, and your direction.

Because I faced this almost immediately with Ruby and Rails as soon as it was released. There were a million people who had all sorts of opinions about where I ought to take it—and not just opinions, but actual demands. “Unless you implement an Oracle database adapter, this is always going to be a toy.”

It was actually more or less that exact demand that prompted me to have a slide at one of the early Rails conferences that just said, “Fuck you.”

Lex Fridman

Yeah, I saw that.

David Heinemeier Hansson

I'm not going to do what you tell me to. I'm here as a bringer of gifts. I am sharing code that I wrote on my own time, on my own volition, and you don't have to say thank you. I mean, it would be nice if you did. You can take the code and do whatever you want with it. You can contribute back if you want, but you can't tell me what to do or where to go or how to act. I'm not a vendor.

This is a fundamental misconception that users of open source occasionally step into because they're used to buying software from companies who really care about their business. I care about people using my software. I think it's great, but we don't have a transactional relationship. I don't get something back when you tell me what to do except grief, and I don't want it. So you can keep it.

My open-source philosophy from the start has been that I have to do this primarily for me. I love when other people find use in my open source. It's not my primary motivation. I'm not primarily doing it for other people. I'm primarily doing it for me and my own objectives, because, as Adam Smith said, it's not from the benevolence of the butcher that we expect our daily meat; it's from his self-interest.

I actually find that to be a beautiful thought: our commons increase in value when we all pursue our self-interest, certainly in the realm of open source. This is also why I reject this notion that open source is in some sort of crisis, that there's a funding crisis and we have to spend more. No, we don't. Open source has never been doing better. Open source has never controlled more domains in software than it does right now. There is no crisis.

There's a misconception from some people making open source and from a lot of people using open source that open source is primarily like commercial software—something you buy and something where you can then make demands as a customer—and that the customer is always right. The customer is not always right, not even in business, but certainly not in open source.

In open source, the customer, as it is, is a receiver of gifts. We are having a gift exchange. I show up and give you my code. If you like it, you can use it. If you have some code that fits in with where I'm going with this, I would love to get those gifts back. We can keep trading like that. I give you more gifts; you give me some of your gifts. Together, we pull all the gifts such that someone showing up brand new just gets a mountain of gifts.

This is the magic thing about open source: it increases the total-sum value of what's in the commons when we all pursue our own self-interest. I'm building things for Rails that I need. You know what? You want me to do that. You do not want me to build things that I don't need on behalf of other people, because I'll do a crap job.

I build much better software when I can evaluate the quality of that software by my own use. I need this feature. I'm going to build a good version of that feature, and I'm going to build just enough, just for me. So I'm not going to bloat it. I'm not trying to attract a customer here. I'm not trying to see some angle. I'm just building what I need.

If you go into open source with that mentality—that you're building for you and everything else is a bonus—I think you have all the ingredients to go the distance. I think the people who burn out in open source are the ones who go in thinking, “I'm making all these gifts. I don't really need them myself, but I'm hoping someone else does, and maybe they'll also give me some money.”

That's a losing proposition. It never basically works. If you want money for your software, you should just sell it. We have a perfectly fine model of commercial software that people can make and then sell.

But I find a lot of confusion—let's just call it that politely—in open-source contributors who want to have their cake and eat it, too. They like the mode of working with open source. They may even like the status that comes from open source, but they would also like to earn a living from making that open source.

Therefore, they occasionally end up with the kind of grievances that someone who feels underappreciated at work will develop when others aren't doing enough to recognize their great gifts, and then they might walk away.

Lex Fridman

I wish I had more insight into the mind-state of the individual people who are running these projects—if they're feeling sad, if they need more money, or if they're burned out. It's just such a dark box.

David Heinemeier Hansson

It can be.

Lex Fridman

I mean, of course, there's some communication, but I sadly see too often that they just walk away.

David Heinemeier Hansson

Right? And I think that's actually also part of the beauty of open source. You are not obligated to do this code forever. You're obligated to do it for as long as you want to do it. That's basically your own obligation.

Lex Fridman

But there is—I know, you might criticize this and push back. You did write a blog post, “Forever, Until the End of the Internet,” with Ta-da List. There is a beautiful aspect, and you found a good balance there. But I don't know, you're bringing so much joy to people with this thing you created. It's not an obligation, but there's a real beauty to taking care of this thing you've created and not forgetting.

I think what the open-source creator is not seeing enough is how many lives you're making better. There are certain pieces of software that I just quietly use a lot. They bring my life joy, and I wish I could communicate that. Well, there are ways to donate, but it's inefficient. It's usually hard to donate. There are some ways for some people that have made it easier. GitHub Sponsors is one way of doing it.

I donate to a few people, even though I don't love the paradigm. I also accept that we can have multiple paradigms. I accept that I can do open source for one set of motivations and other people can do open source for other motivations. We don't all have to do it the same way.

But I do want to counter the misconception that open source is somehow in a crisis unless we all start paying for open source. That model already exists. It's commercial software. It works very well, and plenty of great companies have been built off the back of it, and the expectations are very clear: I pay you this amount, and I get this software.

Open source, once you start mixing money into it, gets real muddy real fast. A lot of it is just from those misaligned expectations: if you feel like you're a starving artist as an open-source developer and you are owed X amount of money because your software is popular, you're delusional and you need to knock that off.

Just get back on track where you realize that you're putting gifts into the world. If you get something back in terms of monetary compensation, okay, that's a bonus. But if you need that money back in terms of monetary compensation, you should just charge for software or go work for a software company that will employ you to do open source. There's tons of that. That is probably actually the primary mode that open-source software is being developed in the world today: commercial companies making open source that they need themselves and then contributing it back.

So I'm glad you brought—sort of drew some hard lines here. This is a good moment to bring up what I think is maybe one of the greatest open-source projects ever: WordPress. You spoke up in October about some of the stuff that's been going on with WordPress's founder, Matt Mullenweg, in a blog post, “Open Source Royalty and Mad Kings.” It's a really good blog post on the idea of benevolent dictators for life, this model for open-source projects.

The basic implication was that Matt, as the BDFL of WordPress, has lost his way a bit with his battle with WP Engine. I should also say that I really love WordPress. It brings me joy. I think it's really a beacon of what open source could be. Matt has made the internet better. It allowed a lot of people to create wonderful websites.

I also think—now, you might disagree with this, but from everything I've seen, WP Engine just gives me bad vibes. I think they're not the good guy in this. I don't like it. I understand the frustration. I understand all of it, but I don't think that excuses the behavior.

There is a bit of—see, this is kind of counter to a little bit of what you said—which is, when you have an open-source project of that size, there is a bit of responsibility. When you're the king of a kingdom that large, there's a bit of responsibility anyway. Could you speak to your empathy for Matt and to your criticism, and maybe paint a path of how he and WordPress can be winning again?

David Heinemeier Hansson

First, I echo what you said about what a wonderful thing it is that WordPress exists. There are not many projects in the open-source world, or in the world at large, that have had as big of an impact on the internet as WordPress has. He deserves a ton of accolades for that work.

That was my engagement, essentially my premise. You know, I had tremendous respect for what Matt has built with WordPress, what that entire ecosystem has built around itself. It's a true marvel, but there are some principles that are larger than my personal sympathies to the characters involved.

I agree. Silver Lake, the private equity company that's involved with WP Engine, is not my natural ally. I'm not the natural ally of private equity doing some game with WP Engine. That's not my interest in the case. My interest is essentially a set of principles.

And the principles are: if you release something as open source, people are free to use it as they see fit, and they are free to donate code or resources or money back to the community as they see fit. You may disagree about whether they've done enough, whether they should do more, but you can't show up after you've given the gift of free software to the world and then say, “Now that you've used that gift, you actually owe me a huge slice of your business because you got too successful using the thing I gave you for free.” You don't get to take a gift back.

That's why we have open-source licenses. They stipulate exactly what the obligations are on both sides of the equation. The users of open source don't get to demand what the makers of open source do and how they act. And the makers of open source don't get to suddenly show up with a ransom note to the users and say, “Actually, you owe me for all sorts of use.” I'm 100% allergic to that kind of interaction.

I think Matt, unfortunately, for whatever reason, got so wrapped up in what he was owed that he failed to realize what he was destroying. WordPress and Automattic already make a ton of money. This is part of the wonder of WordPress: this is a project that generates hundreds of millions of dollars, and Matt didn't feel like he was getting enough of that. That's not a good argument, bro.

You can't just violate the spirit and the letter of these open-source licenses and start showing up with demand letters, even to characters that are not particularly sympathetic. This goes to the root of my interpretation of open source in general.

The GPL is a particular license that actually demands code from people who use it under certain circumstances. I've never liked the GPL. I don't want your shitty code if you don't want to give it to me. What am I going to do with that? I'm not on board with that part of Stallman's vision at all.

I love the MIT License. To me, that is the perfect license because it is mercifully short. I think it's 2 paragraphs, 3 paragraphs, really short. And it basically says, “Here's some software. It comes with no warranty. You can't sue me. You can't demand anything. But you can do whatever the hell you want with it. Have a nice life.” That's a perfect open-source interaction, in my opinion.

And that license needs to be upheld. These licenses in general, even the GPL, even if I don't like it, we have to abide by them because if we just set aside those licenses when, at a moment's notice, we feel like something's slightly unfair, we've lost everything. We've lost the entire framework that allowed open source to prosper and allowed open source to become such an integral part of commerce, too.

I mean, back when open source was initially finding its feet, it was at war with commercial software. Stallman is at war with commercial software and always has been. Bill Gates was, in return, at war with open source for the longest time. The open-source licenses and the clarity that they provide allowed us to end that war.

Today, commercial software and open-source software can peacefully coexist. I make commercial software; I sell Basecamp, I sell HEY, and then I also make a bunch of open-source software that I give away for free as gifts. That can't happen if we start violating these contracts.

No commercial company is going to go, “Let me base my next project off this piece of open source,” if I'm also taking on the liability that some mad maker is going to show up 7 years in and demand I give them $50 million. That's not an environment conducive to commerce, collaboration, or anything else. And it's just basically wrong.

I think there's one analysis that's all about the practical outcomes of this, which I think are bad. There's also an argument that's simply about ethics: this is not right. You can't just show up afterward and demand something.

This is not too dissimilar, in my opinion, to the whole Apple thing we talked about earlier. Apple just showing up and feeling like they're entitled to 30% of everyone's business. No, that's not right. That's not fair.

So I think Matt, unfortunately, kind of stared himself blind on the indignity he thought was being perpetrated against him because there was all this money being made by WP Engine making a good product and not giving quite enough back, in Matt's opinion. Tough cookie.

Lex Fridman

I think there might be some personal stuff, too—maybe I'm reading too much into it. They were not only not giving enough, but probably implicitly promising that they would give and then taking advantage of him in that way, in his mind. It's just interpersonal interaction, and then you get interpersonally frustrated. You forget the bigger-picture ethics of it.

It's like when a guy keeps promising he'll do something.

David Heinemeier Hansson

Sure.

Lex Fridman

And then you realize—you wake up one day, a year or 2 later...

Wait a minute. I was being lied to this whole time. And then I don't even know if it's about money.

David Heinemeier Hansson

I'd get mad, too. It's totally fine to get mad when people disappoint you. That's not justification for upending decades of open-source licenses and the essential de facto case law we've established around them.

This is why I chose to even weigh in on this, because I like WordPress. I don't use WordPress. I'm not a part of that community. I don't actually have a dog in this fight. I'm biased, if anything, toward Matt, just as a fellow BDFL.

I would like to see him do well with this, but I also think there are some principles at stake here that ring much louder. I don't want Rails to suddenly be tainted by the fact that it's open source, and whether companies can rely on it and build businesses on it because, wait, maybe one day I'm going to turn Matt Mullenweg, and I'm going to show up with a demand ransom letter. No, screw that. We have way more to protect here.

There's way more at stake than your personal beef with someone or your perceived grievance over what you're owed.

Lex Fridman

What would you recommend? What do you think he should do, or can do, to walk it back and heal?

David Heinemeier Hansson

Decide. This is the curious thing: He could decide to give this up. That's very, very difficult for driven, ambitious people to do—to accept that they're wrong, give up, and lay down their sword.

I had hoped earlier on that that was possible. I haven't seen any evidence that Matt is interested in that, and I find that deeply regretful. But that's his prerogative. I continue to speak out when he's violating the spirit and ethics of open source, but I wish he would just accept that this was a really bad idea.

He made a bad bet, and I think he thought he'd just get away with it—that they'd just pay up and he could apply pressure. I know that temptation when you sit as the head of a very important project. You know that comes with a great degree of power, and you really need a great degree of discipline to rein that in and not exercise that power at every step where you feel aggrieved.

I've felt aggrieved a million times over in the 20-plus years of Ruby and Rails. I've really tried very hard not to let those sometimes petty, sometimes substantial grievances over time seep into the foundation of the ecosystem and risk ruining everything.

Lex Fridman

As the king of the Rails kingdom, has the power gotten to your head over the years?

David Heinemeier Hansson

I'm sure it has. I mean, who wouldn't?

Lex Fridman

Do you pace around in your chamber?

David Heinemeier Hansson

I do occasionally, and I do marvel at both what's been built and what's been possible. Over 1 million applications have been made with Ruby on Rails, by one estimate I've seen. Businesses like Shopify and GitHub, and a million others, have been built on top of something that I started. That's very gratifying, but you really have to be careful not to smell your own exhaust too much. You have to be just as careful not to listen too much to the haters.

Lex Fridman

And not to listen too much to the super fans, either. You have to assess the value and the principles of what you're working toward on their own merits, on your own scoreboard.

David Heinemeier Hansson

I try to block that out and just go, "Well, I'm working on Rails because I love to write Ruby. I love to use Ruby to make web applications." That's my north star, and I'll continue to do that. I'll continue to share all of the open-source gifts that I uncover along the way. That's it. That's enough, too. I don't have to get all of it out of it.

This is similar to the guy who thought I'd given up on being a programmer or something instead of doing Basecamp. There are people over the years who've asked, "Why didn't you charge for Rails?" Like, "Don't you know how much money I've made off Rails? If we just look at something like Shopify, it's worth billions of dollars. I'm not a billionaire."

And so freaking what? I got more than enough. I got plenty of my share. I will say, though, I'm also introspective enough to realize that if it hadn't panned out as well as it did for me in my own business, maybe I would have been more tempted.

Maybe if you see other people build huge, successful companies off the back of your work and you really don't have a pot to piss in, you might be tempted to get a little upset about that. I've seen that in the Rails world as well, where there are people who contributed substantial bodies of work and then got really miffed when they didn't feel like they got enough back.

I was fortunate enough that the business that Jason and I built with Ruby and Rails was as successful as it was, and I made the money I needed to make. I didn't need to chase the rest of it.

Lex Fridman

But we should also make explicit that many people in your position chase the money. It's not that difficult to chase. Basically, you turned away money. You made a lot of decisions that just turned away money.

David Heinemeier Hansson

Maybe I also think of this example with Matt. He probably thought there was easy money for the taking. It wasn't so easy, was it? It looked like low-hanging dollar bills, and they turned out to be some really sour grapes.

It turned out he probably destroyed vast sums of money by undermining the whole WordPress trust and ecosystem, and putting question marks in the heads of folks who would choose to use WordPress or something else going forward. So, I often think, when people say, "Oh, you left money on the table," first of all, so what? I don't have to have all the money. But second of all, maybe the money wasn't on the table at all.

Lex Fridman

And maybe the cost, even if you got the money, maybe the cost in other ways, like we've talked about—

David Heinemeier Hansson

Yes.

Lex Fridman

—would outweigh all the money that you could have possibly gotten. Meaning, I think you said that the thing that makes you happy is flow and tranquility. Those two things—beautifully, really beautifully put.

Gaining money might assign you the responsibility of running a larger thing that takes away the flow that you gain from being—because fundamentally, for you, flow means programming. And then tranquility is—I think you also have a beautiful post about how nirvana is an empty schedule.

David Heinemeier Hansson

When I look at an upcoming week and I see that I have no scheduled meetings at all, which is quite common, or maybe I just have one thing for 1 hour on 1 day, I think to myself, "Do you know what? This could very easily have been very different."

We could have been running a company of hundreds of people or thousands of people, and my entire calendar would have been packed solid with little Tetris blocks of other people's demands on my attention and time. I would have been miserable as fuck.

Lex Fridman

Yep.

David Heinemeier Hansson

And I look at that and go, "What more can I ask for?" It's a really nice state of being.

I'd actually say I didn't always have this. Early on in my career, I did have some sense of, "I need a little more security." I remember this really interesting study where a bunch of researchers asked people who had made certain amounts of money how much money it would take for them to feel secure.

They'd ask people who had a $1 million net worth, "How much money do you need?" "Probably $2 million. $2 million, then I'd be good." Then they'd ask people with a net worth of $5 million, "How much do you need?" "Ah, $10 million. I need $10 million." They'd ask people with $10 million, "What do you need?" "$20 million." Every single time, people would need double what they had.

I did that for a couple of doublings until I realized, "You know what? This is silly. I am already where I wished I would be, and a million times over. So what else is there to pursue?"

Now, that doesn't mean that if more money is coming my way, I'm going to say no to it. Of course not. But it does mean that I'm free to set other things higher. I also think you realize, as Jim Carrey would say, "I wish everyone would get all the money that they wished for, and they'd realize it wasn't the answer."

Money solves a whole host of problems and anxieties, and then it creates a bunch of new ones. It also doesn't touch a huge swath of the human experience at all. The world is full of miserable, anxious, hurt rich people. It's also full of miserable, anxious, poor people, and I'd rather be a miserable, anxious rich person than a poor person.

But money isn't this magic wand that makes everything go away. That's again one of those insights, just like having children, that you cannot communicate in words. I've never been able to persuade a person who's not wealthy that wealth wasn't going to solve all their problems.

Lex Fridman

One quote you've returned to often that I enjoy a lot is the Coco Chanel quote: "The best things in life are free, and the second-best things are very, very expensive." I guess the task is to focus on surrounding yourself with the best things in life, like family and all of this, and not caring about the other stuff.

David Heinemeier Hansson

I would even say you can care about the other stuff. Just know the order of priority.

Lex Fridman

Yeah.

David Heinemeier Hansson

If you are blessed with a partner that you love and some children that you adore, you've already won the greatest prize that most humans are able to achieve. Most humans in this world, if they are of marital age and have children, if you ask them what's the most important thing, they would all say that. They would all say that, no matter whether they're rich or poor.

It's easy to lose sight of that when you're chasing the second-best things because, do you know what? They're also very nice.

I really like that Pagani Zonda. It was a very expensive car, and I would have had no chance of acquiring it if I hadn't become rather successful in business. So, I don't want to dismiss it, either. It's great fun to have money. It's just not as fun for quite as long, or as deeply, as you think it is.

These other things—having an occupation and a pursuit that you enjoy, being able to carry burdens with a stiff upper lip, and with a sense of meaning—are incredible.

To have family, to have friends, to have hobbies, to have all these things that are actually available to most people around the world—that’s winning. And it doesn’t mean you have to discount your ambitions. It doesn’t mean you can’t reach for more. But it does mean it’s pretty dumb if you don’t realize that it’s not going to complete you in some hocus-pocus woo sense to make more. It really isn’t.

Lex Fridman

What gives you hope about the future of this whole thing we have going on here—human civilization?

David Heinemeier Hansson

I find it easier to be optimistic than pessimistic because I don’t know either way. So if I get to choose, why not just choose to believe it’s going to pan out?

Lex Fridman

Yeah.

David Heinemeier Hansson

We suffer more in our imagination than we do in reality. That’s one of the quotes out of Stoicism. And I also think we have a tendency—a lot of humans have a tendency—to be pessimistic in advance about things when they don’t know how they’re going to pan out.

Climate change, for example, is making a lot of people very anxious and very pessimistic about the future. You know nothing. 40 years ago, we thought the problem was that the planet was going to be too cool. I happen to believe that it’s probably correct that the planet is getting too hot and that CO2 has something to do with it. Whether we have the right measures to fix it in time, if that’s even possible or not, is completely up in the air. And we don’t know.

If you convince yourself with such certainty that the world is going to turn to shit, it is right up here in your head today. Climate change might wipe out this entire species in 200 years. It’s not next year. It’s not 10 years from now. Your life might become more unpleasant, and there might be more negative effects and so on. Yes, okay. But then deal with that hardship when it arrives. Don’t take that in advance. How are you helping Earth by just walking around being depressed?

I think our whole conversation today is also an indication of that. It’s just 2 humans talking. There are billions of us, and there is something about us that wants to solve problems and build cool stuff. Yes, and so we’re going to build our way out of whatever shit we get ourselves into. This is what humans do. We create problems for ourselves and then figure out how to build rocket ships to get out of those problems. Sometimes the rocket ships create other problems, like nuclear warheads. Then we’ll, I’m sure—I hope—figure out ways to avoid those problems. Then there’ll be nanobots. And then the aliens will come, and it’ll be a massive war between the nanobots and the aliens, and that will also bring all of us humans together.

The funny thing, just to pick on one of the points you mentioned, is the atom bomb, for example. When that was first invented, a lot of people thought, “We have essentially ended life on Earth,” right? Or maybe we prevented World War III from happening for the past 80 years because mutually assured destruction kept the superpowers from attacking each other, at least head-on, and kept their fighting to proxy wars. You know what? Proxy wars are not great, but they’re probably better than World War III with nuclear weapons.

So it’s quite difficult in the moment to tell what’s actually a benefit and what’s not. And I think we should be a bit more humble. I’ve certainly become more humble over time about thinking I know which way it’s going to turn. I think the pandemic was a huge moment for a lot of people, where there was so much certainty about whether this intervention worked or that intervention didn’t work. Most people were wrong. Certainly, a lot of very smart, very qualified people got that just utterly and catastrophically wrong.

So, just a little intellectual humility. I think back upon that and go, “You know what? I’m not a PhD in virology, and I don’t claim that I somehow saw how it all was going to play out.” But the people who were really experts in that, they got a bunch of it wrong. Nobody knows anything. I keep reminding myself of that every day. No one knows anything. We can’t predict the economy a month out. We can’t predict world affairs a month out. The world is just too complicated.

Lex Fridman

Yeah. When I watched the Netflix documentary Chimp Empire, there’s a hierarchy of chimps. All of that looks eerily similar to us humans. We’re recent descendants. Some of the chimps have got a PhD; others don’t. Others are really muscular, while others are beta-male types, sucking up to the alpha. There are a lot of interesting dynamics going on that really map cleanly to the geopolitics of the day.

They don’t have nuclear weapons, but the nature of their behavior is similar to ours. So I think we barely know what’s going on. But I do think there’s a basic will to cooperate. There’s a basic compassion that underlies our human spirit. Maybe that is just me being optimistic, but if that is indeed there, I think we’re going to be okay.

David Heinemeier Hansson

The capacity is certainly there.

Lex Fridman

Whether we choose that capacity or not, who knows? And in what situation? I think accepting that we all have the capacity for both ways—for both incredible generosity and kindness, and also cruelty—and accepting that it’s our job to attempt to cultivate the better parts of our human nature is weighed against our propensity to sometimes be the worst of ourselves.

I’m excited to find out what’s going to happen. It’s so awesome to be human. I don’t want to die. I kind of want to be alive for a while to see all the cool shit we do. And one of the cool things I want to see is all the software you create and all the things you tweet, all the trouble you get yourself into on Twitter.

David, I’m a huge fan. Like I said, thank you for everything you’ve done for the world, for the millions of developers you’ve inspired, and one of whom is me. And thank you for this awesome conversation, brother.

David Heinemeier Hansson

Thanks so much for having me.