DHH on Lex Fridman: Why No-Build Rails Fixes Web Complexity

David Heinemeier Hansson 0:00 No one anywhere who's serious believes that cookie banners does anything good for anyone. Yet, we've been unable to get rid of it. 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 you try to access a webpage, you will still see a cookie banner. No one in the universe is safe from this nonsense. It sometimes feels like we're barely better off. Like, webpages aren't that different from what they were in the late '90s, 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.

Lex Fridman 0:43 Mm-hmm.

David Heinemeier Hansson 0:43 They just make systems that create, read, update or delete rows in the database, and they have to compensate for that existential dread by over-complicating things. That's a huge part of the satisfaction of driving a race car, is driving it at the edge of adhesion, as we call it, where you're essentially just a tiny movement away from spinning out. 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.

Lex Fridman 1:21 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 that created Basecamp, HEY, and Once. He is a New York Times bestselling 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 Le Mans race. This is a 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 2:32 For someone who became a legendary programmer, you officially got into programming late in life, and I guess that's because, uh, you tried to learn how to program a few times and you failed. So, can you tell me the, uh, the full story, the saga of your failures to learn programming? Was Commodore 64 involved?

David Heinemeier Hansson 2:53 Commodore 64 was the inspiration. I really wanted a Commodore 64. That was the first computer I ever sat down in front. And the way I sat down in front of it was I was five years old and there was this one kid on my street who had a Commodore 64. No one else had a computer, so we were all the kids just getting over there and we were all 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 and I was playing that for the first time at five years old. And we were, like, seven kids sitting up in this one kid's bedroom all taking our turn to play the game. And I just found that unbelievably interesting. And I begged and I begged and I begged my dad, "Could I get a computer?"

Lex Fridman 3:35 Mm-hmm.

David Heinemeier Hansson 3:35 And he finally comes home, he's like, "I got you a computer." I was like, "Yes, my own Commodore 64." And he pulls out this black, green and blue keyboard. That's an Amstrad 464. I was like, "Dad, what's this?"

Lex Fridman 3:52 Yeah. (laughs)

David Heinemeier Hansson 3:53 (laughs)

Lex Fridman 3:53 The disappointment.

David Heinemeier Hansson 3:54 This is not a Commodore 64. But it was a computer, so I-

Lex Fridman 4:00 (laughs)

David Heinemeier Hansson 4:00 ... got my first computer at essentially six years old, that Amstrad 464, and of course the first thing I wanted to do, I wanted to play video games. And I think the computer, which he, by the way, had traded for a TV and a stereo recorder or something like that, came with, like, two games. One was this Frogger game where you had to escape from underground. It was actually kind of dark, like this frog-

Lex Fridman 4:22 Mm-hmm.

David Heinemeier Hansson 4:22 ... you're trying to get it out from underground and I was just, I was pretty bad at it. And I only had those two games and then I wanted more games. And one way to get more games when you're a kid who don't have a lot of money and can't just buy a bunch of games is to type them in yourself. Back in '84, '85, magazines would literally print source code at the back of their magazines and you could just sit and type it in. So I tried to do that and it would take, like, two hours-

Lex Fridman 4:49 Mm-hmm.

David Heinemeier Hansson 4:49 ... to print this game into, uh, the Amstrad. And of course I'd make some spelling mistake along the way and something wouldn't work and the whole thing... I wasn't that good at English, I was born in Denmark. So I was really trying to get into it because I wanted all these games and didn't have the money to buy 'em, and I tried quite hard for quite a while to get into it but it just never clicked, and then I discovered the magic of piracy.

Lex Fridman 5:14 (laughs)

David Heinemeier Hansson 5:14 And after that I kind of basically just took some time off from learning to program because, well, now suddenly I had access to all sorts of games. So that was the first attempt, like, around six, seven years old, and what's funny is I remember these fragments. I remember not understanding the purpose of a variable. If, if there's a thing and you assign something, why would you assign another thing to it? So for some reason I understood constants, like, 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, still perhaps my favorite computer of all time. I mean, this is one of those things where you're like people get older and they're like, "Oh, the music from the '80s was amazing." To me, even as someone who loves computers and love new computers, the Amiga-... was this magical machine that was made by the same c- company that produced the Commodore 64, and I got the Amiga 500, I think in '87.

Lex Fridman 6:15 Look at this sexy thing. That is a sexy machine right there.

David Heinemeier Hansson 6:19 This is from an age, by the way, where computing wasn't global in the same sense, that 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. They, they 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 it again. And you know what's funny? The reason I wanted to try it again was I remembered the first time, Time To Learn, and then there was this programming language that was literally called Easy AMOS.

Lex Fridman 6:57 Mm-hmm.

David Heinemeier Hansson 6:57 Like, the easy version of AMOS. I'm like, "If it, if it's Easy AMOS, how hard can it be?" (laughs)

Lex Fridman 7:02 Yeah.

David Heinemeier Hansson 7:02 "I gotta be able to figure this out." And this time, I tried harder. I got into conditionals, I got into loops, I got into all these things, and I still, I couldn't do it. And on the second attempt, I really got to the point I'm like, "Maybe this is ju- maybe I'm not smart enough. Maybe programming's just not f- m- maybe it's too much math." Like, I like math in this sort of 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, but like, I'm not that person. I'm not the mac- math geek who's gonna figure it all out. So after that attempt with Easy AMOS and failing, to even get... I don't even think I completed one even very basic game. I thought, "Th- to program's just not for me. I'm gonna have to do something else." I still love computers. I still love video games. I actually, at that time, had already begun making friends with people who knew how to program, who weren't even programming Easy AMOS. They were programming frigging Assembler. And I would sit down and just go, "I've... How do you... The moves and the memories and the copies, how do you even do this? I don't even understand how you go from this to Amiga demos, for example." That was the big thing with the Amiga. It had this wonderful demo scene in Europe. It's this 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 on graphic competitions, where you could probably bring one of these up on your YouTube.

Lex Fridman 8:34 Oh, that thing? (laughs)

David Heinemeier Hansson 8:35 On, on, this thing, they would make these little, um, almost like music videos combining some MIDI music, combining some cool graphics, and they would do all of it in like 4K, four kilobytes that is (laughs) , not 4 days of revolution, four kilobytes of, of memory. And I just thought that was such a cool scene. This was obviously pre-internet. It was even pre-BBS, bulletin board systems, to some extent. It was you swap your demo software with someone else by sending them a disc in the mail-

Lex Fridman 9:08 Mm-hmm.

