Ep. #11, Mastery and Purpose with David Heinemeier Hansson

Patrick Woods: David, thank you so much for coming on Developer Love today.

Really excited to have this conversation.

And I guess today let's kick it off with a question that I ask every guest on my podcast and I'd love to get your perspective on it.

And that question is what would you say is the secret to building things developers love?

David Heinemeier Hansson: Oh, wow.

I think that is a nice broad question you could take from a million different angles, but I will just take it from the selfish angle, which is that I'm a developer.

So the way I try to build things developers love is to build things that I love.

And that has been my driving barometer really for all things that I've built for developers over the past 20 years is to build for myself first.

And then to guess that I'm not the only person who feels like this.

And that there will be other people who like me are inspired by the same things or get annoyed by the same things as often us, so focusing on my own experience rather than try to guess what it is that developers might like.

I always find that a use of focus group approach to development, whether it's products or things for developers to be very difficult.

I wouldn't want to build stuff like that. I don't really know how to build stuff like that.

The only way I know how to build things well is to build things that I like and then hope that there is others like me.

Patrick: Yeah, that makes sense. If you had to abstract that out to two or three elements of the things that you really love and appreciate, what would you say those key elements might be?

David: As it comes to developers and developing, I've been working with Ruby for almost 20 years now.

And one of the things I've learned about myself working with Ruby is just what a satisfaction I take out from the aesthetic element of development, of programming in particular that I like to build beautiful things, beautiful code.

And I will treat that as a more important characteristic of whatever I'm building than many other things that people reasonably could choose to put first, like how fast something is or any of these other sort of barometers when people think about with programming.

Or for example, how it can be automated or how you can build tooling around it.

I tried to look at the fundamentals of what I'm working with.

I like to work directly with it, and I want to have it beautiful.

And that's one of the reasons why I've stuck with Ruby for almost 20 years now.

And I continue to be inspired by that program language.

And just simply thankful that I continue to be able to express myself as a programmer in a language that has such a respect for the aesthetic approach to programming.

Patrick: Yeah, so it's great to hear you say that. Orbit, our company, is a Rails shop.

We made the decision a year ago to build on top of Ruby on Rails.

I'm interested in your perspective as how would you recommend developers think about the choice to use Rails in 2020, and how have you seen that decision maybe change over the past couple of decades?

David: Yeah, I think it's one of those things where one of the reasons why a lot of people are attracted to technology in the first place is the sense that there's always something new, and there is.

There's always something new, and we have a new JavaScript framework every other week, and we have a bunch of new techniques every other week.

So it's very difficult for something that's been around for a long time to continue to have kind of that peak appeal it had when it first appeared.

And I know I have the perspective of time to have seen that entire trajectory as it comes with Ruby on Rails.

The Ruby on Rails that we have today is by far and away the best version of Ruby on Rails that we've ever had.

It is more polished, it is faster, it is better, it's more capable, it's all the good things you could see, compared to when it was first launched back in 2004.

Yet, it doesn't necessarily command the same mind share as it did in say 2007 where it was the hot new thing.

And now as has been the case for the last several years, JavaScript and the many frameworks there have a great amount of mind share and lots of people are attracted by what is most popular. It's a fair question.

There are benefits to operating in a popular development ecosystem. There might be more libraries available. There might be more jobs available, but reducing programming and programming ecosystems to purely a popularity contest, I think, is a very sort of poverished view of what it is because the fact is that if you find a language or a community or an ecosystem that really that clicks for you, that's a superpower. That's something that where you can just rocket past who you might have been in something that didn't really do that for you. That's exactly what happened to me when I discovered Ruby, that was the infliction point of my career.

And not just in terms of outward success, but in terms of my own evaluation of myself as a programmer, the journey that I was on, and the speed with which I was able to learn and improve.

The trajectory took a hard step up once I found Ruby because it just simply clicked with me.

It fit the way my brain wanted to think about programming.

And this is something that is often lost when we come into these tribal debates about what is the better programming language, what's the better ecosystem.

