CoRecursive: Coding Stories - Story: David Heinemeier Hansson, Software Contrarian

Episode Date: February 1, 2020

David Heinemeier Hansson talks to Adam about being avoiding a software monoculture. He explains why we should find a programming language that speaks to us, why ergonomics matter and why single page apps and microservices are not for him. "That is the pleasure and privilege of working with the web. No one knows what you built it. It, you could build an in basic, you can build it a Ocaml, you can build in the Haskell, you can build it in whatever Ruby. No one is going to be none the wiser you get to choose" You want to write for the web. I mean, literally every programming language that's ever been invented and known to humankind is serving a webpage somewhere." "There's just something heartwarming in that, that this idea of the monoculture that like this is all just a battle to the death and there's going to be one framework and there's going to be one programming language that lifts is left standing. Programmers are really drawn into that right into that horse race." So much of their technology choices seem to be predicated on like, is this popular? Is this going to be popular next year? Do you know what I mean?" "The crimes against programming humanities that have been done in the service of single page applications are far worse than the ones that have been done in the service of microservices. But then of course, as it is, lots of people combine the two. So it's a fleet of microservices serving a single page application, and that's just where it bam, my head explodes with like, yeah, I would rather retire and fucking, I don't know, make weaved baskets than deal with that shit." "I'm not saying that email is sort of in its base form is wonderful, but you know what is wonderful asynchronous. Write-ups of cohesive, full thoughts, people using actual goddamn paragraphs to describe ideas and proposals, and they put those paragraphs together into form entire, cohesive thoughts. And then letting someone take that in, read those several paragraphs, sit back for more than five minutes. Ponder that. And then respond." Links: The Majestic Monolith On React TDD is Dead RailsConf 2014 Podcast Page

That is the pleasure and privilege of working with the web. No one knows what you built it in. You can build it in BASIC. You can build it in OCaml. You can build it in Haskell. You can build it in whatever, Ruby. No one is going to be none the wiser. You get to choose.

You want to write for the web? I mean, literally every programming language that's ever been invented and known to humankind is serving a webpage somewhere. Today's interview is with David Heinemeier Hansen, DHH from Ruby on Rails fame. This is really, it was a really fun interview to do. Some of the things we talked about include, let's say you like an obscure programming language. How do you make it popular? How do you use it to get work done? It doesn't have the libraries you need. How do you handle that situation? Also talk about current best practices that seem crazy. Ways of building things that seem complex. David is definitely of the school that you shouldn't play along. You should call things out if you think that they are overly complex or not productive. If you're familiar with David, you probably already know

that he is very passionate. He's also not afraid to drop some F-bombs. So there is some swearing in this episode. Also a lot of really fun, controversial and contrarian ideas. Enjoy the interview. Hey, how's it going? All right. I'm all set. Ready to roll. So I think that Ruby on Rails, it kind of changes the world in some ways, at least by a very small world of software development. I recall years ago going through some tutorial that I think was like build a blog in Ruby on Rails, and I was a C Sharp developer at the time.

It was kind of mind- like just how quickly you could build things. Why did Rails succeed? That's a good question. I think a lot of it was just the right time. There were just a bunch of things that had gone before the stuff that I'd made that essentially provided the foundation, but that I felt was just trapped. So I drew my main experience and influence for Rails from two camps. One was Java and the other was PHP. And I thought that Java was simply chock full of clever people who had clever ideas working in an absolutely terrible development environment. So if you could take those clever ideas and, as I like to call it, liberate them from the environment, you'd be left with some really clever ideas.

And they would be much more appealing. They would be much broader distributed. They were just very inaccessible for people who weren't already deeply enmeshed in that world. So that was where I drew the other inspiration, which was from PHP, where you literally could do a one-line thing that said print hello world, and it would show a web page. It would show hello world on a web page.

You just drop that file into the correct folder, and you're on the web. I mean, just such an incredible, I think to this day, still unsurpassed ease of Hello World. So I thought, hey, if we could take the great ideas around frameworks and how to structure larger software applications, and we could infuse them with that ease from PHP, there'd be a really interesting combo here. And that was really what I did, right? And then the conduit for that was Ruby. That was the sort of third missing element, the third secret spice to the dish here was that Ruby is simply an incredible programming language that enables you to have the best of both worlds,

that immediacy, that ease of introduction, that ease of use, like the print Hello World is almost as easy. Not quite because it's not targeted just at the web, yet it's a language that's also capable of carrying the ideas from something like Java. So that's really all I did. I took those three elements, put them in a pot, and started real good. I was building Basecamp at the time and I needed practical things, right? And I think that that approach to it, that the builder was also the toolmaker, gave it a unique feel that wasn't true in all other environments,

especially in the Java world. There were, at the time, a lot of this architecture thinking that people would be architects and all they'd be doing, they'd be doing frameworks and they'd be doing deep thoughts about how you should build applications. They wouldn't actually necessarily be building those applications, right? And the outcome was often sort of what Spolsky used to call architect astronauts, that they would get so high up in the stratosphere that you'd

essentially lose all oxygen and lose your mind. So my way of tethering myself to Earth was to actually build with what I was constructing. So Ruby on Rails turned out to be this really practical thing that was using influences from these three different environments. And then I had the blessing and the gift of being a newbie. I was new to Ruby when I started on Rails. Rails was basically my first real sort of project. So I didn't know what you couldn't do. And that went both for building something in Ruby, it went for making open source software. It went for a lot of things that I simply just didn't know what it entailed or what the challenges were or what I was supposed

to do and not to do. So I just felt like, well, this is the thing you can do. Of course, you can release a framework that does everything in its full stack and like 2000 lines of codes and you should show it off to the world. So I was influenced certainly by the open source community at large, but I was also repelled by it in some instances. It was very intellectual when you were pitching your software, like, well, here are the trade-offs, here's sort of the objective measures

for why we've done it that way, where I try to convey an emotion. What does it feel like to program in this environment? What does it look like? What does it taste like? What does it smell like to program in this environment what does it look like what does it taste like what does it smell like invoke all the senses not just like your uh prefrontal cortex right like go wider dig deeper into all the elements of being a human because i think if anything ruby's greatest insight was the programmers aren't just programmers. They're also human. And I tried to follow in Ruby's footsteps of appealing to the whole person, to sort