David Heinemeier Hansson 9:09 ... like the 3.5s. And I just, 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 kinda didn't have any skills to contribute, and that's how I got into running BBSes. 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 scenes, allowing all these demo groups to distribute their amazing demos, and then it was also a place to trade piracy software, pirated software. And I ended up starting one of those when I was 14 years old in my tiny little bedroom in Copenhagen. I had my, at that point, Amiga 4000. I had three telephone lines coming into my tiny room.

Lex Fridman 9:59 Nice.

David Heinemeier Hansson 10:00 Which 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 is a 14-year-old-

Lex Fridman 10:13 Ugh.

David Heinemeier Hansson 10:13 ... having three phone lines into their tiny little bedroom? What are, what's going on here? Why are all these modems blinking red and, um, black and making funny sounds?"

Lex Fridman 10:23 Did your parents know?

David Heinemeier Hansson 10:24 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 that was both illegal and whatever else was going on.

Lex Fridman 10:38 Oh, we should probably say that in Europe, maybe you can comment on this, in, 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, there... Maybe, maybe it's just (laughs) my upbringing.

David Heinemeier Hansson 10:51 Even that conversation-

Lex Fridman 10:52 Yeah.

David Heinemeier Hansson 10:52 ... wasn't present.

Lex Fridman 10:53 Yeah.

David Heinemeier Hansson 10:54 I never spoke to anyone growing up in Denmark who had-

Lex Fridman 10:56 That piracy is wrong.

David Heinemeier Hansson 10:57 ... any moral qualms whatsoever about piracy. It was just completely accepted that you're a kid. You want a lot of games. You don't have a lot of money. What do you do? You trade.

Lex Fridman 11:08 Yeah.

David Heinemeier Hansson 11:08 Some people would occasionally buy a game. I mean, I once bought a, uh, Sega Master System, and the... I bought one game 'cause that was what I could afford. I got After Burner II. I don't know if you've ever played that game. It's pretty bad (laughs) implementation on the-

Lex Fridman 11:23 (laughs)

David Heinemeier Hansson 11:23 ... uh, Sega Master System, but it was like 600 crowners, and I was making money at that time, uh, doing newspaper delivery. I had to do that for a month to afford one game. I liked video games way too much to wait a month just to get one game.

Lex Fridman 11:40 Yeah.

David Heinemeier Hansson 11:40 So piracy was just the way you did it, and that was how I got into running this bulletin board system, being part of the demo scene, being part of the piracy scene to some extent, and then also, at some point, realizing, oh, you can actually also make money on this, and this can fund buying more phone lines and buying more modems and buying more Amigas. Oh yeah, that was one of the demo parties. These were amazing things.

Lex Fridman 12:04 What am I looking at?

David Heinemeier Hansson 12:06 Isn't that amazing?

Lex Fridman 12:06 Look at all those CRT monitors.

David Heinemeier Hansson 12:08 All these CRT monitors. Again, when I was 14, I, I don't understand fully why my parents allowed this.

Lex Fridman 12:14 (laughs)

David Heinemeier Hansson 12:15 But I traveled from Copenhagen-... the capital of Denmark to Aarhus, this tiny little town in Jutland, on the train with a bunch of dudes who were, like, late teens and their 20s. I'm 14 years old. I'm lugging my 14-inch CRT monitor with my computer in the back to go to the party. That was what it was called. That was the biggest demo scene party at that time. And 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 12:48 That's kind of awesome, not gonna lie. It's a little ridiculous. (laughs)

David Heinemeier Hansson 12:52 It's totally awesome. And I, I, 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-

Lex Fridman 13:01 Yeah.

David Heinemeier Hansson 13:01 ... who has their own CRT monitor, who's lugged it halfway around the country to get there, is truly special. Because 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 could do, they're really good at programming computers. It's infectious. It was part of that pang I felt then going like, "Oh, man, why can't I figure this out?" I mean, why can't I even figure out easy AMOS?

Lex Fridman 13:25 (laughs)

David Heinemeier Hansson 13:26 I mean, it's kind of frustrating.

Lex Fridman 13:28 But on your third attempt, you were more successful.

David Heinemeier Hansson 13:30 So third attempt is when I start getting it. This is when I start helping out, let's say, building things for the internet. So around '95, I think it is, or '96, I discovered the internet. Actually, in ninth grade. That was my first experience. I went to some university, uh, in, in Denmark, and in ninth grade we had this excursion, and they sat us down in front of a computer, and the computer had Netscape Navigator, the first version, or maybe it was even the, the precursor to that. And they had a text editor, and us kids just gotta, "Hey, build something on the internet." And it was just HTML. And the first thing you do is like, "Oh, I can make the tics- text blink by just putting in this tag and saving it?" That was... That moment, that was actually when I reawakened the urge to wanna learn to program, because I got a positive experience. All the other experiences I had with programming was, I'd spend hours typing something in, I'd click Run and it wouldn't work, and I'd get an error message that made no sense to me as a kid, either at six or seven 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. And these guys out here, we just did it for, like, an hour and a half, and suddenly I go, "Oh, I can make things for the internet that someone in Germany can be able to 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, to the internet. I got into working with HTML, and I still had all these friends from these demo parties.

Lex Fridman 15:06 Mm-hmm.

David Heinemeier Hansson 15:07 And I started working with them on creating gaming websites. I'd write about the video games. I'd review 'em. This was another good way of getting new video games, was to walk down to some store and say, like, "Hey, I'm a, I'm a journalist."

Lex Fridman 15:19 Right.

David Heinemeier Hansson 15:19 I'm like this 15-year-old kid, and they're, they're looking at me, "You're, you're a journalist?" "Yeah, can I borrow some, some games?" 'Cause this was when games moved onto the PlayStation and these other things you couldn't just as easily pirate, at least not at first. So I went down there, did all that, and that started the journey of the internet for me. It started... Working on these gaming websites, working with programmers, n- 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.

Lex Fridman 15:46 (laughs)

David Heinemeier Hansson 15:46 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 p- pathway back into programming. And then slowly, I picked up more and more of it. First website I did with someone, one of these programmers from the demo scene, that was dynamic, was asp.net. And it wasn't even actually called .net. That was what we started on, and then we moved on to PHP, and PHP was when I finally got it, when it finally clicked, when conditionals and loops and variables and all that stuff started to make sense enough to me that I thought, "I can do this."

Lex Fridman 16:26 So would it be fair to say that we wouldn't have DHH without PHP, and therefore you owe a- all your success to PHP? (laughs)