And we start trotting out these logical algorithms, "Oh there's so much so many downloads or there's so much so many libraries" or whatever.

When really the key determining factor as to whether an individual is going to be productive or even happy working in that environment is a far more personal truth.

And a far more personal relationship with that system, with that programming language as it where, or even with that framework, and that there's not nearly enough focus in that we, as a programmer, we're trying to take this rational objective view and you can get into arguments about like, "Oh we should have static typing."

"Oh no, no, we should have dynamic typing." When in reality, it's far more about whether you as a person respond better to static or dynamic typing.

I take that as an example because it's been an evergreen discussion for the past 40 years of programming and that there are proponents on either side.

We're so convinced that if they just shaped their arguments slightly different, the other side will see the folly of their ways and they will be persuaded.

When that is, it's simply not true. I have been around programming for long enough.

I've been exposed to enough programs that I know that static typing it can, just to take one example, It's not the thing that's going to do it for me.

Simply because of what I'd like and the aesthetic approach that I have to programming and the love with which I have for Ruby.

Do you know what? I don't really care. It doesn't mean that I'm ignorant of the trade offs.

It simply means that my personal truths have been rendered in such a way that I've come to the conclusion that for me, dynamic typing and Ruby's whole approach to it is the one that in a sense works for me.

Now, I'll caveat that by saying that very quickly gets into the, oh, your mileage may vary.

We can't have any discussions about what's better or good even because everything is relative, and you should just check out everything on your own, which I also don't see is actually very helpful because there are people who don't know yet.

They're undecided about what works for them.

And they take their bearings in large part by the arguments the proponents that come from each camp.

So I continued to be engaged in a campaign of illumination for the lovely attributes of the Ruby language and the Rails framework, simply to illuminate others to the choices that they have.

You paint the paths that are possible. And then someone will sample the different paths, and they will eventually find one that really fits for them.

And then there are a number of people too, who are blessed with, blessed or cursed with the ability to take any path and not really care.

I'm certainly not one of these people, but respect that there should be such individuals.

And then there's a bunch of other people who are simply are looking for path.

And eventually are presented with sort of a compelling view of like, hey, this is an illumination of this path.

This really works for me. This is really the right answer for me.

And then they end up in a situation where they are far more happy in their daily lives with what they do, if that's programming.

Patrick: To zoom out just a little bit, I'm curious, who do you feel is treating developers well these days?

And what do you think they're doing that demonstrates that developer awareness?

David: I'm not even sure. I like that framing because one of the notions of being a developer that I've embraced is that I'm not just a consumer.

I'm not buying something that someone else is selling.

And then I feel like, oh, if that's not working well enough, then I should go back and get a return for it or I should get my money back.

In fact, I view sort of the whole development experience.

And of course, maybe that's just me because I've been so involved with open source, but as one of shared responsibility, and it is your own responsibility as a developer to get on the path when you're helping to shape your own destiny.

And this was perhaps the biggest shift that we got once we escaped the costs of proprietary development tools and got into open source development, that we were gifted the potential to help shape our own tools, that we were no longer relegated simply to be consumers.

And that all we do is we can complain about the choices that weren't no, we could absolutely just get involved and help make better things.

And when we did, generally speaking, ascended to a higher level of being as a developer.

If you have the power, and if you realize that you have the power to help shape and create your own tools, I think you just end up in a very different place than if you're a passive consumer and simply the best you can do is what, rate the things that come up.

Oh, that's a 4.2, that's a 4.6. And do you know what? I find that uninteresting.

I am far more interested in being a creator, a co-creator at least, than I am in being a consumer.

Patrick: Yeah, it seems like you've talked previously about open source almost as a path to self-actualization for developers in general.

And you specifically interested, if you would say more about the role of open source and one's path towards enlightenment, not to put a too dramatic point on it.

David: I think it is. I think open source is a path to freedom in a way that developers just didn't have in the proprietary world.

When you were simply there to sit as a consumer of what someone else may for you, you ended up in a completely different psychological state of mind.

And as I said, not a big fan of that state of mind when it comes to development I'm a huge fan of co-creation.

