· 24:50
Hey, welcome to Product People. My name is Justin Jackson and it's time for part two of my interview with David Hanemeyer Hansen of thirty seven signals. In our last episode, we talked about how David started working as a contractor for thirty seven signals making only $15 an hour. But he eventually worked his way up and became an owner in the company along with Jason Fried. In this episode, we talk about how he and Jason work together on a daily basis and we go behind the scenes on their decision to rebuild Basecamp.
Speaker 1:We also talk about how he got into driving race cars a mere two years after he got his license. Stay tuned for that and more coming up. Before we get going with the show, let me tell you about a few of my favorite sponsors. Are you creating an application that needs a chart or dashboard? Fusion Charts is a JavaScript charting solution trusted by over 450,000 developers around the world.
Speaker 1:They have tons of interactive and animated charts with advanced features like tool tips, drill downs, chart export, and zoom. Their charts also work across PCs, Macs, iPads, iPhones, and Android devices. You can download a free trial at fusioncharts.com. And Sprintly is perfect software for teams of three or more people. It's the easiest way for managers and developers to track the software development process.
Speaker 1:You and your team can try Sprintly for free. Go to www.sprint.ly. Once you sign up for a billing plan, use my coupon code product people TV 2,013 to get 10% off. You know when I talked to Jason I asked him this question about how he knew that he could trust you. And so I'm going to ask you the same thing because you're a fairly like if anyone meets you and just even hearing about your past and starting all this, you know, these magazines and stuff, you're a fairly independent person.
Speaker 1:What what made you feel like you could trust Jason and that you even wanted to partner up with him? Like, why bother partnering up?
Speaker 2:Well, two things. So first of all, I knew that Third Super Singles had a history. By the time that I got involved with Jason, I mean, the company already had two years under its belt. It had a repertoire of launched sites that they had done for clients. I knew there was something real there.
Speaker 2:And I knew enough about Jason and his sensibilities and so forth to know that there would be a connection, or at least suspect that there would be connection. And then we just chatted on email and sort of got into enough of a level of trust. Also, what was I really risking? I mean, he was asking me to do work. I was asking him to pay me $15 an hour.
Speaker 2:I mean, you don't need a whole lot of trust for that transaction to happen. Yeah. And then trust builds. You just we kept making transactions, which sounds so clinical, but that's what it was. We I kept creating work.
Speaker 2:We kept paying invoices. Boom. Trust. I think it took six months, maybe even more before I met Jason for the first time. Actually, think it took six months before I talked to him on the phone for the first time.
Speaker 2:And I think it took maybe a year or two before I visited the 37 Sickles office in Chicago. But by then, we already had complete trust established. Mean, we knew we cared about the same things, we knew that we shared the same values. So it really wasn't that hard.
Speaker 1:Yeah. Well, maybe let's talk about how this partnership looks in action. Because again, last time I chatted with Jason, we talked about launching the new Basecamp. And I think he said you originally were against the idea of of rebuilding Basecamp, largely because that's usually a bad thing if someone wants to rebuild an app. The traditional wisdom is that you shouldn't.
Speaker 1:Is that true that you were kind of originally against
Speaker 2:the Well, what I was, I was skeptical. And I was skeptical that what we were going to do was just rebuild the same thing. I wanted that if if we were going to remake base cam, we should make something else. I mean, base cam plastic already exists. Just tearing all that down and building exactly the same thing back up again, that didn't make any sense to me at all.
Speaker 2:And and certainly, I'm familiar with the saying that that all rewrites end up sort of bankrupting companies or or whatever. Mhmm. So that was the first thing we needed to establish. We needed to establish that we were building something else, that we were much wiser now, that we were going to build a different kind of product. And we set up to to basically spike that up.
Speaker 2:So Jason had a bunch of design ideas and we talked a bunch about the concept of how this was going to be different. And I had a lot of build up thoughts about how we could tackle this in a different way, especially as it revolves around the speed of the application. I wanted this to be just ludicrously fast.
Speaker 1:Mhmm.
Speaker 2:Sort of this symbiosis there informed a lot of things back and forth. Jason wanted a much cleaner, simpler design, which played in incredibly well with the thoughts and ideas that I had about sharing caches and other approaches to making this thing really fast. It also goes just that is the the core of of our working relationship, I think. I am generally the more cautious, the more which sounds funny, but in many ways, more conservative when it comes to bit the business aspect of things. Yeah.
Speaker 2:And Jason is the more sort of optimistic, bullish, let's tear stuff down and build something new, let's let's push the envelope on a lot of these things. And I think the or I'd like to think at least, that the magic happens in the middle. That by us pulling in each opposite direction, we end up with a great middle ground where we are respectful both of the business that we have built and we're able to innovate and and revitalize the business.
Speaker 1:Yeah. Yeah. And I think I remember seeing you guys did a like a commit history video for Basecamp. Yep. And I noticed like at the beginning it was like almost all you.
Speaker 1:Like you had tons and tons of, you know, you're committing lots of code. Is that usually how new projects start is you kind of bang out your the initial framework or and then you get other team members involved, you know, after it's kind of started? Or what what's the process?
Speaker 2:Yeah. That's that's for products, at least for the bulk of the major products that we've done, that has been the pattern. Not so much just because it's me banging it out, but I think the magic of most new products are that you just you're still exploring an unknown domain. And while you're still exploring an unknown domain, it does it's not really helpful to have 10 cooks in the kitchen. Mhmm.
Speaker 2:You need you need just one person or or very few people just figuring out how should this feel, how should this be, what should the architecture of this be. And I even I fucking hate the word architect. Right? I I hate the idea that somebody should just sit down and imagine how things should be, and then they prescribe this in some sort of spec, and then the minions go off and implement that. Right?
Speaker 2:Yeah. I can't stand that notion. So the only way that I can impose a sense of architecture is actually to build it and to build it myself. So that's what I did with BCX. I built the initial spike of it.
Speaker 2:Certainly didn't have all the features and everything that we wanted, but it had the sort of framework of work. But it wasn't just a framework because that doesn't work either. I mean, that's that's the same as architecting. Just sit down and make something reusable that somebody else is gonna gonna go ahead and and reuse. It's gonna be crap.
Speaker 2:Mhmm. The only way to arrive at good architectural underpinnings is actual to build real stuff. So that's what I did with BCX. I think for the first three months of that project, I was working on it alone. Then we involved Sam to work on the JavaScript for the visual presentation.
Speaker 2:We have this sort of stacker is what it's called, which is this layered UI approach. And and he did a great job on that. And then I think we were like maybe four or more months into it and then we slowly ramped up. And then I think the whole project took maybe nine months. And then by the end of the nine months, we had the entire company banging away at it because now it was clear which direction it was going to go, I was comfortable with the domain, I had an architecture in place for making this thing screaming fast that others could just dive in and work with.
Speaker 2:And then we could just involve everybody and it was very easy to parallelize. But things are not easy to parallelize when you don't know what you want or how you're to do it. In in fact, that often ends up just being more work and worse work when when you have everybody just running around not knowing what to do and where to go.
Speaker 1:Yeah. Yeah. And I love that picture of you guys all working at that big long table at 37. It looked like in the final days there's a bunch of people on-site just all hammering away on Base Camp.
Speaker 2:Yeah. We did we very rarely do this, but also we very rarely launch new major projects or products at the size of Basecamp. But we had this crunch I think it was maybe a crunch week where we got everybody in and just as much to celebrate the launch as it was to to finish it up. But that was a good time. Yeah.
Speaker 2:But that was really just I mean, that was dotting the i's. The bulk of the work is done as a remote team remotely.
Speaker 1:Yeah. Yeah. And what are you working on right now? Is there what's the you know, you're you've just finished off the book. What what are you kind of working on now?
Speaker 2:We have a new product idea in mind that I'm basically doing the same thing I was doing for BCX, just on this new product idea. Just just me as a programmer and then one designer has been helping out, just spiking things out, giving a feel for for the domain. Not sure yet whether we're gonna build it or not, but I'm just trying to figure out how this should work and how it could be great. Then if we decide to build it, we'll involve more people and if we don't decide to build it, I've spent a couple of weeks or a couple of months doing what I like to do anyway, is to program. Yeah.
Speaker 2:So we win either way given the position we're currently in where the bills are being covered by existing products.
Speaker 1:And is that what you really like doing is kind of building brand new stuff?
Speaker 2:Not necessarily. It's not just about greenfield for me. I get a lot of pleasure out of making things and building things to last and improving them. I mean, heck I'm still working on Ruby on Rails a decade after I made the first changes and that's very satisfying to me as well. I was still working on Base Camp Classic up until we got started on BCX.
Speaker 2:I've still worked on a bunch of new features for for the new version of Basecamp since we launched it. So it's not just it's not just that the greenfield development is fun. Although, it is fun, but to me it's just programming is fun. Mhmm. I mean, sure it can be it can suck, but that's usually for all sorts of other reasons like your organization is kinda crappy or you painted yourself into a corner technically or something else like that.
Speaker 2:Most of the time, most of the programming that I do, really enjoy.
Speaker 1:Yeah. Yeah. And then
Speaker 2:I just try to bring as much value as I can to what we're doing at thirty seven Signals. And sometimes that's just hammering out a new feature. Sometimes that's creating a spike of a feature we have in mind and then somebody else finishes it. And then sometimes it's starting a new product. It's whatever needs to get done is is pretty much what I work on.
Speaker 1:Yeah. Yeah. And maybe let's actually let's let's end on this. Let's talk about racing a little bit, car racing. How did you get into that?
Speaker 1:And maybe just talk about what is there any lessons you've learned in racing that have applied to you building products?
Speaker 2:Sure. So I got into racing initially in 02/2007. Well, racing is a big word. I got into driving a race car on a track in 02/2007. Yeah.
Speaker 2:I've got just gotten my driver's license two years earlier. I kinda got my driver's license pretty late living in Copenhagen. You you don't really need a car, and even if you do need a car, they're hideously expensive, and hence I've been paid $15 an hour and plowing that into Apple equipment. Like there was disposable income available to buying a very expensive car as any car is in Copenhagen. Yeah.
Speaker 2:So anyway, I got my driver's license just because I wanted to use it actually abroad. Like I wanted to travel and you can travel to a lot of places where getting around by car is the only option. So anyway, I got my driver's license just like shortly before moving to The US and And then a friend of mine, somebody I met here in Chicago, took me to the local track that's about an hour away from Chicago and put me in a race car and of course, as most people or at least as a lot of people get into a race car find out, it's actually dangerous amounts of fun. So
Speaker 1:weren't scared? Like I've heard that some people get really scared because it's That way is true.
Speaker 2:So there is certainly a percentage of the population just don't enjoy speed. Mhmm. I didn't fall into that percentage. And you loved it? Yeah, really did like it.
Speaker 2:So I just slowly kind of got into it and started just going down to that track that's an hour away just driving on the weekends and so forth. It wasn't really until what is that, 2010, like three years ago, that I got into it with sort of more of a serious intent of actually going racing. And by then I had already put in a lot of hours at that local track, just honing my skills. So when I got into racing I quickly found out that A) I had at least a modicum of talent for it and B) that it was really fun climbing the ladder. And throughout the whole thing I this dream in mind that I wanted to go to the twenty four hours of Le Mans.
Speaker 2:To me that's always been the just the greatest motor racing event in the world. And I had plenty of role model in the Danish driver Tom Christensen who has now won Le Mans nine times. Way more than any other driver in the history of Le Mans motor race and the very long history of the Le Mans motor race has ever won the race. So that provided the motivation to have that as an end goal. So by the time I got serious about racing I just basically plotted out a path.
Speaker 2:How do I get from where I am now to being at the grid at Le Mans? And that entailed going through a number of different series, and climbing up through the classes, and climbing up through the cars, and so forth. And I think that that part for me is certainly transferable. I set out sort of once I got into something, for example with Rails, once I knew that there was something there, once I knew that I was having so much more fun making web applications with Ruby on Rails than I ever had with PHP or Java or any of the other tools that I've been making, I kind of set out that other people should be part of that. They should share that.
Speaker 2:So I took that seriously. I took it seriously that I wanted to basically spread the wealth of what is the wonders of the Ruby programming language to as many people as I possibly could. And I think that's very similar to climbing that ladder system. It's like first it's just get a few early adopters and you get other people involved and interested in helping building the framework so forth. And then you roll it one step at a time from there.
Speaker 2:Get two in one o and you do good marketing side for it and you do some promotion with videos and so forth. And that's all part of sort of that ladder. And as opposed to business, it's kind of the same thing that once we knew we had something with Basecamp, sort of charting a path of always having some goal in mind, oh we want to get to this, we want to get to so and so many customers, we want to we have this vision for the product that we want to get to, it's quite similar. And another final note on similarities, what really is pleasurable and interesting for me about programming is getting into the zone where you just feel like you're just engrossed in this logical problem that you're trying to solve and you lose track of time and other concerns. You don't have a lot of other things going on in your mind than just the program.
Speaker 2:And that's a rare and extremely pleasurable state of mind to be in. In fact, there's been quite a few books including Flow that claim that this is where this is the state of mind where most people derive the bulk of their happiness from. And I would certainly concur with that. What I found was motor racing is almost like a cheat to getting into a state of flow. When you're in a race car going 200 miles an hour, you don't have a lot of time to consider all sorts of other things you're doing.
Speaker 2:Like, oh, what should we have for dinner tonight? Or
Speaker 1:What's on Twitter?
Speaker 2:Exactly, what's on Twitter? You just have in mind that you need to make the next corner, and you need to hit your apex just right, and you need to carry three more miles an hour and you need to not crash and die. And that sort of sense of both danger and intensity just provides for a very easy access to that zone. And I learned to like that zone so much in programming that it just feels just great to be able to that easily end zone in another domain as well.
Speaker 1:Yeah. I like that. I think that's a good parallel actually because you know with with race car with race racing, sorry, car racing, you had this big vision of getting to Le Mans. That was like your overarching goal. That's where you're going.
Speaker 1:But in the car, you can't you have to think about kind of what's right ahead of you. And it's probably similar with building products. You have this big goal for where you want to get to with the product. But then there's also this idea of just, you know, getting down to the work and getting into that that flow like you said.
Speaker 2:Absolutely. I think that a lot of people just think that they just need the one part. They just need that grand goal and then they'll do whatever it takes whether it's fun or not to get there. I don't think that works very well. I think the path to getting to achieving your goals, if that doesn't go through state of flow, things that you really care about, where you really intensely enjoy the activity itself, likelihood of you ever reaching that goal is slim.
Speaker 2:Mhmm. Because it's just too hard to get good enough if you don't enjoy what you're doing. And if you're not good enough, you're not going to get to your goals. I'm not going to get to the freaking grid of Le Mans unless I really fucking learned how to drive a race car, not only safely but also fast. And I was not going to have Ruby on Rails influence be a part of a lot of programmers lives unless I really know or learn both Ruby and programming and how to put it all together and so forth.
Speaker 2:I was not going to get to that point if I didn't enjoy it. I mean you can only do things in pursuit of a goal for so long if you don't enjoy the activity itself.
Speaker 1:Yeah, exactly. Well said. That's a good way to end the show. David, thanks so much for taking the time to chat.
Speaker 2:Sure, my pleasure.
Speaker 1:You can find David on Twitter DHH and be sure to check out his book that's coming out fall two thousand thirteen. I think it just went it just went to the publisher, didn't it?
Speaker 2:In two days, it's going to the publisher.
Speaker 1:In two.
Speaker 2:So October 29 is actually the precise release date.
Speaker 1:October 29, it's out. 37signals.com/remote. Thanks again, David.
Speaker 2:Thank you.
Speaker 1:If you wanna follow David on Twitter, his handle is at d h h. You can follow me on Twitter as well. I'm at m I Justin or follow the show at product people TV. Thanks again to our great sponsors, Fusion Charts. It's a great JavaScript charting solution trusted by over 450,000 developers around the world.
Speaker 1:Fusioncharts.com and sprint.ly. Perfect for teams of three or more people. It's the easiest way to manage the software development process. Go to www.sprint.ly. And let me share with you something that one of our listeners is working on.
Speaker 1:Follow at topsideconcepts on Twitter. Randy is working on a product that will help companies improve their service by prioritizing input from customers. It's a really neat concept. Check it out. Www.topsideconcepts.com.
Speaker 1:Hey. If you like the show, I'd really appreciate it. If you went into iTunes and gave us a review, it's as easy as searching for product people and giving us five stars. That really helps the show get noticed. That's it for this week.
Speaker 1:I'll see you next week. Thanks.
Listen to Product People using one of many popular podcasting apps or directories.