55. When Side Projects Become Real

Ben: Yeah, that was a fun time. So that was, I don't know, 2004, 2005, that timeframe. I came to Ruby because of Rails. I read about it, I think, first on Slashdot, and I was a PHP developer at the time. I'd been doing web development for a few years by then. And the thing that I found is really fascinating about Rails was that it was building in all the things that I had learned as a web developer. Things like templating and database abstraction layer and things like that. All these best practices that I had learned over the years are being baked into the framework, and I thought that was just amazing.

Ben: And as I got to look more into Rails, I just fell in love with Ruby. Something had really clicked in my brain. I had dabbled with Python recently before being introduced to Rails, and I liked the idea of test driven development. I was reading Kent Beck's book on that, where he uses Python as a language, and I just fell in love with Ruby is really the best way to say it. And so I stuck around. In fact, I was so excited about Rails and Ruby that I decided I had to be doing that in my day job. So at the time I was working in a shop that did Perl and PHP, and I knew that there wasn't going to be a change there, and so I decided to get a new job. So I went and found a new job where I convinced the people who were starting up a new company that we should use Rails instead of anything else, and the rest is history. I've been doing it since then.

Ben: And in the early days, those years I'd love to hang out on IRC. You know, there wasn't much written about Rails since was so brand new, where everyone was learning at the same time. And IRC was the place to be to chat with people who were working with Rails on a full time basis, people who were learning about it. And so ended up in the Caboose channel, which was just a very friendly atmosphere for people who were having that same journey. It was a lot of fun to hang out there and get to know more about Ruby. Even the documentation about Ruby, there wasn't a whole lot in English at that point. There was a PickAxe book, so it was really helpful to have people to chat with to get resources, see blog posts that were coming in and get pointed to those, and as I was learning to be able to help other people as well. It was a lot of fun.

Mike: So that even pre-dates the Agile Web Development with Rails book?

Ben: Yeah. Yeah, it does. When I first learned about Rails, there was no routing. The router hadn't been built yet. So that was still done with htaccess rules and Apache. There was still this big question about, "How do you host this?" Because at the time, shared hosting was the main way that stuff was delivered. If you did it in Perl, then you used modperl or CGI. If you did PHP, of course there is modphp. And everybody used Apache. That's basically all there was. nginx wasn't really around yet, so there was a lot of change happening and people trying new things and FastCGI happened and Mongrel. It was a fun time.

Mike: I don't recall if we mentioned this, but your cofounders at Honeybadger.io, Starre Horne and Josh Wood, you guys have a podcast called FounderQuest, and I think I've been listening to it from the first episode. I find it very entertaining.

Ben: Oh, thanks.

Mike: Okay, so side projects. Honeybadger is a classic example of one of your side projects that became a business. Would you like to talk about that now?

Ben: Yeah, that's great. Yeah, I love doing side projects. I've been doing side projects for a long, long time. I find that it helps to get my creative juices out. For some reason, just having one project at a time doesn't consume all my creativity. Starre and I were working together at a startup in Seattle at the time that we came up with the idea for Honeybadger, and Starre and I had been working together both as employees of this business and as freelancers together for many years at this point. We had many times kicked out talking about different ideas that we felt like we could do together. We always had an idea that we wanted to start something together, but we didn’t really have—until Honeybadger—never really had the thing that we felt like we just had to do.

Ben: But when we were working together at this startup, we had this experience with Airbrake. We were using Airbrake at the time to track the exceptions that were happening in our Rails app that we were building. There's this one day that we had this error happen, and there was no detailed data inside of Airbrake about this error. And that was frustrating, because I didn't know what happened. And so we contacted Airbrake and asked them, "Hey, we see that this error happened, but there's no detail. Can you tell us what happened to the detail?" And we got an email back from customer support saying, "Yeah, we got an error but there's no detail." And that was basically it. And I thought, "Oh okay, you just quoted back my email to you."