And that co-creation isn't necessarily always that like I'm going to write all the code that I possibly touch because no one has the time to get involved in every single project that they might use, but that we have the power to do so, it's just a mind shift change.

And of course that we have to exercise that power in some capacities in some ways to really believe that it's true.

It also changes the dynamic about reciprocity. If we feel ourselves as consumers as though we're buying something from a corporation.

We have some entitlements and expectations to the way the software should work and what the people who are making that software should do for us, that they should be responsive to our proclamations and fix things for us, which ends up in a really unfortunate pissy place, really, for a lot of programmers, that they're mad at people who make things for them for free because they're stuck in this consumer mindset.

And that just renders them sort of impoverished in their own approach to life.

They ended up walking around often feeling pissed off, that other people didn't make something better for them, rather than realize their own capacity to help change that.

So I think the other thing here too, is open source opens the door for us to, ironically enough, given the fact that so much open source is used to build commercial systems, but escape capitalism in its most elemental form of the exchange of goods and services for money or time in a transactional way--

That open source shows us that there are ways of human collaboration that are not defined by market terms.

And we keep walking on this edge, and we clearly have not figured it all out yet and not have all the answers or the right ones for all people.

But that has been one of the reasons I've enjoyed open source so much because this is this realm set aside.

No one can buy my time when it comes to open source, right?

No one can force me to be responsive in certain ways just by virtue of economic incentives.

This is a transcendence of that.

And I involved myself in open source for the self-actualization that is the expression of my own capacity as a programmer and the absolute human joy it is to be with and work with other people outside of this transactional framing that that's so much of our lives is otherwise stuck in.

Patrick: We talk a lot about this concept of open source, the open source community.

Do you think there is the sort of idea of the open source community or how have you experienced community as it relates to your open source dealings?

David: That's a great point.

I think that actually is what leads to a lot of misunderstanding is that we think that this is a monolithic ideology that can really drive all the major questions and providing answers to those things.

When it's really not, there are so many different kinds of open source approaches and values and oftentimes they are in opposition to each other.

I gave a keynote at RailsConf 2019 contrasting the kind of free software movement.

And it's focused on extracting contributions out of this scarcity framing where like, Oh if someone is using my GPL software they must give me back any extensions and modifications that they make to that software.

That's undeniably one branch of open source and it is completely positioned to my own personal attraction, to my branch of open-source which is far more based on kind of this abundance principle that is present in the MIT license which essentially says you can do whatever you want just A, don't sue me and who think that I accept any consequences of your use, but like, hey take it, do whatever you want, go on and be free.

I'm gifting this to you without any expectation of getting something back neither in an economic sense, nor in a code sense.

If you choose on your own volition to want to collaborate with me.

Wonderful, I'd love to have it. I'm not going to force you to collaborate with me.

That is just an extractive view that in my mind shares more with the capitalist transactional framing than it does with my personal understanding of open source, which is this beyond market understanding where we're not just trading things back and forth or forcing each other to do things because a license says so.

Patrick: So you you've referenced Erich Fromm's, "To have or to Be" frequently, I think as sort of a seemingly a foundational text for you personally.

I'm curious, have you recognized any overlap or sort of practical application of Fromms'concepts to your work as an open source contributor?

David: Yes, Fromm has been one of the most influential writers in my understanding of myself and my place in the world that I've read in the last 10 years.

Huge fan of "To have and To be." And I think it ties very well to the discussion we were just having about this scarcity versus abundance approach.

This idea of whether I can extract things from others or whether I'm trying to build myself, the to be part in Fromms', "To have and to be."

It's all about developing my own personal character and doing so in, I don't want to say internal way because you're doing that in collaboration with other people but not as sort of a struggle with others.

You are working on yourself, which is one of the reasons I enjoy open source software so much.

It's a way for me to work on myself both as a programmer as to become a better program to practice programming, to express programs, even for the love of expressing, that's another key factor of "To Have and To be," this understanding of human nature is one that is most content when we express our capacities as humans.