of a deeper humanity in programmers. And for reasons greater just than let's make software, right? Like let's make software that we really enjoy making, where the art of creating the software is a pleasurable experience in and of itself that can supersede and be more important than all these other attributes we keep talking about, whether that's execution speed or memory usage or all these sort of objective terms that feel like very concrete and very real. Ruby was incredibly daring, I think, by going out and saying, no, the most important thing, the most important design criteria for our programming

language is going to be programmer happiness. I mean, what a hippie concept. I showed up here and it felt like Ruby heard me. Ruby saw me. Ruby was sort of speaking to a deeper aspect of my being, almost sort of communicating with my soul. Now it's really getting hippie. And then Ruby sort of took my hand and showed me just how deep the rabbit hole could go. And by the end of it, I came out on the other side, loving programming, loving the creation, loving the dance with the syntax and the subtleties of the language and going like this is what i want to do with the rest of my life out of your three components ruby definitely seems like the most unusual i had never heard of it before uh rails i don't know if i would have heard of it if not for rails like Like, how did you come across it? Yeah, so when I first got introduced to Ruby,

it was absolutely this esoteric, very lightly used programming language, at least in the West. And I think it was 2003, I picked up a couple of these programming magazines. I think it was one from IEEE and maybe one from ACM or something else like that. And in one of them had an article by Martin Fowler where he was explaining some pattern and he picked Ruby to explain this programming pattern. And he said something in the intro akin to,

hey, I don't usually get to program in Ruby sort of professionally, but I'm just explaining a concept here. Ruby is very close to pseudocode. So even if you don't know Ruby, you'll be able to follow along. And then he showed his idea. And I thought like, wow, this is, wow, what a beautiful language. What an interesting, this looks very different from what I've done before. And then I think it

was Dave Thomas, who had another article in the other magazine where he was also talking about some programming concept or another, but he also picked to use Ruby. And I just got inspired by the fact that here are two of the great heroes of the programming world. When they are free to pick, they pick Ruby. So I thought to myself, when I had an opportunity to pick whatever programming language I wanted to use in, I should probably listen to these guys. They sound pretty smart. So I think that initial interest or that initial exposure just sparked something in me. And I quickly tried to learn everything I could about Ruby. And shortly thereafter, I think maybe 2004, I went to the third, it was called the third international Ruby conference, I think, which was

essentially an American Ruby conference. And I think there were about like 42 people there. And I was giving a talk on Rails at that point. I had worked on it for a bit and I was giving a preview of it. And at one point I asked, so how many people in this room get to work with Ruby professionally? And I raised my hand because I was actually getting paid to work on Ruby. And I think there was one other person who raised their hands. So this was like 2004. The main Ruby conference in the West has like 42 people there and like two people get to raise their hands. How many work with it commercially? And I think just a few years later, we'd be like 2,500 people at the Rails conference in whatever city that was. So it was kind of a wild ride and it was fun. And like, I look at now, I've worked with Ruby for what is it like 17 years now?

And I'm as excited as I was when I discovered Ruby 17 years ago. It is just truly uniquely beautiful, engaging, rewarding programming language. And I feel just utterly blessed to be able to still work with it. It's just a treat. So you went to this conference and these people were interested in the language, but weren't using it professionally, but were excited about it. Do you think that there's a broader lesson there? Like if I pick a language today that people are very excited about, but aren't using in their work, that that's like a sign that there's something there?

Yeah, I think it's always a great signal when you have people who are so enthralled by a technique or a tool or a language or whatever that they're willing to sort of just do it for the fun of it. That was really what the other 40 people in that room did. They did it for the fun of it, for the intellectual stimulation, for the excitement of getting to work and program with Ruby.

Like that's a very strong signal that there's something there. Now, that doesn't mean that that's going to be in programming with Ruby. Like that's a very strong signal that there's something there. Now, that doesn't mean that that's going to be the next big thing. There are countless tons of both frameworks and programming language and whatever that over time have had a very passionate, small core group of people. You can speak to Haskell programmers or OCaml programmers or whatever who are like, this is the best, greatest thing ever. And it is for them. It doesn't mean that it's going to be a mass movement in the way the Ruby on Rails is because truly very few things become a mass movement,

right? It doesn't necessarily matter. I mean, I'd be doing Ruby on Rails still if we were, I mean, maybe not 42, but 200 people. Well, maybe not 200, but 2,000 or 10,000 people, right? It doesn't have to be a million-person movement for it to be a place where you can live and breathe and work. I mean, I created Basecamp when Ruby had nothing, right? In terms of the tooling that I wanted and I needed to create web applications. I just created all that stuff for myself by hand. I mean, it's totally doable, right? That is the pleasure and privilege of working with the web.

No one knows what you built it in. You could build it in BASIC. You can build it in OCaml. You can build it in Haskell. You can build it in whatever, Ruby. No one is going to be none the wiser. You get to choose, which is really a unique advantage of the web as a distribution platform that is very seldomly cherished enough, in my opinion.

You look at all these other platforms, you look at, you want to write an Android application? It's going to be Java. Well, maybe you can write it in Kotlin, but it's going to compile down to Java bytecode, right? You want to write a thing for iOS? Well, you're going to write in Swift, right? It's just such a monolanguage approach. There are a few people who do something on the edges, but not sort going to write in Swift, right? Like it's just such a monolanguage

approach. There are a few people who do something on the edges, but not sort of in the broad sense, right? You want to write for the web? I mean, literally every programming language that's ever been invented and known to humankind is serving a webpage somewhere. I'm sure there's all sorts of applications out there that those programming languages don't have good access to other programming platforms, but they have access to the web. Yeah, yeah. That's an interesting kind of meta point. Like, if I find the language that's my Ruby, I might not be able to build Rails and have it be such a big success, but I can still make a framework. I can still build my stuff in it. I can still live in that world.

And you really don't need that many people for that to happen. I mean, I think when we look at the modern web pool chain, it's very easy to get overwhelmed and think, oh my God, we could never build that. You could just look at Rails, look at the number of lines of code that's in Rails, and you stare at that today and you think, oh, let me rebuild that in OCaml. And you're going to go like, yeah, that's just not going to happen. There's like tens, I don't know, maybe there's hundreds of programming years into that. But remember, Rails didn't start like that. Rails was serving real business traffic