David Heinemeier Hansson 16:33 100% that's true. And it's even better than that, because it's... 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 developer, web developer ergonomics, is late '90s PHP. You write this script, you FTP it to a server-

Lex Fridman 16:56 Mm-hmm.

David Heinemeier Hansson 16:56 ... and instantly it's deployed.

Lex Fridman 16:58 Yep.

David Heinemeier Hansson 16:58 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-

Lex Fridman 17:07 Mm-hmm.

David Heinemeier Hansson 17:08 ... that runs mod PHP, and it was essentially the easiest way to get a dynamic webpage 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 those 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 have really taken us to a place where it sometimes feels like we're barely better off. Like, webpages aren't that different from what they were in the late '90s, 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.

Lex Fridman 18:12 Mm-hmm.

David Heinemeier Hansson 18:12 They just make systems that create, read, update, or delete rows in a database, and they have to compensate for that-... existential dread by over-complicating things. Now, that's a bit of a character. There's more to it, and there's things you can learn for more sophisticated ways of thinking about this. But there's still an ideal here, which is why I was so happy you had Pieter Levels on because he still basically works like this.

Lex Fridman 18:36 Yeah.

David Heinemeier Hansson 18:37 And I look at that and go like, "Man, that's amazing."

Lex Fridman 18:39 Yeah. You're chasing that high. He's been high all along-

David Heinemeier Hansson 18:42 Yes.

Lex Fridman 18:42 ... using (laughs) using PHP, jQuery, and, uh, SQLite.

David Heinemeier Hansson 18:47 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 first, upfront, is that he's just one guy. And you can do different things when you're just one guy. When you're working in a team... When I started working on 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, "Do you know what? Designers, ah, they're probably not smart enough to figure out CBS."

Lex Fridman 19:23 Yeah.

David Heinemeier Hansson 19:24 And therefore, I just like, "No, no, no. You just FTP it up. You just FTP it on." I knew they knew how to do FTP. And then after the third time I had overridden their changes, I was like, "Goddammit, I guess I gotta teach Jason CBS to not do that 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 19:57 And you've been chasing that with Rails 8. So s- h- how do you bring all the cool features of a modern framework and make it no-build, make it as, as easy to create something and to ship it as it was in the '90s with just PHP? It's very difficult for me to beat the Pieter Levels approach, uh, of just, just... It's so easy to just ship some PHP.

David Heinemeier Hansson 20:22 And it should be. Why should it be harder than that? Our computers today are almost infinitely faster than what they were in the '90s. So shouldn't we be able to work in even easier ways? We should be looking back on the '90s and going like, "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 on 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. Uh, there was a lot of things that sucked. And 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-

Lex Fridman 21:32 Mm-hmm.

David Heinemeier Hansson 21:32 ... which is the JavaScript scene.

Lex Fridman 21:35 Yeah.

David Heinemeier Hansson 21:35 And I don't say that as someone who hate JavaScript. I mean, I often joke that JavaScript is my second favorite programmer language.

Lex Fridman 21:41 Mm-hmm.

David Heinemeier Hansson 21:42 It's a very distant second.

Lex Fridman 21:43 Yeah.

David Heinemeier Hansson 21:43 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 flack. People add a string of two, plus a one, and it gives something nonsense. And I just go like, "Yeah, but why are you, why would you do that? Just don't do that." The language is actually quite lovely, especially the modern version. ES6, that 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, made things so much better. But in the early 2010s until quite recently, all of that advancement happened in pre-processing, happened in build 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-

Lex Fridman 22:51 (laughs)

David Heinemeier Hansson 22:53 ... 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 five 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. Why does everything break all the time? I mean, 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, um, 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 gotta get with the new program. We're completely rewriting everything for the umpteenth time, and anything you've learned in the framework you've been spending the last amount of time on, it's all useless. You gotta throw everything out and you gotta start over. Why aren't you doing it, stupid idiot?"

Lex Fridman 24:18 Is that a kind of mass hysteria that took over the developer community, you think, like where you have to keep creating new frameworks and new frameworks, and we... are we past that Dark Age?

David Heinemeier Hansson 24:29 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, 'cause they're 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?"

Lex Fridman 25:04 (laughs) Yeah.

David Heinemeier Hansson 25:05 And it really wasn't until obviously Firefox kind of kindled a little bit of something, then Chrome got into the scene and Google got serious about moving the web forward that you had a kindling of 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 were- 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 brain power applied to the problem of how to work with the web, and there were some very smart people with some, I'm sure, very good ideas, who did not have, uh, programmer happiness as their motivation number one. 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 does depend on the web and want to push it forward, but have sliced the development role job into these tiny little niches. "I'm a front-end glob pipeline-"

Lex Fridman 26:39 (laughs)

David Heinemeier Hansson 26:40 "... configurator." "Oh, yeah. Well, I'm a front-end whatever engineer." And 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 wanna give it the bold case here, which was that some of the complexity was necessary to get to where we are today, that 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 pre-processing. You can just write text files, send them to a browser, and you have an incredible development experience.

Lex Fridman 27:25 And we should also say that it can kind of be broken, at least the HTML, but even the JavaScript can be a little bit broken and it kind of still works. Like, maybe it half-ass works, but, like, the, just the amount of mess, of smelly code that a browser has to deal with is insane.

David Heinemeier Hansson 27:44 This is one of the hardest problems in computing today-

Lex Fridman 27:47 Yeah.

David Heinemeier Hansson 27:48 ... is to parse the entire internet. Because thankfully, for us as web developers, but perhaps not so much for the browser developers, every webpage that has ever been created, minus the brief period with Flash, still runs today.

Lex Fridman 28:03 Mm-hmm.

David Heinemeier Hansson 28:04 The webpage I did in ninth grade would render on a modern browser today, 30 years later.

Lex Fridman 28:10 That's crazy.

David Heinemeier Hansson 28:11 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, 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, which is why even companies like Microsoft have 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.

Lex Fridman 28:45 Mm-hmm. Nice.

David Heinemeier Hansson 28:46 I've supported that project. I would encourage people to look into that. It's really a wonderful-

Lex Fridman 28:51 Nice.

David Heinemeier Hansson 28:52 ... thing. It's staffed by a bunch of people who worked on other browser projects in the past.

Lex Fridman 28:57 Truly independent web browser.

David Heinemeier Hansson 28:59 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, 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 applicat- 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

Lex Fridman 30:07 (sighs)

David Heinemeier Hansson 30:08 ... that we need champions in the corner of the web who have trillions of dollars of market cap value riding on the open