Ben: So I just got kind of frustrated by that, and I turned to Starre and I'm like, "You know what, this is not acceptable. We can do better than that." And I felt like as developers, we deserve to have the best tools, and at the time that was not the best experience. So Starre and I decided this was the project that we were going to do. Within a few days committed the first line of code and just started working nights and weekends on it.

Mike: A couple of things. When you were talking about getting things going with Starre, didn't you have like a imagery sizing service that you guys built out just before this or within a year or two before?

Ben: Yeah, good memory. Yeah, we totally did. It was called Upload User, and it was one of those ideas that we had, and we just knew we had to build something together. That had a good start, but Transloadit was also launching at the same time, and then also Cloudinary launched around that same time, and frankly they were doing a much better job than we were, so we just kind of gave up. I think sometimes as developers, we get hung up on the idea that, "Oh, someone's already done it, so there's no room for me to do it. Why should I even bother?" But, you know, even with things existing in the marketplace already, they're not perfect, right? There are going to be issues with them that you have or that somebody else might have. In Airbrake's case, for us, it was at the time the owners weren't getting great customer support, and so we figured, "Well we can do better than that." And maybe there is some other feature or whatever that you think you could do better. And I know I'm all about, "Yeah, sure. Take a stab at it. Why not?"

Mike: Yeah. The other thing that comes to mind when I heard the story originally was that in software engineering there's this idea of like BDD, behavioral driven development, and TDD, test driven development. You're basically writing your tests and having them fail until you have something that works, that gives you good constraints to not overthink a problem. To me, when I thought about how you probably reverse-engineered this, of essentially pointing the Airbrake code at a service that you're standing up and slowly just going through and making sure each of the functions worked. It seemed like the ultimate BDD. Is that actually what happened?

Ben: Yeah, that's exactly what happened. Like I said, we were using Airbrake at the time, so we had the Gem installed in our app. So what we did is we just stood up an end point that accepted the same exact payload, and we just changed the configuration of our Gem and our app to point to our new API endpoint rather than the official Airbrake one, and we just started from there. For a long time, and maybe even still today, I’m not even sure, we had an endpoint that would work with the Airbrake Gem, and so we could actually tell people, "Hey, if you want to try us out, you don't even need to install our code. You can just switch the configuration of your current code and point it at our new API to try it out."

Ben: And that was very helpful for some people. But that definitely gave us a starting point, a leg up on getting started that we knew what we needed to support, like what kind of payload that would be coming in. That allowed us to say, "We knew the experience that we had with Airbrake today. How do we want that experience to be different in our own app?" and just start from there.

Mike: How about any pushback that came on that development process? There are probably so many Sasses out there that exhibit the same behavior: poor support, they've published their API interface, whether it be an HTB docs or actually in software. How much pushback did you get from the community on the origins of Honeybadger?

Ben: We did have a few people who were kind of cranky about the idea of us reusing the Airbrake client library. Not too many. The vast minority, I would actually say. Most people are like, "Oh, that's kind of clever," and appreciated that they didn't have to install something new to try it out because we were unproven. I mean, who knew if we were actually going to be around in a month? But yeah, there were a couple people that said, "Well, that's pretty stinky." Or we even had somebody call us thieves. It's like, well, I mean it's an open source license project. Actually the license has changed since we did it, so it was a little more lenient back when we started. But that's the point of open source, right? You get to reuse what other people have done, you get to stand on their shoulders. It's not like we were going out and saying that Airbrake was evil and they were killing babies or something. We're just using the code that they had published as open source.

Mike: I want to say that I heard on another podcast recently that Kubernetes kind of has the same origins in that all of the Cloud providers want to have a uniform system so that you potentially could switch back and forth between Cloud providers and then they compete on the deeper services that they provide. Does that sound right?

Ben: Totally. And I've been involved in open source since about 1993, I guess. I've been an Access user for a long time, and, to me, that is the ethos of open source. We share, we put stuff out into the community because we want to contribute back to the world. At least, that's how I view it. I know that there are different views out there, but you don't put something out and open the code and expect people to never look at it, right? Or to not build on top of it themselves. That's the whole point of open source, and to me, that's one of the reasons why I decided to be in part of the community.

