Audio · 2025-07-12 · 6 moments

#474 – DHH: Future of Programming, AI, Ruby on Rails, Productivity & Parenting

David Heinemeier Hansson (aka DHH) is a legendary programmer, creator of Ruby on Rails, co-owner & CTO of 37signals that created Basecamp, HEY, & ONCE, and is a NYT-best-selling author (with Jason Fried) of 4 books: REWORK, REMOTE, Getting Real, and It Doesn’t Have To Be Crazy At Work. He is also a race car driver, including a class-winning performance at the 24 hour Le Mans race. Thank you for listening ❤ Check out our sponsors: https://lexfridman.com/sponsors/ep474-sc See below for timestamp ✦ AI generated

Apple Podcasts ↗

GUEST David Heinemeier Hansson (DHH)

timeline · colored by role

Claim◆

The simplicity and ergonomics of late 90s PHP — write a script, FTP it to a server, instantly deployed — is a peak of web developer experience that the industry has been losing ever since.

DHH argues that late 90s PHP represented the pinnacle of web developer ergonomics — write a script, FTP it, instantly deployed — and that the industry has been chasing that high ever since, often overcomplicating what is fundamentally CRUD work.

transcript

David Heinemeier Hansson (DHH): 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's no web servers, there's no setup, there's just an Apache that runs mod PHP, and it was essentially the easiest way to get a dynamic web page up and going. And 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 to give them their success experiences that I had? ... 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. And they have to compensate for that existential dread by overcomplicating things.

provides context · 2

Claim

The JavaScript ecosystem from 2010 to 2020 was an asylum of perverse complexity and churn, where build pipelines and tooling broke constantly and frameworks were discarded every few months.

DHH describes the 2010-2020 JavaScript ecosystem as a dark age of complexity where build pipelines broke constantly and frameworks were rewritten every few months, with the community treating this churn as normal.

transcript

David Heinemeier Hansson (DHH): In the early 2010s until quite recently, all of that advancement happened in pre-processing, happened in built pipelines. The browsers couldn't speak a dialect of JavaScript that was pleasant to work with. So everyone started to pre-compiling 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. And that made sense to me, but it was also deeply unpleasant. And 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. And you had to be trapped inside of that asylum to not realize what an utterly perverse situation we had landed ourselves in. ... 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 got to get with the new program.

extends · 1

Claim◆

Chrome is a gift to the open web and splitting it up via antitrust action would be a disaster — the real monopoly problems are elsewhere, like mobile app store toll booths.

DHH argues that while he is sympathetic to antitrust fights in tech, targeting Chrome is misguided: Chrome won on merit, the open web benefits from a trillion-dollar champion, and real monopoly problems like mobile app store toll booths should be the priority instead.

transcript

David Heinemeier Hansson (DHH): It's 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, is with the tools we use to access the open web. ... I also think that the open web needs this trillion dollar champion, or at least benefits from it. ... Of all the things that are wrong with monopoly formation in technology, Chrome is the last thing. And this is why I get so frustrated sometimes about the anti or the monopoly fight, that there are real problems and we should be focusing on the premier problems first, like the toll booths on our mobile phones. They're a far bigger problem. It's not the open web. It's not the tools that we use to access the open web. ... 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.

Example

The contrast between Ruby and Python's aesthetics is stark: Python's `init` and mandatory `self` are aesthetically offensive line noise, while Ruby's `def initialize` is beautiful — proving that aesthetics in programming languages matter and should be optimized for.

DHH contrasts Ruby's beautiful design against Python's, arguing that Python's `__init__` and mandatory `self` parameter are aesthetically offensive line noise, while Ruby's clean `def initialize` shows that code beauty is worth optimizing for — and that Ruby's design choices like the `unless` keyword and predicate question marks serve human readers over machine parsers.

transcript

David Heinemeier Hansson (DHH): When you make a class in Python, the initializer method, the starting method, is def, okay, fair enough, that's actually the same as Ruby, DEF, definition of a method, then it is underscore, not one, underscore, 2, init, underscore, underscore, parentheses start, self, comma, and then the first argument. Yeah, the whole self thing, yeah. I look at that and go, I'm sorry, I'm out. I can't do it. It's just, it's 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? ... Ruby is as beautiful as it 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. ... Let me give you an even better example. The if conditional. ... Ruby boils almost all of it away. ... No parentheses necessary because there's no ambiguity for the human to distinguish that the next part is just a single statement. ... 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. ... You can do user.downgrade if exclamation point not user.admin. Right? That'd be a typical way of writing it. Ruby goes, that exclamation point is line noise. ... We could do user.downgrade unless user admin question mark. That to me is an encapsulation of the incredible beauty that Ruby affords the programmer through ambiguity that is only to serve the human reader and writer.