David Heinemeier Hansson 30:16 web.

Lex Fridman 30:16 We're gonna take tangents upon a tangent upon a tangent. So let's go to Chrome. I think Chrome positive impact on humanity is, is immeasurable for reasons that you just described. On the technology front, the features they represent, the competition they created, it spurred on this wonderful flourishing of web technologies. But anyway, I have to ask you about the, 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?

David Heinemeier Hansson 30:47 It's a disaster.And I say that as someone who's been very sympathetic to the anti-trust fight, because I do think we have anti-trust 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. 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 from exactly what's going on with the DOJ, that 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, 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, 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, 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 tollbooths 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. If I don't want to use Chrome, 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, and their ad monopoly maybe, or the, uh, shenanigans they've j- done in controlling both sides of the ad ledger, that they both s- control the supply and the demand. There are problems. Chrome isn't it. And you end up making the web much worse. And this is the thing we always gotta remember when we think about legislation, when we think about, um, monopoly fights, is you may not like how things look today, and you may want to do something about it, but you may also make it worse.

Lex Fridman 33:04 Mm-hmm.

David Heinemeier Hansson 33:05 The good intentions behind the GDPR in Europe currently has amounted to what? Cookie banners that everyone on the internet hates, that helps no one do anything better, anything more efficient, that saves no privacy in any way, shape, or form, has been a complete boondoggle that has only enriched lawyers and accountants and bureaucrats.

Lex Fridman 33:29 Yeah, you said that the cookie banner is a monument for why Europe is losing, is, is doing the worst, uh, of all the regions in tech.

David Heinemeier Hansson 33:40 It's-

Lex Fridman 33:40 (laughs)

David Heinemeier Hansson 33:41 ... it's a monument to good intentions leading straight to hell.

Lex Fridman 33:45 (laughs)

David Heinemeier Hansson 33:47 And the Europe is actually world class-

Lex Fridman 33:50 (laughs) Yeah.

David Heinemeier Hansson 33:50 ... in good intentions leading straight to hell.

Lex Fridman 33:53 So hell is the cookie accept button that you have to accept all cookies. That's what hell looks like. Over and over, you don't actually ever get to the web page.

David Heinemeier Hansson 34:03 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-

Lex Fridman 34:25 Mm-hmm.

David Heinemeier Hansson 34:25 ... and advertisement can make the web ugly, there's plenty of examples of that. But cookie banners made the entire internet ugly in one fell swoop, and that's a complete tragedy. But 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 does anything good for anyone, yet we've been unable to get rid of it. 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 or portend to make things better for not just citizens, but 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. You can't hide from cookie banners anywhere on this planet. If you go to goddamn Mars on one of Elon's rockets and you try to access a webpage, you will still see a c- cookie banner. No one in the universe is safe-

Lex Fridman 35:32 Yeah.

David Heinemeier Hansson 35:32 ... from this nonsense.

Lex Fridman 35:33 Probably the interface on (laughs) on the rocket.

David Heinemeier Hansson 35:36 It'll be even slower.

Lex Fridman 35:37 Yeah.

David Heinemeier Hansson 35:37 You have basically, uh, 150 second ping time-

Lex Fridman 35:41 Yeah.

David Heinemeier Hansson 35:42 ... so it'll take you 45 seconds just to get through the cookie banners from Mars.

Lex Fridman 35:46 Um, all right, let's walk back, uh, 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 36:03 It is. If I was gonna steel man the other side just for a half second-

Lex Fridman 36:06 Mm-hmm.

David Heinemeier Hansson 36:08 ... people would say, "Well, maybe yes, 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, and 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, and 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, and every single alternative browser on iOS have 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 you 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.

Lex Fridman 37:21 And by the way, we've never mentioned Edge. Edge is also a good browser. (laughs)

David Heinemeier Hansson 37:25 Because it's also Chrome in a dress.

Lex Fridman 37:27 But it never gets the love. I don't think I've ever used Bing, and, and I'm sure Bing is really nice.

David Heinemeier Hansson 37:34 Maybe you have, because you know what is Bing in a dress?

Lex Fridman 37:36 What?

David Heinemeier Hansson 37:37 DuckDuckGo...

Lex Fridman 37:38 What?

David Heinemeier Hansson 37:38 ... 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 37:47 Well, maybe everything is just a, a wrap or a dress. Everything is wearing a dress, underneath there's some other-

David Heinemeier Hansson 37:54 There's some of that.

Lex Fridman 37:55 ... turtles, turtles all the, dresses all the way down. Okay, what were we talking about? We got there from JavaScript and from you learning how to program,

Lex Fridman 38:03 so eventually the big success stories when you built a bunch of stuff with PHP and you were, like, actually shipping things.

David Heinemeier Hansson 38:14 Yes.

Lex Fridman 38:14 And that's when the, the Ruby story came. So what... Your big love affair with programming began there. So can you take me there? What is, what is Ruby? Tell the story of Ruby. Explain Ruby to me.

David Heinemeier Hansson 38:28 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. So I owe a 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 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. And 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 do code in that regard, and I connect 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 solicited advice. Jason had asked an- a question on the internet, and I had sent him the answer, and he was asking in PHP. And I had sent him the answer to that question, and 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? And by the way, we're still working together now 24 years later. That's incredible. But... We started working together, and we started working together on some client projects. Jason would do the design, 37signals would do design, I would bring the programming of PHP. And after we'd work on I think two or three client projects together in PHP, we kept hitting the same problem, that whenever you work with a client, you start that project off in email. "Oh, yeah, let's work together. Here's what we're building." And 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 someone, "Well, where's the latest file?" "Oh, I've uploaded it on the FTP. It's like final final V06 2.0." Right? Mm-hmm. 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. Mm-hmm. Email is the lowest common denominator. That's wonderful. But we had 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. And it has to be simple enough that I'm not gonna run a seminar teaching you how to use the system. I'm just gonna give you the login code, you're gonna jump into it." So that's Basecamp. Mm-hmm. And when we started working on Basecamp, I, for the first time in the experience I had with Jason, had 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?" Mm-hmm. I had free reins. And at that time, I'd been reading, uh, IEEE magazine- Mm-hmm. ... and a couple of other magazines back from the early 2000s, where Dave Thomas and Martin Fowler had been writing about programming patterns- Mm-hmm. ... and how to write better code. And these two guys, in particular, were both using Ruby to explain their concepts, because Ruby looked like pseudocode. Mm-hmm. Whether you were programming in C or Java or PHP, all three constituencies could understand Ruby, because it's basically just read-slang English. S- so these guys were using Ruby to d- describe the concepts. And first of all, I would read these articles for just the concept they were explaining, and I'd be like, "What is this programming language? I mean, I like the concept you're explaining, but I also want to see the programming language. W- why haven't I heard of this?" So I started looking into Ruby, and I realized...At that time, Ruby might not be known by anyone, but it's actually been around for a long time. Matz, the Japanese creator of Ruby, had started working on Ruby back in '93, before the internet was even a thing. And here I am in 2003, ten years later, picking up what seems like this hidden gem that's just laying in obscurity in plain sight.