on like 2000 lines of code. That's what Basecamp launched on. Ruby on Rails, I think was 2000. Maybe it was only 1000 lines of code, actually. I should know this. But it was a very small package created by one person in their spare time. And that was enough to get on the web, right? You don't need to recreate the entire tool chain. In fact, in many ways, it's better to start from scratch,

because this is your opportunity to jettison all the preconceived wisdom of what you're supposed to have, what you need to have. No, you don't. Can you print a HTML tag? Can you send back a 200 OK? There you go. Off to the races. Yeah, yeah. And you said business value, which is interesting as well, right? Because if I build my thing in OCaml, if it has business value and people end up using it, there's going to be some longevity there. Yes. And I think that that's sort of the magic of programming, right? Like we get to build these things out of sort of basically the spit of our imagination. And again, with the web, it's just, you can do it in anything. And like, no one is

going to judge you in terms of at least users using it, as long as it's a good application, right? Like it really can be done in anything. And then you get to have that longevity, at least if you're the ones working on it, right? I mean, Ruby had this argument used against it in the early days, which there's some validity to. But for example, let's say you build a large application in, let's say, OCaml, right? Perhaps your sort of talent pool for just hiring someone who can plop into that project and be productive right away is a little smaller than in the other wise bit. But it's certainly doable. And I think you should do it, right?

I love this idea that the web is being served by hundreds of different programming languages. That I could be using this web app I really like and it's actually written in OCaml or BASIC or Elgo 6 to 4 or whatever esoteric language it could be, there's just something heartwarming in that, that this idea of the monoculture, that this is all just a battle to the death,

and there's going to be one framework, and there's going to be one programming language that is left standing. Programmers are really drawn into that, right? Into that horse race. So much of their technology choices seem to be predicated on, like, is this popular?

Is this going to be popular next year like, is this popular? Is this going to be popular next year? Do you know what? I mean, fuck that. Not all, not in all places, but plenty of them who have the freedom to just pick something because like they want to do it. And I say to them, please do. I want to see what that OCaml next framework is going to be, right? I think actually one example of that, that I love sort of following from afar is Elixir. That here you have this sort of obscure, for a lot of programmers at least, programming language in Erlang. And then along comes Jose and says like, oh, this is actually great technology.

There's some core ideas here that are really important. Let me try to sort of shape those a little bit and make them more appealing to a wider audience. And here we go. Now there's a great programming platform and language. I look at that and just go like, man, that's amazing. I love that. Yeah, I agree. There is though, there is a certain weight like to popularity, right? Like there is a certain like fullness of libraries or whatever That is an advantage when you're... It is. It is. But I find that that advantage is often overstated. And the reason I say that is because that was literally the number one argument I kept hearing when I created Rails back in the day. Well, I mean, there's only like, there's so few programmers in it. Yeah. Everything starts from a seed.

If you expect that every new thing is going to be this thousand-year-old redwood, nothing new is ever going to happen. You have to have the seeds. You have to have the seeds. You have to have the people who are willing to nurture those seeds and accept the fact, yeah, they're not standing with the redwood right now. You can't drive through it. It's a small little thing and you have to protect it and you have to nurture it. And that's also really satisfying. There are people who really get a kick out of that, me included, that seeing my life's work in terms of ruby and rails grow from this tiny little seed that I planted in the ground, the fertile ground of Ruby, but ground nonetheless and seed nonetheless, grow into, if not a redwood,

at least a very strong, solid tree. It's just magic. And there are people who are attracted to that. And they're not all the same people. Some people just want, yeah, I just want to use the thing that's popular because I don't care as much or I'm not influenced as much or my boss is yelling at me or whatever it is. There's all these practical, reasonable reasons for why someone would just go like, just give me the most popular thing. That's got to be the best thing. And that's fine. It's great. It's okay. Ruby and Rails is in some ways a beneficiary of that same thinking, that once we tipped over and became this mass phenomenon, there were a lot of people who suddenly had permission to use it. And that was for a long time a driving force for me working on Rails was to make Rails popular enough that it gave people who didn't have otherwise a choice the permission to use Ruby.

That felt like just like a gift to the world and a gift that I essentially owed the world given the fact that I had found Ruby as a gift to me and my programming journey. So to return that favor to a broader audience was incredibly rewarding. And I think still one of the crowning achievements of all the work I've done on Rails is not just the Rails. It's the fact that so many people got to work with Ruby and perhaps they otherwise wouldn't have had. Maybe they would have.

Maybe someone else would have come along six months later and they'd created Bales or whatever, something else. And it would have gone on to be just as popular. But there's certainly plenty of examples where that didn't happen, right?

Like programming languages that had something to it where people saw a sparkle in it didn't go on to be a mess for a variety of reasons of either timing or fit or whatever else have you. So the fact that Ruby did and ended up being this mass language, like this mainstream language actually in many ways, like it's being used at sort of all these internet companies

that everyone's have heard of, right? Like it runs GitHub, it runs Shopify, it runs Square. It was the foundation of Twitter. It was like all these things, like people go like, oh yeah, I know that, right? And all these companies are now, many of them, big billion dollar companies that hire tons of programmers all the time. And those programmers get to use Ruby. And then there's this entire ecosystem.

What a wonderful thing. It's true, but I'm going to give you the negative spin on it, which is when you created Rails, there were people who were forced to do Java who didn't want to. There's people who are doing Rails now who don't want to. Yes, and I think that is a real thing. But I also think that's a sort of subjective truth that I absolutely recognize.

And then at the same time, if you were to do it on the grand scale of the number of people or the percentage of people forced to use Ruby who actively hate it, I am certain just in my soul that that is a far smaller number than the percentage of people who are forced to use Java who hate it. Again, certainly there are people who will be exposed to Ruby and go like, what the hell, right? Like one of the things, for example, is that Ruby is loosely and dynamically typed and some people simply have their brain wired in such a way that that is an offense to their sensibilities, right? And I respect that because I feel the same way about sort of statically typed languages. I just don't like them.

And I find that a lot of those people have been sort of forced into a bad situation from the start. Like they joined some company that had a truly terrifying code base because some people just wrote some bad code, right? And they associate that with Ruby on Rails and they go like, this is where I hate Ruby on