When we do, when we create, rather than when we have and when we gather and when we hoard, which is to have orientation. And I see that in so many ways, if you take the transactional commercial capitalist framing as we just talked about today, it's all about accumulation in its traditional understanding.

And then as I said, I also see the GPL and the extraction of contributions in much the same way that like, there is a fixed number of contributions in the world and I need to gather them all because otherwise it's unfair.

If someone is taking advantage of me, there's a much greater satisfaction in my mind and experience from a detachment from that.

Yeah, this is code that I wrote the primary satisfaction that I got was the pleasure of writing it.

The satisfaction is not coming from like what I can get out of it, in which way it can be an asset to either accumulate more assets or to grant me access to something else.

No, the pleasure was simply in writing it the pleasure was the journey, not the destination, even if I can also take pleasure in sitting in the meadows of my destination here and viewing the wonders of what we built and did Ruby on Rails community for the past 20 years.

That's great. But the lasting enduring satisfaction comes from the fact that I was part of that journey and I continue to be part of it the journey that this is not a time-boxed satisfaction.

This is not like, oh, I will be happy once we get to X.

No, I will be happy once I get to continue to contribute.

Once I get to continue to be part of, once I get to continue to learn and no one can really take that away me that goes to the point we had about popularity.

That there are people who measure, they're like, where should I focus my energies?

And should I be in the popular place, okay. Yeah, I don't really care that much.

Again, maybe this is because when I showed up to build Ruby on Rails, the number of uses there were was one, me, sort of inherent in creating something new that I've not had this need or you could frame it differently and say I had the privilege of starting from scratch and not worrying about popularity as a main metric or deciding factor in choosing where to go.

No, I go always like who I want to be.

And part of that is what I want to work with and how our respond to those things and I can make the best choice as he sees fit for me and my character.

Patrick: So thinking along those lines, I'm interested zooming up from your personal contribution up to sort of your role as a manager and a boss and a leader. I'm curious, what are some of the ways that you helped make Basecamp a place that's built more on this mode of being versus having?

David: Yes, it is one of the things I continue to struggle with. I don't actually, you said the word boss.

I don't like being someone's boss because I think it is an inherent conflict with this sense of personal responsibility for your own growth and so forth.

So I try to work with people at Basecamp in this so far as I have a say in that, of people who are intrinsically motivated by the work that they do.

And in addition to that who are comfortable either being or working towards becoming a manager of one.

Someone who could be responsible for their own direction.

Now, again, that doesn't mean that you have to be, sort of this lone personnel in your own little Island and you don't do anything in relation to others, not at all but just that you have the center of your satisfaction with work within the joy of doing the work.

And then we build on top of that and say like, hey, we enjoy programming and we enjoy getting better programming.

We enjoy extracting the lessons that we learned during our programming adventures. We can share it with others and so forth.

And like, hey, while we are doing all that stuff let's walk in this direction together. Let's work on this product.

But within that, you take responsibility for your own contributions and learnings and quality bar.

And I will feel most at ease in my role as a co-owner of this company if that's just the thing that you do and I can go like, oh, that's awesome.

And we can have fewer discussions about me telling you, quote, unquote, what to do.

I hate absolutely loath being told what to do to the point that I have a difficult time telling others what to do.

And I think that's a feature, not a bug.

And rather than telling other people what to do at least the majority of the time you inspire them to walk into the same direction issue.

And then you are hopefully illicitly surprised when along the road, they come up with their own ideas and approaches and so forth.

This is one of the reasons why in our development methodology which we call shape up at Basecamp, which we published it's free for anyone to download at Basecamp.com/shapeup.

We have such a focus on drawing out projects in a very highly level, sketchy, thick marker sort of way in such a way that we're not detailing all the individual decisions that are to be made by practitioners as they're implementing this thing.

Because we want that creativity that's sparked by the people actually doing the work rather than just being told exactly what to do and which way to go.

That's the kind of work that I enjoy, Jason enjoys as a partner in the business, as a designer that should be the privilege we extend to the people who we get to work with that they get to have a material impact on, they're doing the work.

The closer you are to the work, the more informed you are the better you are in many cases at making the detailed decisions about how that works should manifest itself.