Lex Fridman 43:31 Mm-hmm.

David Heinemeier Hansson 43:32 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 I thought, "This is... This is very different." First of all, where are all the semicolons?

Lex Fridman 43:55 Mm-hmm.

David Heinemeier Hansson 43:55 I'd been programming in PHP, in ASP, I'd even done some Pascal, I'd looked at some C. There were semicolons everywhere. And that was the first thing that struck me is, "Where are the damn semicolons?" And then I started thinking, "Actually, why do we have semicolons in programming?" They're to tell the interpreter that there's a new line of instructions, but I don't need them as a human.

Lex Fridman 44:20 Mm-hmm.

David Heinemeier Hansson 44:20 How? Oh. Someone is looking out for the human here, not for the machine. So that really got me interested. And then I thought to myself, "Do 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 gonna give myself two weeks. I'm gonna write a proof of concept where I talk to a database, I pull some records, I format them a bit, and I display them on an HTML page. Can I figure that out in a couple weeks?" It took about one weekend, and I was completely mesmerized. I was completely mind-blown, because Ruby was made for my brain like a perfect tailored glove by someone I'd never met. Like, how is this even possible?

Lex Fridman 45:14 We should say maybe, like, paint the picture of the certain qualities that Ruby has, maybe even compared to PHP. We sh- we should also say that there's a ridiculous thing that I'm used to that I forget about, that there's dollar signs everywhere-

David Heinemeier Hansson 45:27 Yes.

Lex Fridman 45:28 ... in PHP.

David Heinemeier Hansson 45:29 Yes.

Lex Fridman 45:29 I mean, that-

David Heinemeier Hansson 45:29 There's line noise.

Lex Fridman 45:30 Li- line noise (laughs) .

David Heinemeier Hansson 45:30 That's what I like to call it.

Lex Fridman 45:31 Line noise. Line noise, that's such a beautiful phrase. Yeah, so there's all these things that look like programs, and with Ruby, I mean, there's some similarities in Python there. Uh, it just looks kind of like natural language. You can read it normally.

David Heinemeier Hansson 45:47 Here's a wild loop that does, uh, uh, five iterations.

Lex Fridman 45:50 Mm-hmm.

David Heinemeier Hansson 45:50 You can literally type the number 5., now I'm calling a method on the number 5, by the way. That's one of the beautiful aspects of Ruby, that primitives like integers are also objects. And you can call 5 times start brackets. Now you're iterating over the code in that bracket five times. That's it.

Lex Fridman 46:15 Okay, that's nice.

David Heinemeier Hansson 46:16 That's not just nice, that's exceptional. There's literally no other programming language that I know of...

Lex Fridman 46:21 Okay.

David Heinemeier Hansson 46:21 ... that has managed to boil away the line noise that almost every other programming language would inject into a five-time iteration over a block of code to that extent.

Lex Fridman 46:32 Wow. That's a really nice... Oh, thank you for giving that example. That's a beautiful example. Wow, I don't think I know a programming language that does that. That's really nice.

David Heinemeier Hansson 46:41 Ruby's full of that. And there's... So let me dive into a couple of examples.

Lex Fridman 46:45 Okay (laughs) .

David Heinemeier Hansson 46:45 Because I really think it helps paint the picture. And let me preface this by saying, I actually, I like the ethos of Python. I think the Ruby and the Python community share a lot of similarities. They're both dynamic interpreted languages. They're both focused on immediacy and productivity and ease of use in a bunch of ways. But then they're also very different in many other ways, and one of the one ways they're very different is aesthetically. Python, to me, I hope I don't offend people too much. I've said this before. It's just, it's ugly. And it's ugly at i- in its base because it's full of superfluous instructions that are necessary for legacy reasons of when Guido made Python back in '87 that are still here in 2025, and 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. Okay, fair enough, that's actually the same as Ruby. D-E-F, definition of a method. Then it is underscore, not one, _2 init__ parentheses start self comma, and then the first argument (inaudible 00:04:52) .

Lex Fridman 48:03 Yeah, the whole self thing, yeah. Mm-hmm.

David Heinemeier Hansson 48:06 I look at that and go, "I'm sorry, I'm out. I can't do it."

Lex Fridman 48:10 (laughs) . Yeah.

David Heinemeier Hansson 48:10 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?

Lex Fridman 48:29 Hey, you're making me... You- you know where you're, like, talking about my marriage or something like this?

David Heinemeier Hansson 48:33 (laughs) .

Lex Fridman 48:34 And- and I'm now realizing I've been in a toxic relationship all along (laughs) . Yeah- yeahs, just get used to it (laughs) .

David Heinemeier Hansson 48:39 That, to me, by the way-

Lex Fridman 48:40 That's the problem.

David Heinemeier Hansson 48:40 ... 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. I didn't even have the concept that aesthetics, beautiful code, was something we could optimize for, that something we could pursue, and even more than that, that we could pursue it above other objectives. That Ruby is 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.

Lex Fridman 49:14 Mm-hmm.

David Heinemeier Hansson 49:14 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 __init__ make me repulse-But it does. And when I look at the Ruby alternative, it's really instructive. So it's def, same part, D-E-F, space, initialize, parentheses. Not even parentheses. If you don't need to call it with any arguments, there's not even a parentheses. That in itself is actually also a major part. If the human doesn't need the additional characters, we're not just gonna put them in because it'd be nicer to parse for the computer. We're gonna get rid of the semi-colons, we're gonna get rid of the parentheses, we're gonna get rid of the underscores. We're gonna get rid of all that ugliness, all the line noise, and boil it down to its pure essentials, and at the same time, we're not gonna abbreviate. This is a key difference in the aesthetics between Ruby and Python as well. Init, it's shorter to type, it's only five characters. Initialize is a lot longer but it looks a lot better, and 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. But 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, space, start parentheses, we all do that, and then you have, um, perhaps let's say you're calling a object called, uh, user dot is_admin, closed parentheses, closed parentheses, start brackets, and here's what we're gonna do if the user's an admin, right? That would be a normal programming language.