Rails because I have to work in this shitty code base every day and it's killing me. I think that's right. Yeah. Oftentimes it's actually just dealing with a horrible code base where everything might fall over and yeah, there's just no fun there. I definitely, I definitely find types really useful, but I do like but I do like Ruby as well. You know, when I first encountered it, it has some things that the aesthetics of it are unusual, right? Or maybe less unusual now, but certainly at the time, it seemed like a lot of things seemed like sort of the inverse as I would expect. Did it look strange to you? I think for whatever reason, Ruby was the programming language I'd been searching for my whole life.

And when I saw it and I saw just the layout of the statements and how it all fit together, it was just one of those eureka moments where how my brain thought about programming was expressed in this programming language. And I know that that's sort of that a people have that about all sorts of programming language. They go like, yes, again, we use this example over and over again. And the funny reason or the funny thing here is like, I actually don't even know what OCaml looks like. Like, I don't even have a mental picture of it. Right. But I'm sure there's some people who come to OCaml and just think like, yes, this is me. Right. Like, this fits my brain. And then there are other people who sort of acquire a taste for something

that they didn't like Ruby in the beginning and then they work with it for a while and then they do, or they didn't like Java in the beginning and then they work with it for a while and then they do. For me, it was just this romantic moment of love at almost first sight

and then just this disfection right from the get-go which is like, this is how I think. It is like if you were to do sort of the source map of my brain, it would map to Ruby. Nice. That's interesting. Yeah, it's funny. You just made me look up some OCaml examples. I think that you might like it because it is strongly typed,

but it's like inferred type. So there's not actually any types and it kind of... Please stand by. I see your screen. There's lots of lets. Yeah, it's funny because I don't know for whatever reason I had sort of a lisp look in my head when I said OCaml.

This obviously does not look anything like lisp. It doesn't speak to my sort of heart right away, but at this point I'm perhaps also beyond the point of no return with my love affair with ruby i will absolutely accept that that's a possibility yeah this is actually not bad like that that looks that looks pretty cool but yeah then i look at this although this is sort of uh this is one of the reasons why for a long time i thought i wasn't going to be a programmer like the code we're looking at now is sort of very mathematical

right like it's about math problems we And I was never interested in math problems. For the listeners, I pulled up the N Queens problem, which I think is a very mathy type problem. Yeah. And this is exactly why I literally thought I wasn't going to be a programmer, because I just didn't have any interest in math problems. I don't have any interest in algorithms beyond their utility. What I do have a deep, deep affection for is sort of domain modeling, sort of in the Eric Evans sense of the word, domain-driven design. I love noodling with a business domain. I love finding just the right words. I love sort of breaking the domain model apart and all that stuff, which is all sort of logical, sort of semantical approaches to it.

It is not algorithmic. It is not scientific. It's not math. Yeah. And I think that this was one for the longest time why I thought like programming is not for me because I knew quite a few programmers and they all did the math type programming. Like they were demo coders or game programmers or whatever. And everything was vector this and vector that and i would look at the code and i'd just go like

yep no interest absolutely zero interest in that and then i started working with the web and i started working with business applications and sort of it in the literal sense of information technology and and so on and i thought, oh, can programming be this too? This is what I like. Like programming of this sort, that's what speaks to me. That's what I'm interested in. And then I kind of just went like, let me double down on that. And then Ruby just felt like that was a perfect fit for that, right?

We looked at that piece of mathy code. And like the OCaml actually looked more clean somehow, right? Like it didn't feel like Ruby is the natural language for doing math-like programming. Yeah. So, I had somebody on as a guest and he was talking about how like some people really think about coding as math, but he thinks of it as like literature. What's your take on that? Yeah, I'm in that camp. I had a keynote at RailsConf, I think about five years ago, where I framed all of the sort of approach, how we think about programming. Rather than thinking about like construction projects or thinking about math problems,

I think about it as writing problems. It's about being a good writer. How can you be clear? How can you be succinct? How can you structure your paragraphs into cohesive arguments that make sense to a human reader that's the part i enjoy the writing part and the rewriting part like sort of the draft and the edits and boiling things down into sort of logically clearer components fitting those things together it's just like there's some division of labor here is that i have no interest in the zeros of the one or the assembler language above it or the C code above that, right?

I joined the stage by the time we get to the high-level programming language of Ruby. And then someone else with interests different than mine can do sort of the work beneath it. I think at the same time, I became familiar with Rails. There was a lot of excitement about it, but also, I mean, people who really didn't like it. And I mean, maybe that's kind of where the division was. There was people who, you know, maybe, I don't know what they were doing,

building databases or distributed systems where they thought they were. And they were like, this isn't real coding or, I'm not sure, did did you this is my impression was there was did that kind of pushback happen were i imagining it oh hugely hugely no absolutely happening today i've still literally listened to people say well what do they call it ruby is a scripting language and they say it in this sort of derisive tone right like it's not a real programming language.

And people are like, well, you can make prototypes. This is what I hear all the time. You can make your prototype in Ruby on Rails, but once you make a real application, you're going to have to rewrite in something else. And you just go like, dude, where have you been for 20 years? Like, look at the internet, you stooge. A lot of it is running off Ruby on Rails. You think Shopify is not a real application? You think Shopify is not a real application? You

think GitHub is not a real application? It's just the blinders of sort of ideology. And I can see where they're coming from, right? Because I'm actually, I'm a fan of ideology in many ways. I'm a fan about having values and practices and beliefs that underpin your path through life. But you got to recognize the fact that when you adopt an ideology, the trap is that it puts blinders on your head, right? And you start thinking that the values that you hold dear are these universal truths that are true for everyone, rather than just your personal truths. I'm very comfortable accepting just the personal truths of Ruby for truths. I'm very comfortable accepting just the personal truths of Ruby for me. I don't need everyone in the world to believe those same

truths. They're true for me. Ruby is the perfect programming language for the kind of work that I do using the brain that I have, right? That's about as personal of a statement as they come. But there are a lot of people who sort of adopt an ideology and then they just, they can't square other people having a different one, right? And then the cognitive dissonance of sort of other people being successful with a different ideology or a different toolkit like just blows their minds. Like they literally can't hold that truth in their head without going crazy. So, they just sort of dismiss it i guess their complaints have to do with trade-offs that that rails and ruby have right i think the vast majority of this is not based in sort of some logical empirical objective