Claim◆

Ruby is designed for programmer happiness above all else — it prioritizes human readability and beautiful code through features like no semicolons, predicate methods with question marks, unless conditionals, and the ability to extend base classes.

DHH explains that Ruby's design philosophy, driven by its creator Yukihiro Matsumoto, prioritizes programmer happiness above all else — eliminating line noise like semicolons and parentheses, adding readable features like question-mark predicates and 'unless' conditionals, and allowing programmers to extend base classes as equals.

transcript

David Heinemeier Hansson (DHH): His number one goal was programmer happiness, that his number one goal was the affordances that would allow programmers to articulate code in ways that not just executed correctly, but were a joy to write and were a joy to read. And that vision is based on a fundamentally different view of humanity. There's no greater contrast between Matz and James Gosling, the designer of Java. ... His view of humanity is rather dark. His view of humanity was programmers, at the 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. ... Matz went 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. ... Ruby allows you to extend base classes. ... In Rails, we have something called active support, which is essentially my dialect of Ruby for programming web applications. And I'll give you one example. I've added a method called days to the number. So if you do 5 dot days, you get 5 days in seconds, because seconds is the way we set cache expiration times and other things like that. ... 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 that Matz wrote and the code that I wrote.

gives example · 1

Highlight slides

Late 90s PHP: The Peak of Web Developer Ergonomics✦ from: The simplicity and ergonomics of late 90s PHP — write a script, FTP it to a server, instantly deployed — is a peak of web developer experience that the industry has been losing ever since.From Simplicity to Overcomplication✦ from: The simplicity and ergonomics of late 90s PHP — write a script, FTP it to a server, instantly deployed — is a peak of web developer experience that the industry has been losing ever since.Breaking up Chrome would be a disaster for the open web✦ from: Chrome is a gift to the open web and splitting it up via antitrust action would be a disaster — the real monopoly problems are elsewhere, like mobile app store toll booths.Real monopoly targets are elsewhere✦ from: Chrome is a gift to the open web and splitting it up via antitrust action would be a disaster — the real monopoly problems are elsewhere, like mobile app store toll booths.Ruby's Core Design: Programmer Happiness First✦ from: Ruby is designed for programmer happiness above all else — it prioritizes human readability and beautiful code through features like no semicolons, predicate methods with question marks, unless conditionals, and the ability to extend base classes.Equal Footing: Extending Ruby's Core✦ from: Ruby is designed for programmer happiness above all else — it prioritizes human readability and beautiful code through features like no semicolons, predicate methods with question marks, unless conditionals, and the ability to extend base classes.

Related episodes

Article · Simon Willison's Weblog

The simplicity and ergonomics of late 90s PHP — write a script, FTP it to a server, instantly deployed — is a peak of web developer experience that the industry has been losing ever since.

The JavaScript ecosystem from 2010 to 2020 was an asylum of perverse complexity and churn, where build pipelines and tooling broke constantly and frameworks were discarded every few months.

Chrome is a gift to the open web and splitting it up via antitrust action would be a disaster — the real monopoly problems are elsewhere, like mobile app store toll booths.

EU cookie banners are a monument to good intentions leading to hell — a universally hated regulatory failure that has made the entire internet uglier while doing nothing for privacy.

The contrast between Ruby and Python's aesthetics is stark: Python's `__init__` and mandatory `self` are aesthetically offensive line noise, while Ruby's `def initialize` is beautiful — proving that aesthetics in programming languages matter and should be optimized for.

Ruby is designed for programmer happiness above all else — it prioritizes human readability and beautiful code through features like no semicolons, predicate methods with question marks, unless conditionals, and the ability to extend base classes.

Ruff v0.16.0

xai-org/grok-build, now open source

Story: David Heinemeier Hansson, Software Contrarian

The contrast between Ruby and Python's aesthetics is stark: Python's `init` and mandatory `self` are aesthetically offensive line noise, while Ruby's `def initialize` is beautiful — proving that aesthetics in programming languages matter and should be optimized for.