Lex Fridman 51:12 Mm-hmm.

David Heinemeier Hansson 51:13 Ruby doesn't do it like that. Ruby boils almost all of it away. We start with the if. Okay, that's the same. No parenthesis necessary because there's no ambiguity for the human to distinguish that the next part is just a single statement. So you do if space user.admin question mark.

Lex Fridman 51:35 (laughs) Yeah.

David Heinemeier Hansson 51:38 No open brackets, no parentheses, no nothing. Next open line, here's your 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 just 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 your statement you want to execute before the conditional. You can do user dot upgrade, say you're calling an upgrade method on a user, space if space user.admin question mark. 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. So, let's flip it around.

Lex Fridman 52:51 Mm-hmm.

David Heinemeier Hansson 52:51 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. Why do we have if and then an exclamation point? That's ugly. We could do user downgrade unless user.admin question mark." That to me is an-

Lex Fridman 53:18 That is beautiful.

David Heinemeier Hansson 53:19 ... encapsulation of the incredible beauty that Ruby affords the programmer through ambiguity that is only to serve the human reader and writer. All of these statements we've just discussed, they're the same for the computer. It'll compile down to the same C code that'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 the predicate method has... It's just incredible. It reads like poetry at some point.

Lex Fridman 53:55 It's, it's also incredible that, you know, one language designer is creating that. You know, Guido van Rossum also, it's like one person gets to make these extremely difficult decision because it's, you have to think about how does that all get parsed, and you have to think about the thousands, if it's a popular language, the millions of people that end up using this, and what they feel, what that question mark on the, for the if statement, what, what does that feel like for the user?

David Heinemeier Hansson 54:23 That's what Matz thought about because he started his entire mission off a different premise than almost every programming language designer that I'd heard at least articulate their vision. That 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. I once listened to James talk about the design of Java. Why was it the way it was? Why was it so rigid? And he was very blunt about it, which I, by the way, I really appreciate, and I think Gosling's done a tremendous job with Java, but his view of humanity is rather dark. His hum- view of humanity was programmers at the average are stupid creatures.

Lex Fridman 55:30 (laughs)

David Heinemeier Hansson 55:31 They cannot be trusted.... with sophisticated programming languages because they're gonna 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.

Lex Fridman 56:11 Mm-hmm.

David Heinemeier Hansson 56:11 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 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 dot times is a way to iterate over, um, a statement five times? That five is obviously a base class. It's a number. Do you know what? You can add your own methods to that. I did, extensively. 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 five days in seconds, because seconds is the way we set cache expiration times and other things like that. So you can say, "Cache expires in 5 dot days."

Lex Fridman 57:32 Yeah.

David Heinemeier Hansson 57:33 And you're gonna get whatever-

Lex Fridman 57:35 That's nice.

David Heinemeier Hansson 57:35 ... 5 times 24 times 60 times 60 is, or whatever the math is, right? 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 represent five days."

Lex Fridman 57:51 Mm-hmm.

David Heinemeier Hansson 57:51 In Ruby, you get to write five days, but even better than that, Matz didn't come up with it. Matz didn't need the five 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 who he'd 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 it. None does it with an articulated vision of humanity, a trust in humanity, like Matz does. That is the opposite end of the spectrum of Java.

Lex Fridman 58:46 Yeah, I mean for my aesthetic sensibilities, just the way you described 5 dot days, that's really pleasant to me. Like, I could see myself sitting alone, sleep deprived, and just writing that. It's just it's an easy thing. You can write it in a long way with a comment. You can, you can write it in multiple lines. You could do... And now with AI, I'm sure it's gonna 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 f- feeling there, and I'm sure we'll talk about happiness from all kinds of philosophical angles, but you know, that is what happiness is made of. (laughs) That little-

David Heinemeier Hansson 59:26 Exactly. And-

Lex Fridman 59:27 ... good feeling there.

David Heinemeier Hansson 59:28 And it's the good feeling that come out of a concept compressed to its pure essence. There's nothing you can take away from that statement that's superfluous.

Lex Fridman 59:39 But see, I, I also want to push back a little bit just 'cause it's not... 'Cause I also have programmed in Perl a bunch, uh, just, just to be cool. Um, so like, it's not all about compression.

David Heinemeier Hansson 59:51 No, you can compress it too far.

Lex Fridman 59:53 Right.

David Heinemeier Hansson 59:53 Perl Gulf 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 WALL, was a great student of Perl, was a great student of Python, and 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. So he was able to learn from his lessons. But what I found incredible about Ruby is that here we are 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 possible 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 the efficient market theory, that if someone comes up with a better mouse trap or better idea, others will eventually copy them to such an extent that perhaps the original mouse trap is no longer even remembered. No one has been able to copy that essence of Ruby. They 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 1:01:21 And we should also say like, you know, uh, maybe the perfect programming language is that, that metric, and then there's the successful language, and those are often different.

David Heinemeier Hansson 1:01:30 Yeah.

Lex Fridman 1:01:30 There, there is something wonderful about the Brendan Eich story of creating JavaScript-

David Heinemeier Hansson 1:01:34 Yes.

Lex Fridman 1:01:35 ... of, (laughs) of... There's something truly beautiful, uh, about the way JavaScript...... took over the world. I've, uh, recently got to visit the Amazon jungle and just one of my favorite things to do is just to watch the ants take over anything, everything. And it's just like, it's a nice distributed system-

David Heinemeier Hansson 1:01:53 Yeah.

Lex Fridman 1:01:53 ... it's a messy thing, there doesn't seem to be order, but it just works. And the machinery of it-

David Heinemeier Hansson 1:01:58 Worse is better. Worse is better. I mean, that's actually the name of a pattern for, in, in software development and other ways of how do... It's the pattern for Linux.

Lex Fridman 1:02:07 Yes.

David Heinemeier Hansson 1:02:07 Linux was quantifiably worse than, I think it was Minix at the time. Other ways of it that were more cathedral-

Lex Fridman 1:02:15 Mm-hmm.

David Heinemeier Hansson 1:02:15 ... less bizarre. And it still won. That there's something to it that the imperfections can help something go forward. It's actually a trick-

Lex Fridman 1:02:24 Mm-hmm.

David Heinemeier Hansson 1:02:25 ... I've studied to the degree that I now incorporate it in almost all 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.

Lex Fridman 1:02:35 Mm-hmm.

David Heinemeier Hansson 1:02:36 It's a little busted in ways that invite people to come in and help me-