Ben: Back in that time frame, Microsoft was dominant in the tech industry, it wasn't necessarily the natural choice to use Linux, back when you had to install it with, like, 40 floppy disks. You had to be pretty intentional about wanting to do something different, something that was a little bit out of the mainstream. To me, the whole appeal of things like Kubernetes and things like Apache and Linux is that you get to see how it works, and then beyond that, you get to make it work in the way that you want to make it work. You can make your own changes to it and do what you want with it.

Mike: Let's kind of talk about, like, I'm a new developer or I'm a developer that's always been focused on my company. Maybe I've had some entrepreneurial urges in me. How would I go about working on a side project if I'm working for somebody else at the same time?

Ben: Well, my first side project that I can recall anyway was a test plan manager. Basically it was my first or second job out of college, first or second full time development job, and I'm slinging code all day long and I'm curious on how I'm going to test this code. One job I didn't have any QA staff to work with and at another job I did, and so I wanted something, besides Word documents, that I could use to manage like test cases. So I just built this little crud app that did that. That's a long way of saying you look for some need that you have. You want to have something exist in the world based on what you're doing today. And that's a great side project. I never did much with that particular side project but it was fun for me, and it was something that I found useful.

Mike: So we started this conversation off talking about the shiny Sass app on top of the hill, the Honeybadger. But I think another example that I know that you have is the Rails kits, which isn't so much a Sass, but it was providing something useful to other developers, which were your customer. Can we talk about that a little bit?

Ben: Totally. It started as a side project, also like a byproduct of my day to day work. So at the time, I was a freelance web developer. I was building Rails projects for entrepreneurs. My typical project was somebody with an idea would come to me and say, "I have this thing that I want to exist in the world, can you build it for me?" And so we would work together to build that app. And what I noticed after doing several projects was that there was this common theme of when you build a Sass, you have to build the user management and the billing system. So thought, "You know, instead of rebuilding this code again for the n-th time, how about I just pull it out, extract it—just like Rails was an extraction from the original Basecamp work—how about I extract this and make it into a product and see if people buy it?"

Ben: And it turns out, yeah, people did buy it. Again, that was something I was working on in my day to day. I recognized this need, I had to be able to speed up my development time, so I built that out of that work.

Mike: That reminds me of other projects and services that you built. Can we talk about PackageBot?

Ben: Yeah, so PackageBot is the latest one that I worked on and just released that a couple of weeks ago. It's very simple. All it does is it is an API endpoint for you to send, from your Debian box or your Ubuntu box, a list of packages that are waiting to be updated. So if you hop onto an Ubuntu server, it'll tell you, "Hey, you've got 20 packages that need be updated," and you do an apt upgrade, and it gets those packages, and everything's great.

Ben: At Honeybadger, we have 30-ish servers running, and they all run Ubuntu, and so they all have package updates and I don't really want to keep track of that myself all the time by logging into them. So we've used Apticron in the past, which is a great open source utility. What it does is every day or every week, whatever you define, it checks to see which packages need to be upgraded, and it sends you email telling you which packages need to be upgraded. So we do everything at Honeybadger out of Slack for our dev ops. We have those emails from Apticron show up in Slack. And emails forwarded into Slack just isn't the best UI. You can see them but it's not great. So I decided I wanted that, but I wanted it to be prettier.

Ben: And so I built PackageBot, which basically all it does is takes those package update information and then sends a Slack message to you saying, "Hey, server blah has these packages that are waiting to be upgraded." And then I can go in and use Ansible or whatever to then update them. So again, it was another one one of these little itch that I had, and it's like, I built it just internally first, and that was cool. I was like, "Well, you know what it's not going to take a whole lot more work just to slap Stripe on there and do some billings. So how about I just push it out there to the world?" And there it is.