And it's also just more fun to work that way. It's more motivating.

If you look at Daniel Pink's "Drive 2.0," or something, the three factors of motivation is mastery, autonomy and purpose.

And that part, the autonomy part is really important for developing the first part mastery as well.

If someone else just comes in and say, hey here's what you need to do.

You need to do these exact 10 steps in this order. You know what?

There's not that much potential for you to develop your own master.

You have to get the opportunity to have some freedom to express yourself within some course constraints and boundaries, of course.

So just that we're walking in roughly the same direction but that you're making the detailed decisions.

And that's another value that I see expressed in Rails.

And I've tried to express in rails, this idea that I'm not going to tell you what to do. I'm going to nudge.

I'm going to illuminate some paths but ultimately you are in charge.

Ruby itself is a programming language that embraces a value like that.

That's like, you know what? If you want to do some wild things that generally would not be the sound thing to do that would be prohibited.

If you were working in a more constrained or locked down program language like my old nemesis Java, that's on you.

That we cannot expect someone to develop their mastery.

If they can't test the boundaries, if they can't sometimes fall off the rails and hurt themselves.

You have to, in my opinion, allow people to do things that aren't as well advised for them to realize why that advice is the way it is in the first place, allow them to make mistakes.

Don't try to protect themselves too much from mistakes because mistakes is one of the key ways that you learn.

And then also this idea that there's this omnipotent framework or language designer who can have foreseen all possible permutations of reasonable use is of course a complete fall.

And oftentimes we, as language or framework designers learn a lot more about what's actually reasonable or not by programmers doing things that we thought perhaps they shouldn't have done or that isn't part of the official guidebook.

And that is the kind of creativity that I'm inspired by. And I want to courage and I want to see more off.

And I think that that unleashing that by having nudges and guidelines rather than rules and restrictions is a wonderful way to go.

Patrick: Yeah, it seems like this notion of personal agency is pretty strongly woven throughout your worldview.

I'm curious, how do you think that either companies or open source maintainers slash communities, how can those people create an environment where people aren't afraid to fail?

David: One way to do it is to lower the risks of failure.

What's at stake, if you're afraid of failing because you fear the consequences of that failing.

Yeah, you can be afraid of failing. If the consequences of a failure are lower. They're either caught sooner.

So it's that they don't have as large of an impact or it's just not that big of a deal.

You know what the price of expectation. So at a company, for example, one of the things that we do is we do a lot of code reviews.

So if someone is trying something new and novel they'll at least have another couple of sets of eyes to look that over and see whether that's a good idea and they can then do so and launch something and come up with a new approach to whatever it is that they're working on because they can have some reassurance that they're not just off on their wild self.

Not everyone has the personal conviction to believe that they're right.

Most of the times do things and maybe that's both my blessing and curse that I have that but lots of people that they need some, crave some even validation that whatever they were trying to do, it's actually okay it's something we can do before they launch it.

So you can give that through something like code reviews and when it comes to the open source community I think the most powerful pattern that get, in general has encouraged the idea of the fork that you can just take an existing piece of software and then you can fork it.

And then you can do whatever crazy idea you have in mind, building on top of what's already there.

And you know what? If it doesn't work okay, fine. Just fold then. Go back to the main trunk.

You don't have to persist this fork to all eternity.

And if the fork and the experiment turns out well you get to upstream it or I guess propose to upstream it.

It also goes to a sense of freedom in the core framework of language.

One of the key things I've enjoyed so much about Ruby over the past 20 years is it's humility in allowing others than the language designer to amend and extend the language directly in such a way that the native or internal features are not more convenient or even prettier than the extensions that can be made by someone else.

Ruby has open classes.

You can add whatever you want to string or to number or any other base class.

And people who have a certain mental persuasion or worldview look at that in horror and go like what?

That just means anyone could open string and offer writing with whatever nonsense, this is going to be chaos.

Which is funny if you look at the original objections to open stores they were much the same.

What, if anyone could contribute anything we're going to have chaos.

If you looked at the Britannica objections to Wikipedia, they were much to say more.