Lex Fridman 1:02:40 Yeah.

David Heinemeier Hansson 1:02:40 ... 'cause 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 1:02:48 Yeah. That's awesome.

David Heinemeier Hansson 1:02:49 But Ruby is somehow, or was at least, a little bit different in that regard. Not in all regards. Matt's 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, I mean, hundreds of man-years to get Ruby to be both this beautiful yet also highly efficient and really fast.

Lex Fridman 1:03:15 And we should say that the thing that made you fall in love with this particular programming language is metaprogramming.

David Heinemeier Hansson 1:03:21 Yes. So that takes all of these elements we've just talked about and turned them up to 11. I'll explain metaprogramming real simple.

Lex Fridman 1:03:28 Yeah, please.

David Heinemeier Hansson 1:03:29 Metaprogramming is essentially a version of the five dot days. You get to add keywords to the language. ActiveRecord 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, um, descends from ActiveRecordBase. 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 space colon 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, to create comments, to 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. When 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. And when metaprogramming is used in this way, we call it domain-specific languages. You take a generic language like Ruby and you tailor it to a certain domain like describing relationships in a database at a object level. And this is one of those early examples where you can do, um, User has_many Comments belongs_to space colon Account. Now you've set up a, uh, one-to-one relationship. Before we had a one-to-many relationship. Rails is rife with all these kinds of domain-specific languages where... And sometimes 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. And Ruby does it at a level where you cannot tell my metaprogramming from Matt's keywords and with zero line noise.

Lex Fridman 1:05:56 Yeah. I should say that my first love was Lisp, so... There's a slow tear that you can't see.

David Heinemeier Hansson 1:06:01 I've actually never written any real Lisp myself.

Lex Fridman 1:06:04 Well, how can you judge it so harshly then?

David Heinemeier Hansson 1:06:07 Because I have two eyes and I can look at code and my aesthetic sensibilities forbid me to even go much further, which is a limitation, I know.

Lex Fridman 1:06:14 Mm-hmm.

David Heinemeier Hansson 1:06:15 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, but the past of programming languages. With Smalltalk, for example, I think Smalltalk is a incredible experiment that also worked but isn't suitable for today's programming environments.

Lex Fridman 1:06:36 I love that we're talking about Ruby so much and what beautiful code is and what a beautiful programming language is. So one of the things that is I think implied, maybe you made explicit in your descriptions there is that, uh, Ruby is dynamic typing versus strict typing. 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.

David Heinemeier Hansson 1:07:04 It's the essence of what makes Ruby, Ruby. This is why I don't fully understand when people call for Ruby to add static typing, 'cause to me, it's the bedrock of what this is. Why would you want to turn one of the most beautiful languages into something far uglier? 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. That was actually one of the things that just really sent me on a tear of getting meta or getting TypeScript out of some of the projects that I'm involved with. We pulled TypeScript out of, um...... Turbo, one of the front-end frameworks that we have, because I tried to write the 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 its essence. You can't remove one dot, you can't remove one character without losing something. This moment you go for static typing, that you declare at least, I know there are ways to do implied typing and so forth, but let's just take the stereotypical case of the j- of a example, for example. Um, capital U User, I'm declaring the type of the variable, lowercase user, I'm now naming my variable, equals uppercase User or new uppercase User. I've repeated User three times. I don't have time for this.

Lex Fridman 1:08:40 (laughs)

David Heinemeier Hansson 1:08:40 I don't have 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 them with text editors. I chisel them out of the screen with my bare hands.

Lex Fridman 1:09:21 Mm-hmm.

David Heinemeier Hansson 1:09:22 I don't autocomplete. And 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-

Lex Fridman 1:09:40 Mm-hmm.

David Heinemeier Hansson 1:09:41 ... to stay in the world where Ruby is beautiful. Because as soon as it gets easy to type a lot of boilerplate, well, guess what? You're gonna have a lot of boilerplate. Every single language, basically, 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. So, these things play together. There's the aesthetic part, there's the tooling part, there's the metaprogramming part. There's the fact that Ruby's ethos of duck typing, I don't know if you've heard that term before.

Lex Fridman 1:10:23 Mm-hmm.

David Heinemeier Hansson 1:10:23 It's essentially not about, "Can I call this method if a object is of a certain class?" It is, "Can I call this method if the method responds?" It's very out of Smalltalk in that regard. You don't actually check of 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 wanna 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 can have fewer bugs. You're gonna have less null pointer exceptions, you're gonna have n- less... All this stuff. Yeah, 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, with integration testing. Those are the kinds of precautions that will catch logical bugs, things that compile but are wrong, along with the uncompilable stuff. So, I've never been drawn into this world, and 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, 50 million lines of code, with hundreds, thousands, or tens of thousands of programmers, I fully accept that you need different methods.

Lex Fridman 1:11:49 Mm-hmm.

David Heinemeier Hansson 1:11:49 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 base camp, because I'm just a single individual. That's complete nonsense. In the real world, we would know that that makes no sense at all, that you don't, I don't know, use your Pagani to go pick up groceries at Costco. It's a bad vehicle for that. It just doesn't have the space, you don't wanna muddy the beautiful seats, you don't wanna do any of those things. We know that certain things that are very good in certain domains don't apply to all. In programming languages, it seems like we forget that. Now, to be fair, I also had a little bit, perhaps, of 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 unconceivable that anyone would choose any other programming language at all to write web applications. And I kind of engaged the evangelism of Ruby on Rails in that spirit, as a crusade, as, "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 learned that that's not the way, and 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, duck-typed language that I can chisel code out of a text editor with. And other people need the security of an IDE, they want the security of classes that won't compile unless you call the methods on it. I have 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 evidence, mountains of evidence to the contrary.

David Heinemeier Hansson 1:13:55 This is one of the reasons I'm so in love with Shopify as the flagship application for Ruby on Rails. Shopify exists at a scale that most programmers will never touch. On Black Friday, I think Shopify did one million requests per second. That's not one million requests of images. That's of dynamic requests that are funneling through the pipeline of commerce. I mean, 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 on Rails. So, Ruby on Rails is able to scale up to that level without using static typing in all of what it does. Now, 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, and some of those limits you hit with dynamic typing are actually, by the way, just limits you hit when you write five million lines of code. I think the Shopify monolith is about five 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 five million, if they'd been written in, let's just say, Go or Java, would have been 50 or 25. Now, that might have, uh, 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.