evaluation of different languages i think it's absolutely a contrast of ideology and if you're a kind of person who goes like you cannot write sort of high quality software without static typing, like your head will simply not accept the fact that people are writing high quality software using a dynamically typed language like Ruby, right? And then you need to contort your arguments to support that conclusion, right?

Like then you come up with all this other stuff. There's a bunch of good books about how sort of the logical mind is actually not the one in charge, right? Like, it's our sort of primal mind, the one that operates on emotions and so forth that's in charge. And that mind will come to a conclusion, and then it will enlist your logical mind to come up with the justifications that support that conclusion. And I'm as susceptible to that as anyone. But I try to sort of limit those justifications just to underpin my own personal truths. And I mean, it doesn't always succeed. But yeah.

You think the enterprise Java guy looks at Ruby and Rails and he's just like primally angry about it. And then backwards he works and says like, well, it's not as fast as what I've written. Right. Or that that speed matters for that application I'm working on. I mean, that is the biggest joke of all. When back in the day when sort of the enterprise was the bar, right? Like, is this language enterprise ready? We don't talk about these terms anymore because they've been ridiculed to death. Because the enterprise usually means nothing of significance, right? Like these days, it's web scale, right? Like there's no enterprise

application that runs in what, a Fortune 500 company that does more traffic than say, Facebook pushes through PHP or that Shopify pushes through Ruby or that any of these mega companies on the web deal with. Like the enterprise is just small potatoes. It didn't used to be, right? Like it used to be that there was some sort of unique scaling challenges that the enterprise was facing, but that's not been true for a very long time.

I guess you're saying performance is not a trade-off that's being made, because it doesn't matter. I mean, not categorically, right? There are these cases. There are cases where you truly hit a hotspot or a bottleneck and you want to replace that with something. It's just that for the vast, vast, vast majority of applications, that point is so far out into the future or so imagined as

it might as well be a fairy tale. It isn't a fairy tale, right? There literally are people who deal with web scale. And when you're dealing with, I don't know, a million requests per second, like, yeah, you need to do different things. You can't use off the stock software. But that was always true. Even in the Java days, right? Like you can't use standardized tools to deal with extraordinary circumstances. You need extraordinary tools. Like this is why if you look at everyone from Facebook to Google to whatever, they've built their entire tool chain internally, right? Like Google built a goddamn programming language, right? Like Facebook built a new interpreter for PHP.

And like all these web scale companies eventually end up in a place where they build their own tooling because they need to. They're literally at the vanguard of sort of pushing things to the maximum. I mean, they're building their own damn hardware for Christ's sake, right? Like Facebook even is doing hardware design because like that just makes sense

once you have, I don't know, 200 data centers that have millions of computers and shit in them, right? These are not the problems that we, you and I face. And that like 99.99999% of everyone else making software today face. I'm interested in making software for the 99%. And do you know what? The 1%, they can go off and make their own software. They always have. One thing that I think is unique to the software industry, right, is like that 1%, I mean, they're really held in some reverence.

So we're all watching what they do and trying to learn from them. To our detriment. Yeah, like I guess if I watch somebody build a skyscraper and then I tried to build my house using like I-beams or something, that would be a mistake. Yes, there is a reverence. I think, thankfully, it is fading. I think both in society at large and also in programming circles where everything that

comes out of, say, Facebook or Google is not automatically just thought to be the greatest thing ever or in service of the noblest aims or goal ever, I think, finally. But also, just on the practical sense, trying to learn from the people who have the 1% problems and apply those to your 99% concerns is often exactly the opposite of what you should be doing. The constraints and challenges that Google face at web scale are just utterly irrelevant to what the 99% are dealing with. Not only are they irrelevant, like the solutions are literally the opposite, right? Like you simply, you almost couldn't go worse if you tried by looking at, oh, so how is the Google search engine implemented, right? Like what kind of setup does it have?

What kind of distribution does it have? What kind of distribution does it have? And then you try to apply those lessons to like how do you run your little web app like Basecamp? And I mean, you die before you even made it to Hello World. Because just the sort of construction of that whole rigmarole would kill you as a business right so i um that reverence is is better thought of as like sort of a distant appreciation not actually as a fucking guidebook right like it's it's it's actually the opposite and then worry about the the one percent problems when you're in the one percent right and it is all these sort of embarrassed millionaires that are wondering about like how to outfit their yacht while they have like 30 bucks in their checking account that I just think like, do you know what?

Maybe you have more pressing concerns than what marble to use on the fourth floor of your yacht than worrying about that, right? Like you should be worrying about like, well, how can I make something happen that people like? And now we're going to get 100 people to like it. I'm going to get a thousand people to like it, right? Worrying about what will happen once you have a billion users. And do you know what? I think you're wasting your time here. Yeah, but it's hard to find where the line is, I guess. I don't know. So let me give you some examples. So a company called Amazon, I think kind of pioneered microservices. And my experiences with it have been that it can be a pretty useful way to do things.

What do you think? Is this a trap? Do you know I have like a 15-minute rant of microservices sort of always in my gun holster? Yeah, I think microservices and the hype around it is probably one of the most damaging trends that has hit web development in the last 10 years. I think very few things have done more damage to sort of the integrity and the productivity of software development teams than the premature application of microservices. I am a stout and proud supporter of the majestic monolith. This idea that you have a single application that a single person can fully grasp, comprehend, understand, deploy, operate. And that is far, far preferable to this idea of having a fleet of microservices built in a hundred different toolkits and languages that no one knows how to sort of operate and go on.

Microservices is a great example of a sensational tech pattern. It's not actually a programming tech pattern. Microservices is what you do when you have teams so large that they essentially need dominion over their own domain, right? They need to sort of control their own boundaries and so on. And when you have 50,000 programmers, yeah, it's a completely reasonable pattern. And it makes total sense. Trying to apply it while you have two, five, 20, 50 programmers? Jesus, no. Just no. So, I would agree at five. I don't know, 50. 50 is a lot of people. Like it can be helpful to break people up into teams, right? And then it can be helpful if those teams have a clear,

you know, area that they own with clear interfaces. Yeah, I think that's just that the boundaries are much higher, right? Like I don't think it happens at 50. I think it happens much later in the equation and that the benefits of having a single application that everyone sort of operates on are vastly underrated. And that this appeal of the microservices approach neglects all the tremendous downsides to that approach, including the whole idea that a method call is now a network call, right?