If anyone can edit an encyclopedia we're just going to have bullshit and nonsense.

And in every single one of these three cases, it was proven.

And perhaps because it wasn't at least for a certain mindset, intuitive that this could work.

But now we have the imperial data that shows that it does.

Chaos did not ensue in Ruby land because you could open and extend base classes. Surely there were individuals who occasionally make mistakes and overridden, but by and large, it did not create a world of chaos. That requires a real serious faith in humanity, a faith that was not present when you look at these other programs.

Like you say, you can't just extend the core classes in Java that's another thing you got to make your own thing.

If we're going to make sure that these things are separated and then like there's the official line and the official classes.

And then we don't get them polluted and tainted by whatever experiments, the common programmer in their lack of wisdom will shove in there.

When Ruby simply went in a far more egalitarian, we said, do you know what?

I don't necessarily have all the best ideas is do you have some ideas, try them out.

And if we liked them, we can build them into language.

And that's what ended up being active support which is essentially the dialect of Ruby that I started as a way of tailoring the Ruby programming language is specially for the creation of web applications with Rails.

And that since hundreds if not thousands of people have contributed to where we've extended base classes in all sorts of directions this is how we get 5.days.

Plus I forget whether we actually have this if this is still just a figment of my imagination 1.fortnight, and then you get 19 days out of that.

It allows a fluidity of expression which is exactly what dialects and capillaries that are extended will provide.

And that is a rich source of satisfaction for someone who's interested in programming from the, if not literary, then writing aspects of it.

I've never thought of myself as a programmer in the science or mathematical sense.

I know plenty of programs are, and I'm very thankful for their contributions to computer science.

I will never be the person who contributes a major new sorting algorithm or any sort of core computer science progress in that regard.

But then there's room for other expressions of quote unquote, computer science.

Let's not even call it computer science, just programming.

Programmers who like the writing aspect of it, coming up with the right words and the right constructs and concepts and labeling those and creating a cohesive systems of logic within that.

That's the kind of stuff that I enjoy. And that enjoyment is just enriched so much when I work in a environment like Ruby, that allows me to do that on an even setting with the language designer.

Patrick: So you said before that a lot of times you don't need a laser focus, you need a broad perspective and I'm curious, how do you apply that heuristic?

How do you know when to apply which?

David: So the broad perspective for me when it comes to developing software is usually the notion of the whole system.

What does it take to understand the whole system?

Because I tried to understand the whole system of any system that I've built.

And that ambition, the idea that someone can understand the whole system is at odds with many of the software development approaches that are popular or at least popping up such as micro services or other ways of dividing and breaking down your application into small chunks.

And then essentially thinking, I don't need to understand this. This is just something I need to work with.

I like to understand the whole broad perspective.

So the whole system, the integrated system this is why I've been a champion of what I've called the majestic monolith for so many years this ideas that there is a tremendous amount of simplifying value when you have the entire system in one application and you build it in such a way that individuals can understand the whole thing.

Now I know that that approach has boundaries.

There are some applications at certain scales that do become too large and no individual can understand them anymore.

I am mortified with such systems, generally speaking but I understand their necessity in certain ways but I don't find that it's sort of imperative that all applications have to arrive at that place.

I'd actually say that that is the far exception.

And then most software that ends up being partitioned into smaller bits and pieces encountered that faith because they were poorly written.

And because the approach to writing them, didn't focus on could we write what we have better?

There's almost, perhaps sounds ironic coming from me but there's almost an arrogance in it, right?

Like this application is just the size that it is. It's an immutable force.

And it just happens to be let's say 100,000 lines of code.

That's just what it is. We can't do it any other way.

So all we can do now is carve up those 100,000 lines and perhaps five applications of 20,000 lines each when the reality is those hundred thousand lines could probably most likely be expressed in an application that was only 30,000 lines of code if you introduced better abstractions and simply run it better.

It's funny to me that the so many programs seem to take it just for granted that like systems decides that they are and there's not that much you can do about it or it almost feels impossible to think that you could do something about it when we have an immense power in the rewrite, in the edit in the refactory that we can extract better abstractions.