Lex Fridman 1:15:33 So, the thing does scale. That's a persistent myth that it doesn't scale. Uh, Shopify, and, and others, but Shopify, I think is a great example. Uh, by the way, I love Shopify and I love Tobi.

David Heinemeier Hansson 1:15:45 You got to have Tobi on.

Lex Fridman 1:15:46 Yeah. For sure.

David Heinemeier Hansson 1:15:47 I was talking to him this morning.

Lex Fridman 1:15:47 For sure. He's a brilliant... I, I got to hang out with him in the desert somewhere, I forget, in Utah. He's just a brilliant human. Um, and, uh, and, and Shopify... shopify.com/lux has been supporting this podcast for the longest time. (laughs) I don't, I don't think actually Tobi knows that they sponsor this podcast. I mean, it's a big company, right?

David Heinemeier Hansson 1:16:05 It's a huge company. I think, uh, just under 10,000 employees, market cap of 120 billion, uh, GMV of a quarter of a trillion every quarter.

Lex Fridman 1:16:16 And he's involved with the details still?

David Heinemeier Hansson 1:16:18 He is, very much so. Funny story about Tobi. Tobi was on the Rails core team back in the mid-2000s.

Lex Fridman 1:16:26 Really?

David Heinemeier Hansson 1:16:26 Tobi himself wrote ActiveMerchant, 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.

Lex Fridman 1:16:44 Yeah.

David Heinemeier Hansson 1:16:44 I think it's just... it's very inspiring to me, because it's such 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 1:16:54 Mm-hmm.

David Heinemeier Hansson 1:16:54 He runs a company of almost 10,000 people that is literally... like, world commerce depends on it, 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-

Lex Fridman 1:17:16 Mm-hmm.

David Heinemeier Hansson 1:17:16 ... to be able to encompass Rails being a great tool for the one developer who's just starting out with an idea, who don't even fully know everything, who is right at the level where PHP would have been a good fit in those late '90s, because, "Eh, I could probably upload something to an FTP server," and so on. Rails does have more complexity than that, but it also has so much longer runway. The runway goes all the way to goddamn Shopify. That is about the most convincing argument I can make for sort of dynamic range that 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. That was the pre-Shopify Shopify he created all by himself. And that was possible because Ruby on 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, that they can build system where they can keep the whole thing in their head and be able to move it forward such that you can go from one developer sitting and working on something, and that something is Shopify, and turns into what it is today. When we talk about programming languages and we compare them, we often compare them at a very late stage. Like, 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 on Rails. They then hit some scaling problems. It was a big debacle at the time. They end up then, I think, writing it in some other language, which, by the way, I think is the best advertisement ever for Ruby on Rails, because nothing fucking happened for 10 years after they switched over, right? Essentially zero innovation. Some of that was because they were doing a long conversion, and all of the early success in part came because they had the agility to quickly change and adopt and so forth. That's what startups needs. That's what Shopify needed, that's what Twitter needed, that's what everyone needs, and that's the number one priority for Ruby on Rails, to make sure that we don't lose that. Because what happens so often when development tools and programming language are driven by huge companies is that they mirror their org chart. React and everything else needed to use that is in some ways a reflection of how Meta builds Facebook, because of course it is, because of course it's an abstraction of that. I'm not saying React isn't a great tool and 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 on Rails.

Lex Fridman 1:19:59 Uh, let me say this as a small aside, because I think we might return to Shopify and celebrate it often. Just a, a sort of personal note...... a, this particular podcast has way more sponsors and sponsors that want to be sponsors than it could possibly ever have. And it's really, really important for me to not give a shit. And to be able to celebrate people, like I celebrate people, I celebrate companies. And it has n- I don't care that they're sponsoring. I really don't care. I just wanna make that very explicit because we're gonna continue saying positive things about Shopify. I don't care. Stop sponsoring. It doesn't really matter to me. But yeah, I just wanna, uh, make that explicit. So but to linger on the scaling thing with the Twitter and the Shopify, uh, can you just explain to me what Shopify is doing with the, with the JIT? What did they have to try to do to scale this thing? Because that's kind of an incredible story, right?

David Heinemeier Hansson 1:20:59 Yeah. So one of the great contributions that Shopify has made to the entire Ruby ecosystem, not just Rails, but in particular Rails, is YJIT. So YJIT is their compiler for, for Ruby that just makes everything a lot more efficient. And 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 the Ruby 1.8.6 that Tobi probably started on just as I started on. And that was enough to propel Shopify to the scale that it has today. A lot of the scaling conversation in, is lost in a failure to distinguish two things. Scale is kind of 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 a second and a half to execute, the user's gonna notice. Your app is gonna feel slow and sluggish. You have to get that response time down below, let's say, at least 300 milliseconds. I like to target 100 milliseconds as my latency. That's kind of 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 whether you can deal with one million requests a second like Shopify is doing right now, if you have one box that can do 1,000 requests a second, you just need X boxes to get up to a million. And what you'll actually find is that when it comes to programming languages, they're all the same in this way. They all scale largely beautifully horizontally. You just add more boxes. The hard parts of scaling a Shopify is typically not the programming language, it's the database. And that's actually one of the, um, challenges that Shopify has now is, 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 and so much on application servers, if we can get just 5% more performance out of Ruby, well, we could save 5% of those servers and that could filter down into the budget. Now, that analysis concludes into basically one thing. Ruby is a luxury language.

Lex Fridman 1:23:47 (laughs) .

David Heinemeier Hansson 1:23:47 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 it in. You simply have to slum it with a C or a Go or some other low level language or Rust, talk about line noise there for a hot second.

Lex Fridman 1:24:17 It's like the thrift store of languages.

David Heinemeier Hansson 1:24:19 Exactly. Where you need kind of just you need a very low level to do it. You can't afford to use a luxury language to u- to, 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 is not CPU cores. It's wet cores. It's human cores. It's human capacity to understand and involve systems. It's their personal productivity. I did a calculation once when someone had for the 400th time said that, "Oh, if you switch from Ruby to some faster language, you could save a bunch of money." And I calculated it out that at the time, and 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. So for me to improve my cost profile of the business, um, by seven percentage points, I'd have to pick something twice as fast. That's quite hard. Versus if Ruby and Ruby on Rails was 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 three or five, 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 six 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. If you're making-... Unreal Engine rendering stuff, like Tim Sweeney you had on.

Lex Fridman 1:26:13 Mm-hmm.

David Heinemeier Hansson 1:26:14 Yeah, he needs to really sweat all those details. The Nanite engine can't run on Ruby. It's never going to. It was not meant for that. 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