And just the complications that come with trying to orchestrate different applications together. And I don't say that just out of sort of a high-minded theoretical concern. I say it out as a practical concern of someone who did microservices back in like 2006. Basecamp actually had a number of microservices when I kind of, before microservices, we called it service-oriented architectures. And it's sort of the same thing, depending on how coarsely you grain things, right? But we broke Basecamp up into a number of sort of subservices, right? And I learned on my own body just how different a method call is from a network service call. And it's funny because in some ways, we're traveling back in time here. When I got started with Ruby and with Rails, the big thing in Java was EJBs and J2E, which had sort of these remote and local services and which was essentially doing the same thing, right?

Turning method calls into network service calls. And it was a shit show then, too. And I think it is exactly as we talked about. People looking at the big shops. Oh, Netflix has 126 services to run their thing. Of course, we should have 23, right? And you just go like, no, you shouldn't. You should have one. That's funny. What about another example I can think of, I guess, is like single page applications or React. Like I think Rails is in the world primarily of like emitting HTML, but a lot of things are moving towards maybe a more freestanding front end. First, I think tons of Rails applications

are feeding JSON into React applications and all peace be with that. That's not how I want to build applications. That is another instance of distributed applications where you end up having one application on the front end that talks over an API to an application on the back end and And you end up with a lot of reimplementation back and forth and a lot of contortions to make that happen. And I'm not a fan at all. And at Basecamp, we try to not do that. And all of our approaches to dealing with the front end is in essence,

ways to get out of that while delivering the same high quality user experience. And there are, not surprisingly, tons of other alternative techniques that people can use. But I will absolutely say that React has been an astounding popularity success. I mean, it's really quite something to watch just how sufficiently it swept the world. I think it's more of a tragedy or a comedy than it is a documentary of how to do things well, especially once you mix it. And not so much just React in its core, beautiful form of sort of blow away the world and re-render. I actually kind of like that. It's more once you get into all the contortions needed to make a complete application, right? And Redux and all

these other things. When I look at a fair amount of that code, I look at some Redux routing code and I go like, do you know what? J2E was simpler than this. Even at its height of complexity, even at the height of the WS Death Starfer, it was simpler than this. Like, how did we end up here?

Holy shit. So even if I think that the single page application front end is a horrifically overused pattern far more so than than even microservices and i think so the crimes against programming humanities that have been done in the service of single page applications are far worse than the ones that have been done in the service of microservices but then of course as it is lots of people combine the two so it's a fleet of microservices serving a single page application. And that's just where I go like, ka-blam, my head explodes with like, yeah, I would rather retire and fucking, I don't know, make weaved baskets than deal with that shit. If I had to work in Assembler or even C, I'd go like, you know what?

I could do something else with my life. It doesn't have to be programming. And if someone told me, do you know what? You have to build a fleet of microservices and it has to work with a single page application front end, I could go like, do you know what? Farming sounds nice. Give me a rate.

But so we're different, right? Like it doesn't mean that that's just my personal truth as we were talking about, right? Like it doesn't mean that that's right for everyone. And clearly there are people who who like this thing and to each their own in some regard like i will continue to advocate for the fact that i think that this is bad but that's just my advocacy right and you have to discount that from with my biases and so on and so forth but you can use that as a counter melody to play in your head for reconsideration when you think, oh, let me just go with what's popular in the industry norm.

Like, let me start up with my microservices. Let me go for my React, Redux, Monstrosity. And like, that's best practices, right? You'll have me sitting as a little canary singing, no, it's not. Right? Or like, that's a dead end. Like a canary in the coal mine laying with my tongue out just going like don't go so deep you're gonna die like you think we make things too complicated like just

in general um i would even go stronger than than think in that statement i would say people make things too complicated period and it's tragic period and i wish they wouldn't, period, and I'm trying to focus most of my advocacy on helping them unlearn the things that they have learned that have led them down this tragic path. So, yes, I think that programmers in particular are susceptible to the siren song of complexity, and they get this kick out of being able to master that complexity and to wield that complexity, whether it's appropriate or not. It feels just like a sense of intellectual accomplishment that you can figure out the most gnarly shit on the universe. Like a multi-microservices-backed application serving a single-page front-end application. You can go like, I am victorious.

I beat the computer. And you can feel good about that. And I just go like, okay. I mean, we the computer. And you can feel good about that. And I just go like, okay. I mean, we all have our kicks. That's not my kick. And let me tell you that there is a different way here. How about unit testing and test-driven development? You're hitting all the highlight hot buttons here.

Yeah, I gave a talk. It was actually that same talk, the one we just talked about about software development being writing. 2014, you can look it up on YouTube, where I call TDD the greatest diet fad that the software development world has ever seen. And I kind of labeled in that it that from a perspective of sort of this approach of pseudoscience, right? TDD presenting itself as the scientific method of creating better software. And I just thought it was bullshit.

And I lived under it for a long time where I thought, yes, the gospel is true. TDD is truly better. And I'm a bad programmer and a bad person because I don't get it, right? I wrote TDD. I wrote a lot of TDD, right? Test-driven development. I wrote a lot of tests first, and then I wrote my code. And I didn't like it.

I thought it was not a way that fit with my flow of my brain. Like most of the time, what I will do is I will explore my programming first, just sort of exploratory. I'll figure out how it works. And then I'll write my tests afterwards. I'm a huge believer in automated testing. It often serves the proponents of TDD to conflate those two things. Like, oh, you're against TDD, therefore you're against automated testing. No, you're not. What the fuck are you talking about? I love automated testing. What I don't love is to drive my development through my tests. I don't love writing my tests first and then writing my code afterwards. I don't love having my tests dictate the inner workings of my classes and my methods to serve some sort of testability purpose. There's TDD proponents who simply

believe that if you write code, it's easy to test, it. There's TDD proponents who simply believe that, like, if you write code, it's easy to test, it means it's better code. Bullshit. No, it's not. I did a whole series together with Martin Fowler and Kent Beck on this topic when, back from that 2014 talk, when I sort of provocatively pronounced TDD to be dead. And I pronounced it to be dead in sort of that Nietzsche sense of the

