December 13, 2022
David Heinemeier Hansson is the creator of Ruby on Rails, co-owner of 37signals (makers of Basecamp & HEY), a best-selling author, Le Mans class-winning racing driver, antitrust advocate, and investor in Danish startups.
Julian: Thank you so much for joining the Behind Company Lines podcast. Today we have David Heinemeier Hansson, co-owner and CTO of 37signals, who are the makers of Basecampand HEY, David, I'm so excited to chat with you. Learn more about your background, your experience. Not only are you a builder of companies, you're a race car driver, and we'll get into what that means in juggling that and other responsibilities.
But really just truly excited to chat about the whole, you know, building process around company the youth of technology and how we enable, you know, clients and customers and everything along that. But what were you doing before you started 37signals?
David: Well, so I'm just trying to say, it's almost hard to remember. I've been working at 37signals with 37signals on 37signals for, I think it's 21 and a half years since 2001, which is literally half my life and the majority of my. Adult life. So, back before I got started working with Jason, my business partner at 37signals, I worked at a number of different startups and companies in the Danish startup scene.
This was just around the.com. Boom and bust, which proved to be very influential in my outlook on the technology industry and how we were going to run a company at 37signals after the fact. But I kind of got started working with Jason on 37signals and all the things we've. Built on a whim. I mean, the company had existed for a couple of years as a design company.
I'd been interested in it, and I was sitting in Copenhagen, Denmark. I happened to send Jason, who was in Chicago, Illinois, an email on the basis of a blog post that he had written and. Boom boom. One thing led to the other and we kind of started working together, but when I started working with Jason, I had only barely just learned to be a professional programmer.
So it was not like I had this long, illustrious career behind me before I teamed up with Jason and we started working on 37signals together. But it was still an inflection point. I mean, I had learned how to program. Through some of these other projects that I've been working on. But this was really the first true commercial engagement where someone was paying me to program, not just paying me to make html or styling things or even JavaScript.
So, really it is the total sum of my career. If you go to my LinkedIn page, it has one entry and it just says 37signals, 21 and a half years.
Julian: I love that. I love that. And what would you say the experience is kind of coming in, kind of learning as you go along? You know, a lot of founders talk about that being a part of the process when they're building companies or jumping into a project.
Is this whole process of having to learn, you know, while you go along but in particular you were learning not only your craft, but also how to build. What was that process like?
David: Well, I think when you start like that, you are blessed by ignorance. You're blessed by not knowing how difficult all sorts of things are.
I think many of the things we took on both as the company in terms of the products, but also in terms of things like Ruby on Rails. The web development framework that I created as part of creating basecamp and releasing that at an open source. I took all that on because it was like not knowing how difficult it would be or what it would entail if you had told me upfront, Hey, do you know what to really built this web framework?
You're looking at thousands, if not tens of thousands of hours of investment that you have to put into it, but very well have gone like, yeah, you know what? I don't know if that's. But this ignorance, this benefit of ignorance of not knowing how difficult something is. . It's a powerful motivator to get going because as humans, we are just intrinsically equipped to underestimate the challenge of whatever we are taking on if we haven't done it before.
I think the problem actually often comes in when you try to do something for the second or the third time that you tried to preempt all the troubles and tribulations that you faced the first time along the way. And some of. those Might help you, but many of them might not be relevant in the given situation, or it might be something completely different that you have to worry about.
So I do think there is just a unique blessing possible with that blank canvas of, I haven't done it before. I have to figure it out. And particularly if you're approaching that process from first principles, I will figure out what makes sense to me, to us in this given situation based on. Sort of the firsthand research.
I'm not gonna just take a playbook that someone else has written, or even my own playbook that I've written developing something else and just following that, I think it really is a unique, wonderful opportunity to be able to start something from scratch and not knowing where it takes you, not knowing how difficult it's going to be, but trusting.
That you'll figure it out. And I think that's one thing what Jason or I had perhaps in some ways in excess, was a confidence in our own ability to figure things out along the way that whatever trouble or challenge would show up on a given day, it was something we could figure out that we weren't scared that Oh, what if someone knows more?
What if someone's done more? Yeah. Do you know what all those people started from exactly the same position that we. Once upon a time too, everyone have the experience they have today because of the time they didn't. Yeah, there literally is no other way to gain that experience than to try things you haven't done before.
So embracing that and embracing it with the full confidence, perhaps. Excessive confidence of thinking. Do you know what it's gonna. I'm gonna figure it out is something I found to be a far more successful and happiness, conducive way of trying to do a business. Run a business. If you're constantly second guessing yourself, oh, I don't know if I can do this, or, I don't know if we should do this, or, Oh man, that just sounds exhausting before you even get going.
And there's plenty of real reasons to get exhausted about starting a company or creating a new piece of technology. You don't need all the invented reasons on top.
Julian: Yeah. Yeah. In regards to, you know, Ruby and building kind of a new you know, new way to connect, you know, on online stores and kind a more sophisticated, you know, purchasing and browsing experience that a lot of from the use case I've seen that's what a lot of people use it for.
What was the catalyst in that, during that? What was the you know, I guess the incumbent technology that wasn't giving you what you needed, that you needed to create a new technology to do so?
David: Yeah, so when we started working on basecamp we started working on it as a side project with me, as the sole technical person involved with the project, and I had 10 hours per.
To work on this thing, and I found that the existing options be they Java or php, and the tooling available in both of those, neither of them really gave me the confidence that I could build something. That could not only work, but that I would be thrilled to work on with those tools. So I found this programming language Ruby, by following some other technologists in the industry who had been writing about this relatively unknown and not very used programming language out Japan called Ruby.
This is back in 2003. We start working on basecamp and I. Free choice. I could pick whatever I want. I am the sole technical person on the job, and Jason's not gonna tell me what to use. So it felt like a rare privilege to just go with whatever I felt to be best. And I picked up this programming language, Ruby, which didn't really have a lot of tooling for creating web applications.
And I thought, you know what? This is so good. This is unleashing my. Creative juices in a way no other programming language has ever done for me before. This just fits my brain like a glove. I can build the things that are missing. I can build what we need to take this programming language and use it to create something like base cam.
And that's exactly what I did. So I took the, if you will, raw programming language and I just started building basecamp with it. And of course I kept hitting thing. Thing that I needed to build the tooling to get there. Oh, I need something to talk to the database. I need something to generate edgel.
I need this, I need that. And before I know it, I had a complete toolkit that was useful for building the kind of web application that I had just built, which. Happens to be quite the product, typical application that most people were trying to build at the time is still trying to build, which is, as we call them, crud applications, create, read, update, and delete applications.
Basically user interfaces. To a database. And here we have this unique programming language that places this focus on the programmer, not just a computer, which was a real mind shift at the time, that having happy programmers could actually be an objective worth optimizing for in and of itself, not just a byproduct of using some programming language, but the primary.
Design apparatus as Matt, the creator of Ruby put it. And and now I've built this web application framework that others can use to enjoy that glorious programming language as they built their own application. So ending up with both of those things was just a real pleasure, but I really did it for.
I did it such that I could be able to use Ruby to create the work that I was interested in creating. And then it just so happened that lots of other people saw it the same way once I in induced him a little bit to giving it a try. And today we have. Some amazing applications. Everything from Shopify to GitHub to Hulu to basecamp, to hey to, to so many other things that have been created with with Ruby on Rails.
I saw one count saying there's over a million internet applications online today built with Ruby on Rails, which is quite astounding.
Julian: Yeah. That it's fascinating to, when you said the piece about it, it's putting the developer first and then coming from a developer's perspective into building applications.
What does that mechanically mean? I, is that how the language is set up? Is that how, when you're inputting certain information and outputs or what in particular are part of the mechanics that allow it to come from that perspective and how's it different from other languages prior?
David: Yeah, so a lot of programming languages at the time that MATS was creating Ruby, were explicitly, or not even explicitly, actually implicitly, because this was understood to be the main design objective focused on making things easier on the computer.
How do we make this easier to compile? How do we make it faster? How do we make it more memory? Efficient. How do we do all of these things? And then the ergonomics as they arrive to the programmer is downstream. From that you will get whatever it takes to make the computer happy to execute your program.
And Ruby flipped it out. Its head and said, we are willing to make it difficult on the computer to understand what you're writing if that enables you to write programs in a natural human way. And that's really where Ruby excels greater than any other programming language that I had seen at the time and have seen sins that the kind of code that you write in Ruby just has a fluidity to it.
It is free of any excess symbols, excess. Noise that detracts from your understanding of what the program is actually trying to be. A lot of people will say when they look at Ruby, it looks like what we call pseudo code, the kind of code that is basically like just an English representation of what.
The software is supposed to do the individual instructions that you want this program to execute, and you write it in this pseudo code because you aren't ready to translate it into a real programming language yet. Well, Ruby basically took that concept and said, what if we just shipped the pseudo code?
What if the pseudo code could be executed directly by the computer that would allow the programmers to write in the most natural fluent way? That we can possibly come up with freedom from all these little things. So many programmer languages, for example, require that you put a semicolon. At the end of a line because that demarcates the separation of each instruction lines, and you can see why that makes things easier for a compiler or even a compiler writer.
Well, Ruby doesn't have that. Ruby says. We don't need the semicolons. Now, Ruby isn't the only language to ditch the semicolons, but it is an example of how we're just now gonna put noise in here in our programs. We want, in part beautiful software. We want a programming language where it's possible to write software like you would any form of beautiful prose, perhaps even poems, and.
I've now been programming in Ruby for almost 20 years, and I can tell you that is a long term joy. The joy I have opening up Ruby Code on a regular basis and looking at it and simply Mark remarking that like. This is just gorgeous code. Like this is not something I think most people would've said about most programming languages prior to the popularization of of Ruby and even Rails.
Now there were some, and there are multiple influences and factions in the software development industry and other peoples have worked on this problem. But Ruby really took it to the next level, and I could. Be more fortunate to continue to call that programming language home and where I get to spend my time making computers dance.
Julian: I love making computers dance. It's it's such a fascinating you know, thing in, in regards to taking an idea and building. You know, code and language and then interpreting it from a user perspective and having that whole relationship you know, start to create applications and things that we really enjoy using or are extremely valuable to us in our day-to-day lives.
Shifting to Basecamp and to, hey you know, when you're working on 37signals and you're working on these different projects, are you. You know, are you finding the problems in the world? Are they being presented to you? I always like to ask founders where they kind of, what inspired their ideas whether it was external or internal.
Did you build something that you thought people would use or did you see that people needed something, a tool or application, and then you started building it? What was the process behind basecamp and hey to really invest time and to be inspired by an idea to, you know, solve the problem?
David: Well, everything that we've built at 37signals since becoming a software company has been something we needed.
We did not look for an opening in the market or an angle or a hold that we could fill. We looked for our own needs and where we were really annoyed. Or frustrated with existing solutions or the lack of existing solutions. Basecamp originally came to be because 37signals was running as a design consultancy at the time, and we were dealing with clients as plenty of creative services firms do and realizing the same thing.
Millions of other creative services firms have realized is that most projects start on. , an email is wonderful when you're just a couple of people for perhaps a week, and as soon as you breach those boundaries that you either try to run a project for a longer period of time, or you try to run it with more people, you realize that email is where things fall through the cracks, where it's difficult to keep the scope of a whole project.
Cohesive. Have a single location that you can point someone at. If someone joins the project later, how do they catch up? How do they get an overview? How do you keep track of a project that might have multiple moving parts and might have dozens of outstanding to-dos or milestones or things we've agreed upon?
Lots of people. Try to solve that problem through email and so did we. And we just, like lots of other people eventually found that something was dropped. And it was bad and the didn't look good to the client, and we thought, you know what? We know how to build software. Couldn't we just build a tool where we could have everything in one place, where we could have all the messages and all the files, all the documents and all the to-dos and the schedule, everything just in one place so we could give the client.
One URL or someone new joining our company, just one U url, and they could find it all. And that was the impetus for base cam. In fact, when we started building it, we were explicitly just building it for ourselves. We didn't have even the concept of wanting to commercialize it. It wasn't until halfway through the process we'd shown what we'd made to some other people in the industry, and they were really excited wanting to buy it, that we were like, you know what?
There's something commercial viable here. We turned it into a product. Put it out in the market with relatively modest expectations and very quickly saw just a dramatic response from the market. And to our surprise, it wasn't just other creative services firms that were excited about Basecamp, it was everyone.
Because almost all types of companies have projects of some kind that they need to manage. And many of those companies are managing them quite. Using existing tools like email or in-person meetings or notebooks or whatever else they have. And and when that stops working and they realize, you know what, we need a system.
This can't go on. That's when they start looking for Basecamp And Hay was much the same. I mean, I've been writing emails since two. or since 93, 94, something like that. So I've been writing emails for, geez, almost 30 years and used a lot of different systems in the meantime, but particularly one system.
I've used Gmail since 2004, and when Gmail came out in 2004, I thought like, this is a revolution. What an. An awesome application. What a creation notion that I can have, like a gigabyte of storage. This is just a true revolution. And out of that revolution came a monopoly. A monopoly that cemented Google's weight on an email.
I think something like 80% of all email in the US go through Gmail now, something too preposterous and with that position as the dominant mono. Player also came a complete deep freeze on innovation Gmail. Didn't have to try anymore. They'd already won. Yeah. So we ended up with very little innovation on the core workflows of email for 10, 15 years, leaving both Jason and I ever more frustrated that the way we wanted emails to work weren't possible.
So, hey, it was something we started working on in, I think, when did we start working on, in like, 2018? And just outta sheer frustration that here is the piece of software that I spent the second most amount of my day in the first being base cam, the second bean gmail. And it's not great. It's basically been standing still for a decade.
And in a decade we've learned so much about how to build better software, learned so much more about how awesome email workflows can be. And we thought, you know what, now is the time we have been in business for long. We've worked off good enough skills, we have enough of a cushion we can take on a behemoth like Google and provide a proper alternative to Gmail.
But of course the difficulty with hey was that not only were we competing against a pretty good product, the product that hasn't basically evolved for over a decade, but still pretty good product that a lot of people didn't even know they had a problem. . So first we had to convince them that there were actually were better ways, and second, we had to convince them to pay.
Most people used Gmail for free. . So here we are coming along and saying, do you know what? There's a better solution. Let me convince you that. And then secondly, let me convince you that you have to pay $99 a year to use it, which was obviously quite the uphill battle to do. But we had this amazing launch in part because we got wrapped up into this nonsense battle with Apple over the right to even exist.
And we have tens of thousands of customers put down their credit card and pay for the product within a few weeks. Both of those products came out of trying to solve our needs first, and that's also what drove the whole product development. We always try to make B one laser focused on just solving our problems.
There will always be endless amount of time to listen to customers to get feedback, but if you can make that B one. Really tight, really focused on a couple of people's true needs. You know, you're not building something speculative, you know, you're building something that's actually worthwhile. And starting with a core base of really sharp takes, really sharp features, really novel things that no one perhaps would ask for is in my opinion, the more rewarding and productive ways to run product development.
Julian: Yeah. What was that go to market strategy? You said it was gonna be hard to convince people to, to pay for something that they've used for free for so long. I think that's the case for probably anything. If, but if there's enough of a compelling reason to do so, then of course people will adopt it and then, you know, you'll get kind of mass adoption there.
Yeah. What was the strategy to, to bring in customers and have so, so many people excited to use and pay for something that, that they hadn't had to pay for previously?
David: So the first thing that we've done over the past 20 years when we. Launched, Hey, was we've cultivated an audience during that whole time.
Not just a bunch of potential customers, but an audience. People who were interested and willing to listen to what we had to say, and perhaps enjoyed some of the ideas, some of the writing, some of the podcast appearances, some of the books, some of the other software that we've written who would give us the benefit of the doubt when we came yelling from.
mountaintop. We have something new. We have something novel because I mean, let's be fair, most marketers say that even when it isn't true. And then also just having the strength of a product that was really radically different in many ways. We were not trying to come up with like a different color scheme for Gmail now.
We were trying to fundamentally rethink how people use email in ways that. vastly beyond even coming up with a new client. Like in the time that Gmail has been a dominant email service, there's been a lot of. New clients come out for Gmail. We weren't interested in making a client. We wanted to make an email service.
This was not an add-on to Gmail. This was an alternative to Gmail. So I think, yeah, in part just the aspirations and the ambitions of taking something that ludicrous on. In itself helped sell the vision here, because I heard from lots of people, like, what do you mean? Like, but I'm not paying for Gmail.
Like almost, it seems so preposterous to launch a product like this that helped drive things on their own. But so of course did having a truly unique. Product. And this is one of the things, if you go to hey.com and just start going through, see how it works, you'll just see feature of the feature that looks nothing like what you get when you use Gmail.
And for some people they might first go like, oh yeah, that's nice. And then they'll see a thing that goes like, yes, that's the thing. I've been using Gmail for 10 years, but I'm so annoyed by this thing. Why does it work like that? You've solved it. For a lot of customers, all we need is one or two hooks, one or two true pain points that they might have.
Lived with for a long time. Not even verbalize that. It's something frustrating, but when they see a solution to that problem, they go like, bingo. That's the thing I didn't even know yesterday that I wanted. Now you've made it. Okay, take my money.
Julian: I love that. I love that. You know, between basecamp, between hay, between all the other, or building Ruby on rails and all the other endeavors that you're working on, what do you spend your days doing now?
What's the distribution your workflow? How much are you working on basecamp? How much are you working on Hay and o other projects? When it gets to this point, how do you really, one, stay motivated, but two continue to give everything the attention that it.
David: Yeah, so for the longest time as a company, we're quite a small company.
We would just focus on one thing at a time. We've had quite a few products over the years. Some of them we've discontinued and no longer sell, but continued to service and we would always rotate between them. And it'd be like, all right, now it's base cam's turn. We're gonna build some good stuff for base cam.
And then we're gonna let that sit for a bit and we're gonna go over and we. Work on something else for a while. These days we are slightly lighter or lighter, we're slightly larger. We're about 80 people at the company, which affords us the luxury compared to our history of working on multiple things at the same time.
So we have teams working both on Basecamp and on Hay, and we're working on even new product development as well simultaneously. And both Jason and I kind of jump between the things as they're needed. I still love to program. I still love to program on Basecamp. I still love to program on, Hey, I will frequently dive in and work on a project on my own.
I will also spend a lot of time reviewing work that's in flight whether that's code or that's. The product management. And then of course, Jason and I share together with our COO Elaine, the responsibilities, the executive responsibility for running the business, which within the employees there's always something something to do.
But we do approach that I think in quite. Different way than a lot of other founders or executives who are at an 80 plus person company perhaps would do in the sense that both Jason and I stay so tight and nitty gritty and fingers in the mold to. Work on the products themselves directly. . We also don't spend the majority of our times in meetings.
We've managed to configure this company in such a way that we can focus mostly on the things we enjoy the most, which for me is programming. It's writing. It's marketing, and it's operating the business. And for Jason it's designs that are programming and then the same aspects of it. So ending up.
With a company, you actually enjoy the day-to-day runnings of that. You don't just enjoy the extrinsic rewards of seeing it grow, reach high water marks in terms of revenue or customers, or even worse, chasing some exit. Whether that is to go public or sell. The company has given us this opportunity to have like a long run.
Satisfaction in just being in the business. That it doesn't have to be about striving for something new. Something next that living the day-to-day work of simply improving these products, dealing with these lovely customers that we have and making a nice place for employees to work is satisfaction enough in itself.
I think there is often way much of a focus. In entrepreneurial circles on what's the next thing. Like, we always have to get on from where we are and I understand that drive, and I have some of that too, and we're working on new product ideas and so forth, but I think it, we behoove us to balance that somewhat with.
like, could we also just enjoy where we are for a hot minute? Could we enjoy the state of the company right now, not just constantly be pining for it to be bigger or to be more valuable, or to do something new? Can we also just enjoy the things that we've built and the day-to-day that we're in?
That's the kind of company that Jason and I have tried to create such that we would exactly arrive at this day, 20 year, 20 plus years into it and go like, you know what? I still like to go to. . I don't, yeah. I don't need to constantly think of what's next. How do I get out of the current situation I'm in?
No. What the current situation has a lot going for it.
Julian: I love that. I, you know, that's something my Michael Funner and I kind of discussed a lot is, you know, how where to motivate ourselves and where to focus on what we're building so that we're not necessarily leading to anything that.
Aren't looking forward to, which is an exit or all these different outcomes or conclusions I would say to, you know, building. But you know, I think for me at least, I would love to hear your advice here is I find myself. , striving to create and fabricate a goal versus maybe focusing on something more, whether it's intrinsic or externally motivating, like customer, you know, and customer satisfaction.
What advice would you give a founder in your position? Not thinking about any conclusion, but really just wanting to focus on building, continuing to improve. Where do you kind of, I guess, set your own goals or expectations or or something else? You know, what advice would you give?
David: Yeah, I would say it's in that category of something else. I'm not a big fan of goals per se. Goals have a tendency to turn into a treadmill. So you reach this revenue goal, this customer goal, okay, fine. You feel good about that for what, five minutes and then you set a new goal, right? It's not like you're done by the time you reach your goal, versus you can decide how you show up with what virtues and what habits you engage.
The day-to-day of running the business because most of running the business is the day-to-day and having healthy. Motivating, sustaining habits and virtues to strive for. That to me, is something that is long term durable. For example, the way we built software at 37signals is in some people's eyes, perhaps obsessive that I worry as much about the quality of the construction.
That no customer would ever see. No customer is going to pick us over a competitor on the basis of whether I think our code is beautiful, but that's something that's tremendously important to me for my satisfaction. Long-term satisfaction of wanting to stay in the business is that we build beautiful software and I could.
Lots of rationalizations for why. I think that actually also is a good business strategy, even if you just evaluate it on pure financial metric, that we are still running on a long-term legacy code base that new developers at the company can adopt, take on and. Create new things for that is hugely valuable.
But it didn't come out of that. It didn't come out of a goal of like, oh I need to build it this way. Such the 10 years from now when I hire new developers, it's going to be inexpensive for them to get up to speed. No, we wrote it this way because I like to work on good stuff. I like to write excellent code.
I like to sweat the details, and that commitment to mastery is something that. Is very different from setting an explicit goal that can be met or not met. The commitment to mastery that we build great software, the kind of software that would be an joy for anyone in our industry to, to join and to work on that is a kind of of guiding.
That we can continue to strive for forever essentially, or certainly for decades. And the same thing of basically just treating customers, right? So one of the things, one of the principles we've helped at the company is that we will run our services until the end of the internet. If we lose.
I was about to say interest. That's not always the case if we stop wanting to sell a given product, and I mean, we've been in business for 20 years. We've sold a lot of different products over time, and some of them we've stopped selling because we just weren't going to develop, continue to develop them.
And they ended up in a state where we're like, you know what? I wouldn't be so proud to still sell this. We haven't worked on it for five, seven years. We're going to shut it off for new customers, but we're gonna continue to service existing customer. even on software products that we have. worked on beyond performance and security updates for a decade or more because that's what customers would want.
I love that notion that even something like a software company can have an allegiance to its own legacy. like a Porsche? Like a company? Yeah. Like any of these hallowed brands and companies who've created these incredible products from the sixties, from the seventies, from the eighties, that you can still get repaired.
You can still get serviced because they simply treat their legacy with respect. Now contrast that to a company like Google that seems to decommission and sunset every service they launch six to nine months after it goes into the air, or at least after someone started depending on it. And you can see the contrast that value produces compared to others in the market.
Julian: Yeah. What are some of the biggest risks that 37signals faces?
David: I mean, there's always the risk of competition. There's always the risk of the paradigm changing. There's always the risk that what we're selling will not be as relevant. I think maybe not so much yet in our business, but you look at obviously something like, well, everyone thought that Facebook was gonna be forever, and then suddenly TikTok comes around and you go, like, what?
That's a new paradigm. That's a different thing. It's not someone came up with a better Facebook. , it's that something came up, someone came up with something totally different and that, yeah, Facebook was no longer relevant. So I could possibly imagine that. I mean, it is really actually a joyous time for free imagination.
Particularly when it comes to the field of ai. It feels like we're just at the cusp of this major new revolution that many of us are having a great time trying. Predict where that is going to flow. But obviously we ultimately don't have an idea. Nobody knows exactly where this is gonna go, but that does seem like one of those things where like, do you know what?
Maybe you end up somehow in a place where you don't send your own emails, for example. You just dictate to your AI. Agent that like, Hey, could you write a post to this and this person and make it be about this? You never actually see the individual email. I don't know. I mean, this is just free form association here.
Yeah. But ending up in that situation where like the whole product space that we're in is no longer relevant because I mean, to be honest, I don't fear so much the direct competition. That's not to say that. Take market share, they can't appeal to other people. I'm sure they can, but I have enough faith in our ability to create something great within that existing paradigm.
But the paradigm shifts, they don't come that often, but when they do, they usually leave you flatfooted. Whether you're Blackberry at the advent of the iPhone or maybe you're Google at the advent of the personal AI that can answer all your questions. It's yeah, it's those kind of things, those kind of black swans that.
I most worry about because do you know what the smaller stuff the things that kill most businesses, just like, like stunting your own execution is something I feel like after 20 years I have a fair amount of faith that we could keep going along the same trajectory for another 20 years.
So it's really only if that trajectory is heading to the wrong place that, that I fear the risks of the company.
Julian: I always like to ask this question to founders. One for selfish research, but also for the audience as well. You mentioned mastery, and I know there's certain books with that kind of are in line with that philosophy of what is mastery creating mastery.
But outside of that, you know, whether it was early on in your career or now what books or people have influenced you the most?
David: Oh, that's a good question. If you Googled the five books dh h, you'll find the ones that have meant the most to me for programming. But I would actually say that the ones that have meant the most for me as a person have probably been books and stoic philosophy.
Everything from Marcus Aurelius, the meditations to life is long enough as Seneca and particularly Epictetus. Espresso version of stoicism called the manual. A very short book you can read in 45 minutes is one I recommend to almost anyone. It's certainly a way of thinking, a way of approaching life that has meant a tremendous deal to me.
So in terms of shaping how I see the world and how I try to show up in the world, I would say the book from the Stoic mashes is the ones I would recommend.
Julian: Amazing. And I know there's so much we could have filled into this episode, and I know we're a little over time, but honestly, I could we could go down so many rabbit holes. But I guess last quick question is there anything I didn't ask you that I should have?
David: No, I thought this was a great conversation. I mean, many of the topics that we've talked about is something I've been writing about extensively. I've published four books on how to create a software business in particular, but really could be applied to many different kinds of businesses and all of my work, all of my writing, all my products and involvements.
You can find those at dhh.dk
Julian: I think. Well, David, it was incredible chatting with you and I know we didn't get into the race car stuff, but people can find it on your bio. And it was so exciting to learn about not only your journey, but how you philosophically view building companies. Personally, you know, I think it kind of reinvigorated some inspiration for me and I hope it does for my audience.
So I hope you enjoyed yourself and thank you again for being on the show.
David: Thanks for having me this is great.