Mike: Let's back up. We keep on giving good examples of good successes. Let's go back to the beginning. How do you kind of vet out for yourself? You have an idea about something, how do you determine if it's a good idea?

Ben: That answer to that question has changed for me over time. You know, when I did the first side project, that test plant manager, there wasn't really a whole lot of thinking, "Is this a really good idea?" I just wanted it, and I had some spare time, and I had the desire to write some more code and just build an app. So boom. It was fun. I guess if I would have sat back a little bit and thought about it, "Is this a good idea?" Yes, it's a good idea because I want to have something to play with. It's a hobby kind of thing. These days, I'm a little bit more discriminatory with my time. I have a Honeybadger which feeds me and feeds my family, so I'm not desperate for an idea that's going to get me out of the rat race, for example.

Ben: So now it's like, "Oh, do I want this to exist badly enough to work on it even if nobody else cares?" To me, that's the criteria that I usually use to determine, "Is this a good idea? Do I want it bad enough myself?" And I think it's totally fair to say that I'm not going to work on something unless I can envision a thousand customers and paying me at least $10,000 a month total MMR. If that's your criteria for whether you engage on a project, sure, that's great, too. I think that takes a little more leg work up front, because you should do some market research and see if that's actually viable. That's not just a hobby fun project anymore, that's something you wanted to turn into a business.

Ben: So I think maybe the shorter answer, the first step is what are my goals? What do I hope to accomplish with this project that I'm thinking about? Do I just want something that's a creative outlet? Do I want something to contribute back to the world? Do I want something that's going to support my family? Once you have that end in mind, then you can begin well and decide does this particular project meet those goals?

Mike: So obviously you're a professional programmer, professional engineer, but also clearly that you like programming in your free time. So basically your hobby, to some degree, is what you also do to make a living.

Ben: Definitely.

Mike: I know I've heard you talk about—you like to ride road bikes now. Is that right?

Ben: Yep.

Mike: So have you ever had to deal with burnout or having what you do for fun mixing up your work too much?

Ben: Yes to both of those questions. I'll answer the second one first because it's the Honeybadger story. When Starre and I were working at that startup, we didn't really have an intention of leaving that startup. We wanted Honeybadger, we wanted to build it, but we weren't looking to replace our jobs per se. We were happy where we were. But Honeybadger got to the point, because it got successful enough, that we didn't really have a choice. In the early days, we had scaling issues, we'd catch on fire as we got new customers that were sending us a lot of traffic. And so all of a sudden it's like, "Oh, I got to take a lunch break right now so I can go deal with these servers that are falling apart." And that's not fair, to have that kind of situation where you're stepping away from your employer, paying you to do something, to go do your own thing. In the middle of the day, it's not fair to steal time. But most of my side projects aren't like that. They're just minor. They don't take much time.

Ben: And the burnout question is, yeah, I've definitely experienced that. There are times when I'm working, writing code or whatever dev ops stuff I have to do, and I get home and I just don't want to touch the computer. I just want to get on my bike. I can't put 40 hours of hardcore creative work in a week. I can't do it. When I get to four hours of deep thinking on code—I'm done for the day. Maybe five, if I'm lucky. If you asked me to sit in a chair for eight hours a day and be productively writing code, that's just not going to happen. I don't think that's realistic.

Ben: And so what we've done at Honeybadger, we've acknowledged that the three of us, we're all like this. We don't have unlimited energy to write code and be that focused. And our policy is, again, since we're all remote, we're not looking at each other across a desk. Well, go take a walk, or go ride your bike, or go take a nap or whatever. It doesn't matter. Just go do something. If you're done, you're done. And as we've been doing this for several years, realizing, you know what, let's just make this a policy.