word that God is dead, right? Like it's not that God doesn't exist. It's that it doesn't, he doesn't hold the central focal point in our universe anymore, right? And that's how I felt about TDD. The TDD for a while held that central focus point in a programming universe. And I wanted to kill that, right? Or I wanted to see that die. I just got fucking tired of listening to people tell me like, I just didn't get it. No, I get it. I just don't agree. Like those are two separate things, right? The TDD advocates or whatever, they always seem a bit too keyed up or something. Like it's the, it solves everything. What about just like, just like unit tests? I believe I watched something where you were saying unit tests, not as valuable as people think.

We usually have about half as much test code as we have production code. And that's been a ratio that's been surprisingly stable across all the applications that we've done at Basecamp. Not because we designed it that way, but that seemed to just be a heuristic that for us, for our application, turned out to be. That's the level of tests that we sort of like to have the confidence for our code. And unit test is one part of it. But I think that oftentimes, actually, I've stopped calling it unit test. What we call it now, we call it model tests, because some purists took offense to the fact that when we do unit tests in Rails, in particular, we often end up talking to the database, right? Which is a big no-no when it comes to unit testing. You're supposed to isolate all your sort of dependencies and test only in

isolation, both for speed and for repeatability and blah, blah, blah. And I just went like, do you know what? I'm not interested in that. Those kinds of tests do not reveal anything interesting for me. I want to be able to test all the way down to the database layer when I test my models, because that's where I often find the bugs or the issues or whatever. And I don't really like mock or stub data. I find that it often introduces all sorts of bugs, and then I need to deal with those and da-da-da-da-da. We write some model tests, and I think model tests are great. And then we also write some sort of controller tests, which happen at the layer above. And those controllers also do not stop anything out.

They actually call the real models, and those real models call real database calls and so on. And then above that, we write whole system tests that flex the system perspective of the job and driving a browser and so on and so forth. Sometimes you have the same thing tested in your model test as you do in your control test and as you do in your system test. And other times you just go like, you know what, the system test coverage here is fine. The controller test coverage here is fine. I don't need to replicate everything down to a unit test level because I have the level of confidence that I need or want in my code. So we're done. There you go. Your book had some interesting things that were kind of like more organizational, but that I found equally shocking. Like in my work, we meet daily, kind of we have a standup meeting where we kind of all say how things have been going, if anything's in the way.

Do you think that's a good use of time? In the broad sense, no. I think the requirement for stand-up, which often has these connotations of in-person, that they're better when they happen sort of face-to-face, are not worth their price. And the price, especially for in-person stand-ups, are synchronization of time, that everyone shows up at the same time, synchronization of space, that they're all in the same location at the same time. These are dramatic compromises and costs

that I could never subject our organization to. And the value you get out of that synchronized link up to me seems very small in comparison, right? The advantages of remote working, we have 56 people at Basecamp and I think the city that has the most people in one city is like Chicago and there's like 10. We could not operate our business like that if it was for an in-person standup. Now, people do these standups, they do them over sort of video chat or whatever. I also find that just to a lot of time be a waste of time. We don't need a synchronous meeting that's sort of on the calendar every day to give status reports. In fact, writing status down is a far better use of time. So people can show up

when they show up, they can read it at their leisure when it fits into their schedule of the day and then you can have this asynchronous communication back and forth if there's blockers that need to to happen now that does not mean that there is never a time where you should sync up synchronously and talk things through when you hit real deep blockers where you need to do collaborative design work together by all all means, jump on a video chat. I do that all the time. It just doesn't happen like every day. Barely happens every week. Maybe it happens every few weeks

that we have a thing where we go like, oh, this is a real hard problem. We don't want to wait for the asynchronous back and forth. Like most of our design problems, we solve through pull requests and comments. And someone will chime in on that pull request when they're ready. And someone will read those comments when they're ready.

And it's plenty good enough. And you don't need these synchronized gears that kind of grind the whole organization to a halt unless they line up perfectly. So I work remotely from here. I have for some time. And my team, so we all kind of do our standup on Zoom as we're talking now.

You know, one thing that I get from seeing people's face, like maybe not everybody's as vocal as you are. So like if I'm saying like, oh, we need this new calendar thing. So I'm going to rebuild this section using like React and a single page app. Like maybe I'll see somebody wince and then they can explain. I agree. It's important. Humans are important.

Looking at humans move and picking up the subtle clues important. Every day important? No. We do these synchronizations at Basecamp every six to eight weeks. So we run these six to eight week cycles, which also comes into a whole critique. I don't know if we had time for that too, but I think sprints and the whole sprint language is absolutely a travesty and a harm to the software development community at large. This idea that you should be constantly sprinting and that sprints should only be like a couple of weeks long, I think has caused immense damage and harm to software development. Now, it came as a reaction to something that I totally understood why that reaction came, right?

Like if you're used to sort of projects that run on for years and years, you go like, holy shit, this feedback loop is totally broken. Let's do the counter to that and let's just do it every two weeks. I just found that like doing that every two weeks is its own kind of harm. And where we ended up at Basecamp

was with this methodology we called ShapeUp. We just published a web book around that. It's basecamp.com slash ShapeUp that details our full methodology and how we approach it, the software development process. And that process includes that every six to eight weeks, you have essentially sort of some cool down time where you consider what you do next. And it is in that time when we sync up and we have a chat face to face, well, Zoom to Zoom or video chat to video chat, where you go over what you should build next. If you are in the middle of developing

things and you just come up with, hey, we should build a calendar in React, your software decision making process is broken, right? Like if you can just on any given Wednesday come up with a whole new branch of feature, something's wrong. Yeah, I guess my example's bad. But sometimes people thrash, right? Like they just start working on something and they get stuck. And I don't know. Yeah. Totally.

And you should follow up on that. And you can, right? Like if you have someone observing the work and following along and doing pull request, you can see when people get stuck. And then you can do an intervention when that happens. But over sort of prescribing that intervention to be something that has to be applied every single day for every single one is to me a complete misapplication and misintervention and actually disruption and one that comes at great cost. How about just like I use Slack and, you know,

often pinging people on my team to ask them questions. My condolences. Not useful? Harmful. I think actually the introduction of chat as a main source of company communication has probably been the most hurtful introduction in the history of sort of interactive communication tools. And I say that as someone who built a, essentially a chat tool,