And those extractions can have a simplifying effect that entire system, both in terms of the lines of code but also in terms of its sort of conceptual cohesiveness.

And that's the part I'm interested in, that is how can we become better software writers?

How can we use those increased skills to write better majestical monoliths to shrink the applications that do the same things in fewer lines of code with stronger integrity in their contextual modeling, rather than like how can we take the shit we already have and shove it into a bunch of different drawers.

Patrick: I think you've used the term merchants of complexity before to describe some of this phenomenon.

David: Yes, that's the sort of more cynical view on it that there is a whole industry of people who benefit when things are difficult.

That the harder something is, the more likely it is to require consultants.

The more likely it is to require books and conferences and certifications and all these other things.

There's a lot of economic disincentives from a lot of technologists to not make things easier.

Now, of course no one self-respecting will admit this to themselves.

Like no one goes like, well I just make things hard to use such that people will pay me to learn how to use it.

That's not a thing that anyone says, but I think that that is the consequence of certain incentives.

It's almost like Upton Sinclair saying that, "a man can understand what his paycheck depends upon him not understanding."

That this is one of those reasons why I've rejected commercialization of the core development Rails for so long.

That we haven't incorporated Rails in.

There's no blessed consultants or consultancy around it in contrast to how a lot of other open source projects work.

Like where there is an corporation around it and that incorporation which really nurtures itself on consulting revenues.

And then there's almost a conflict when you make the software simpler and easier to understand perhaps there's lesser need for someone to drop a support or consulting contract and I think that there's just some inherent incentive conflicts in that.

And that's where the merchants of complexity idea comes in.

It's not necessarily out of malice although I would not be, I wouldn't even track that all.

Way back, if you look at what's going on with Oracle and Java you think like, eh, there's probably some willful merchants of complexity there who are willfully making things difficult for developers such that certain licensing scheme set up.

Patrick: So one theme of today's conversation I would say is your perception of power and lighting the way and sort of guiding people towards an outcome and not necessarily trying to go to them and extract value.

We've talked about that in a number of domains it seems but I'm curious in your perspective as a co-owner of Basecamp, and as you think about your go to market and your brand how did those conceptions influenced the way you all sort of operate the go to market of the business?

If that makes sense.

David: Yes, it certainly does and there is certainly an echo of how I approach open source and how I approach commercial software.

And part of that echo is, again this story about popularity, right?

Like, what is your goal? Why are you making and selling software? Is it to be the most dominant player in your industry or in your market, or is it to make great software at a fair price that people will enjoy using?

It's putting a little bit of an edge. Most people would say, "Yeah, I want to make great software at a great price that people like too."

But then they will also say "I want to capture as many customers as possible. I want to dominate my industry and I want to crush my competitors."

And those last three statements are not something that I think I want to be a part of. And thankfully we haven't had to.

One of the reasons we haven't had to at Basecamp is because we have the privilege. The enormous privilege of saying "enough."

We have enough, this is good.

Can we just stay here and to build a company of about 60 people who are happy, where they are, we're not on a constant chase to be on a trip of exponential growth.

So when you're not on that and you build software in a different way you approach your customers in a different way.

You treat your employees in a different way.

When long-term sustainability and calmness is key to the organizational values, then you make different decisions.

And I think those decisions are reflected well in that discussion we just had about scarcity versus abundance here.

I don't care how big the market is for say email services.

I don't need everyone in the world to use our new email service, Hey.

If we get enough that is just sustainable then we can continue to improve it and make our business better and pay our employees well, then that's good enough.

And that is such a release in many ways that you don't have to constantly compare yourself and be like, look, how many users that Gmail has or whatever the dominant 500 pound monopolist in your industry can brag about.

I'm just going, do you know what? I'm happy that I'm building a great system, founded on some ethical values that I hold dear.

And then that the market has some response to that.

And if that response is 0.1% or 0.01% of the market, fine, whatever, who cares, I'm not even counted