Ben: So our policy now is we have a 30-hour work week at Honeybadger, and how you do that work week is up to you. Do you want to do six five-hour days? Okay, well great. Have at it. Do you want to do four days of eight hours? Well, okay, if that works for you. And we're not strict about the whole 30 hour thing. It might be 25 hours in one week, it might be 40 in the next. Who knows? Based on whatever your schedule is like and whatever needs to be done. But basically acknowledging that we are not going to be working productively 40 hours every week, so let's just call it like it is and be honest with ourselves and just give ourselves the flexibility, the leeway, to just stop. When you feel like it's time to stop, just stop.

Mike: Not all ideas are good ideas and a facet of that is sometimes ideas don't happen at the right time. Do you have any experience with this?

Ben: Yeah, I had a couple of projects that just didn't work out. That one, that test plan thing, at first was just for me, and then I thought, "Oh, maybe I could sell this," and that didn't work at all. And then I've had other projects where it was for fun, and I thought, "Well maybe I can do something with it and try it a little bit," maybe kind of halfheartedly, and that didn't pan out. I don't necessarily regret the time I spent on those things, because I was building stuff and I was learning stuff and that was cool and really a win enough.

Ben: I think it goes back to those goals. If I would have been depending on one or both or however many projects that haven't gone anywhere, if I was depending on those projects to support me and my family, those would feel like colossal failures, because there's no way that they did. I think maybe just being a little easy on yourself. It's okay just to set out to have some fun. There was a great presentation in RailsConf 2019 by [Justin] Searls. He talked about basically doing programming for fun. Even if you're a professional programmer, it's okay to have fun with a side project or even a work project maybe that's kind of experimental. That's a great presentation. Definitely check that out. I thought it was really enjoyable.

Mike: That reminds me of hearing you guys on FounderQuest talk about how your work-life balance is at Honeybadger. It seems like Josh really tries to adhere to a creator schedule. It seems like he's real protective about not being in huge blocks of time where he has to be at the keyboard, that he has a creative and flexible lifestyle. And I've heard you guys talk about how you handle vacation. Can you talk about your guys's work lifestyle?

Ben: Yeah, I think we have tried to optimize for enjoyment of life first. We all have families and we all do enjoy spending time away from the computer, and so we decided early on that we did not want to have the prototypical Silicon Valley venture funded startup madness of 60 hour weeks or whatever, and that we wanted to have something that was sustainable, something that would maintain our lives without consuming our lives. We also chose early on that we would be 100% remote because we did not want to waste our lives commuting. I think those two choices have been instrumental in how we work. We try to work independently so that we don't have dependencies on each other. We don't have to coordinate closely, which means we don't have to be sitting in the same room talking to each other.

Ben: We've chosen a particular market to serve. We don't try to sell to large enterprises, for example. That's not something that we're interested in, and allows us to be selective about how we run our support. We don't have to have an account manager who's going to be on the phone with large accounts because we've decided that we wanted to go for people like us: smaller-sized companies, small teams, individual freelancers. So all those choices kind of snowball into allowing, for example, me to go during the summer months, to leave at one o'clock in the afternoon and go ride my bike on the trail for a couple of hours. Josh, like you said, he likes to spend big blocks of time just focused on code. So we decided that that's the kind of company we wanted, so that's the kind of company built.

Ben: For me, I think that really was the motivation for all these side projects. Even if I didn't have the stated goal of this one's going to support my family, I wanted my own thing. I enjoyed working for other companies. I've enjoyed the working for clients, when I was freelancing, but I always wanted to have my own thing. And that's why Starre and I were always on the lookout for what's the project that we're going to build together? What is that? Because both of us had that same goal of wanting that thing that was ours.

Ben: And to me, that's the beauty of what we do as developers. We have the ability to take an idea and turn that into reality. All it takes is some typing. And I guess back to the open source bit, with all those tools that are out there and with things like Heroku that make it easy to deploy stuff. Having all these resources, all the blog posts, and all the papers that you can read about how to do whatever you want to do. It's just an amazing world that we live in, that we can create something out of nothing and we can have that thing and share it with the world. And if we're lucky, we have fun while we're doing it.

Mike: All right. Well, Ben, thank you so much for being our guest today on Code[ish].

Ben: Thanks.