just like Slack in 2006 called Campfire. And for many years, essentially ran a company on that philosophy. It's a terrible way of working. And you don't realize it until you take a step back and look at how your day's spent and how it's broken up and the cognitive harm that happens through interruptions. That if you can't seem to get two, three, four hours of uninterrupted time without someone pinging you or interrupting you, it's not good. We have a whole big write-up on this that Jason, my business partner,

just recently finished called Group Chat Stress. Again, not that chat is always bad, but the chat as a main mode of communication is a horrible interruption and intrusion on people's productivity, cohesion, and sanity. So you have this partial attention syndrome

going on all the time because of chat versus sort of the reaction that chat came to, which was email, right? Email has in its sort of most naive implication a lot of all the issues, right? Like I'm not saying that email as sort of in its base form is wonderful. But you know what is wonderful? Asynchronous write-ups of cohesive, full thoughts. People using actual goddamn fucking paragraphs to describe ideas and proposals. And they put those paragraphs together into form, entire cohesive thoughts. And then letting someone take that in, read those several paragraphs, sit back for more than fucking five minutes, ponder that, and then respond.

That is all lost once you move your collaboration to chat. Every person now thinks on a line-by-line staccato basis. And you know what? The quality of that thinking is low. It is poor. And it has all sorts of cognitive consequences

to interrupt people constantly during the day to get them to reply to this or reply to that. And I think chat has really done tremendous harm in that regards. And in some ways, we're still healing our organization from the harm that chat has influenced. Because once you pick up the habit of chat, once you pick up the habit of pinging someone, it is so fucking addictive. Like you have the slightest issue, you're stuck for 30 seconds. Oh, let me ping Sam because Sam knows the answer, right? With no consideration about whether Sam is in the zone trying to solve a real hard problem, right? You just ping Sam, hey, Sam, what's up with it? Can you solve it for me? You have no consideration about what the cost of that interruption is.

And often the cost of that interruption is incredibly dear, right? Because Sam wasn't just pinged by you. He was also pinged by, I mean, Susan and Jack and a bunch of other people, right? That you didn't even know. And before you know it, Sam has spent his entire day just answering other people's questions, trying to get into his groove, into his loop, and he has nothing to show for it. Absolute travesty. Absolutely a contributor to burnout and all these other things. Chat is not the sort of devil in all regards. And I think especially the social components of chat can be quite helpful and useful to create cohesion in a remote team. And they're good and you should do some of them. You just shouldn't drip it throughout the whole day and require everyone to pay attention through the whole day and require them to be immediately responsive to someone pinging you on chat.

We have a concept, for example, called office hours. Let's say you have someone like Sam, who's the expert in some domain, and a lot of people have questions they want to pose of Sam. Sam decides that Thursdays from 10 to noon, you can reserve time with Sam to ask him questions about his expertise. And you don't pepper those questions over the whole week. You simply hold them until it's fucking Thursday, right? And do you know what?

Most of the time, you'll solve your own problem sooner, and you'll learn more, and you'll be better. You have taught yourself how to fish before it's Thursday, and it's not relevant. Or it gets to be Thursday, and you get some real dedicated time where you're not in position, where everyone has agreed upon that this is now a good time to do it. And Sam has set time aside to be available for you. And that works well. It makes sense. But at the same time, because of the way that I feel like I'm working currently, it sounds insane. Like that I would wait till Thursday to talk to Sam. Yeah, totally. Because we've all gotten addicted to right here, right now ASAP.

Yeah. And that is a terrible addiction that is very hard to break. Once you've become addicted to ASAP, almost anything else seems insane. I can totally see that, right? But actually, the insanity is the water that we're in. I love this commencement speak by David Foster Wallace that goes, this is water. You can look it up on YouTube, which basically goes to say that you become blind to your insane environment very quickly. To me, it's an absolute insanity that anyone can interrupt anyone else in an entire company at their leisure with no warning, no consent, and just like, hey, because I want to. Fuck that. It is such a selfish view of the world, right? And I think it's counterproductive. And when it happens back to

you in return, you don't like it, right? People like helping other people. So this is why they always say yes, right? This is why you never get like, hey, can you help me with this? And people say, no, come back on Thursday, right? You need to set up procedures and protocols for this to be effective. And if you don't, you just get this selfish imposition of people stealing other people's attention in sort of these slight inconveniences just because it's good for me. It's good. This is what I want right now. I want someone to help me this second.

It can't wait 10 minutes. It can't wait an hour. I can't write it up as a post for Sam to ponder later. I just need this right now. No, no, that's that's insanity. But I totally I mean, your reaction is is a perfect um reflection of of how most people respond to a lot of the ideas we have about how to work right you you go like well this is not how it worked like this that seems crazy like right yeah which is i mean that's literally

the title of our latest book it doesn't have to be crazy at work yeah so we're running out of time but yeah i really like the book it's it's very i think it's short and pithy and i guess the big takeaway i got was something like that. Like, hey, we're all really busy, but we're not getting anything done. Maybe we should stop that. Yes. Isn't that insane, right? The fact that people can't get work done at work.

Yeah. That so many people think like I have to show up early in the morning, stay late at night or work weekends because that's the only time I can get my actual work done. If I'm just there in the office from nine to five, what will happen to my time is I have to spend half of it paying attention to some rolling conveyor belt of chat. Then I have to spend the other half with people pinging me. And then another half, and now we're up to three halves,

that's intentional, being pulled into all sorts of meetings for status reports. Holy shit, just shoot me now. So I recommend everybody check out the book. Thank you so much for your time. This has been a lot of fun. Absolutely. Thank you for having me on and pushing all my red buttons. That's what I'm here for. Awesome. Thanks, man. All right. That was the interview. I hope you liked it. What did you think? Let me know. I

thought that he was super interesting and I kind of wish I had pushed back on him a little bit more about types because I really like types and I find them super valuable. And I kind of wish I had pushed back on him a little bit more about types because like, I really like types and I find them super valuable. And I really just think that I can convince them that they can be like very unintrusive and helpful, but I do like, I do still find microservices a valuable way to cut things up sometimes. So yeah, I don't know. Anyways, that was the show. Let me know what you think on these topics. Maybe you disagree with them. Maybe you agree. I know a couple of people who think more like him and that we've kind of gone into some architecture astronaut mode in the industry recently with all of this, you know, Kubernetes

and microservices and front end frameworks, but I'm not sure. What do you think?