Patrick: We lot at Orbit about sort of the culture of the tooling of so many commercial organizations is extractive and about capturing value versus creating value.

And it sort of comes back to this notion of scarcity versus abundance that has been, so, I think thematic of our conversation today.

David: I really thinking is one of those main lenses to look at the world that help explain a lot of how things are but also a lot of how people are like whether they approach life majorily from a scarcity perspective or from a an abundance perspective.

And of course, it isn't just a strict dichotomy.

And sometimes you do need to have some eye to the scarcity of things and then other times not so much, at least identifying those different frames.

And when they apply. I think it's a material level up that you can do as a person and as a business.

And I think that also that sort of frees you from some of the traditional framings that are put upon companies and individuals about what they're supposed to do.

Who an entrepreneur is, what is a successful startup. You can start questioning those types from a much more informed perspective. I think once you look at it from these angles. and then it allows you to opt out of a mainstream understanding of what's a successful startup, for example.

Basecamp has repeatedly from the scarcity side of, "hey, let's just all try and make unicorns all the time"

We've been criticized for the fact that we were a failure. "ike we used to sell a chat program called Campfire.

And someone goes like, " that could have been Slack. You guys are just too lazy. Now you've missed out on billions or whatever."

And they legitimately think of like, Oh, that's a really deep cutting insult.

Because surely these people at Basecamp must also have just such a sense of regret for the fact that they didn't end up being a billion dollar public company.

And that's the frame that this insult is lobbied from when you just go, like I feel bad for you that this is the way you view world that the only people who you can qualify as successful are this small, tiny handful of company owners who end up doing billion dollar IPO's.

Then we can have what, 20 successful people in the world? Jesus talk about scarcity mindset.

When I look at it and think like I wouldn't trade my business for one of those billion dollar companies.

I wouldn't trade my business for neither Slack nor Uber nor Facebook, nor any of these other companies.

Some of them on ethical grounds. Some of them on just size grounds.

Some of them just in the ground, of do you know what I like running a company of 60 people.

It allows me to do my favorite things. A lot of the time such as programming, such as writing.

And I would have less opportunity to do some of my favorite things, if I ran a much larger company and I would have to do much more of the things that I don't consider my favorite things at all.

So just financial projections or talking to investors or whatever other bullshit that most CEOs fill up their day with.

Patrick: It seems like a good place to wrap it up here. I'd love to keep going.

I know it's late there, but I feel like we've covered a lot of really interesting territory today.

Is there any other areas or any other points that you'd like to mention or bring up?

David: No, this is great. This is a good, a tour de force around a lot of the topics that I care about for a couple of decades.

Patrick: Yeah, yeah. I interviewed Tim O'Reilly a few weeks ago and I'm not comparing you in any way, other than the sort of polished and succinctness around your worldview.

That's been really fun to hear.

What I've appreciated about your perspective is that it's incredibly consistent from the way you handle or you manage yourself to your code base to your company.

So kudos to you for that. That's really rare to see and something I hope you can be proud of.

David, thanks so much today for this conversation.

We've covered a lot of ground, gone deep on some pretty interesting topics and really appreciate the generosity of your time.

You have a lot of intellectual footprint out there from Basecamp to your books, to your Twitter feed.

If people wanted to learn more about what you're up to where would you send them to find more?

David: If they want to get maddened about some of my tastes that they invariably will not agree with they should totally check out Twitter.

But if you don't want to have that experience then I actually would recommend my latest book that I wrote with Jason. "It Doesn't Have to be Crazy at Work."

It touches upon a lot of the themes that we've been talking about here as it relates to running a commercial business and this whole idea of goals and abundance and so forth.

So that's a great place to start. It's not too long, about three hour read.

And then the other thing to perhaps check out is some of the keynotes I've given that RailsConf over the years.

We talk about one of the keynotes about GPL and the definitions of open source. If you search DHH RailsConf 2019, you'll find that.

And you can also just leave out the 2019 and you'll find a bunch of other keynotes I've given at RailsConf that touch on some of these topics.

Patrick: Thanks again, David, and keep up the great work.

David: Thanks so much for having me. This was great.