60. From Engineer to Entrepreneur
Hosted by Erin Allard, with guest Ben Orenstein.
Ben Orenstein had been working as a programmer for 15 years before he started his first software company. While he knew he had the technical skills to build the application he wanted to sell, his challenge was in establishing the business around it. On this episode, he'll provide advice for other developers interested in quitting their jobs and starting their own companies.
Erin Allard is a Platform Support Engineer at Heroku, and she's interviewing Ben Orenstein, one of the co-founders of Tuple. Screenshare was a popular pair programming app that was discontinued after being acquired by Slack. Finding no other alternative for this functionality, Ben and his friends built Tuple.
Ben spent much of the early months of Tuple investigating pricing strategies, because he understood that the business wouldn't exist unless he could charge a reasonable price customers would be willing to pay. This process also reduced the risk of their efforts, knowing that they could burn through months of savings with the likely goal of being able to turn a profit. To that end, Tuple became completely bootstrapped and self-sufficient.
Ben continues by pointing out that having a group of advisors has been instrumental to Tuple's success. These are friends and former colleagues who provide direct feedback, which allows Tuple to shape their own product roadmap based on real needs. He mentions the importance of being able to focus on the product and not the infrastructure as the main reason for choosing Heroku as the backend platform.
Links from this episode
Erin: Welcome to another episode of the Code[ish] podcast. I'm Erin Allard, a platform support engineer at Heroku. Today I'm talking with Ben Orenstein who is one of the co-founders of Tuple. Hello, Ben. Thank you for joining us today.
Ben: My pleasure. Thanks for having me on.
Erin: Can you tell us just a little bit about your professional background and then we can jump into talking about Tuple and the whole topic of today's podcast, which is making the shift from engineer to entrepreneur.
Ben: Yeah. I spent most of my professional life as a programmer. I've been writing code for I guess about 15 years now. And mostly in Ruby, written a lot of Rails apps. Done some consulting, done some product work, that kind of thing. And two years ago I decided to quit my job and start my first software company with two friends of mine.
Erin: Can you tell us a little bit about what you and your co-founders decided to build and why?
Ben: I had been wanting to start something for awhile, and so I would go over to one of my co-founder's apartment and we would sort of kick around business ideas. And this process actually happened over the course of weeks and months, I think.
Erin: Oh. Yeah, because Slack definitely does not have a pair programming feature.
Ben: Yes, exactly. I kept looking around and asking programmer friends of mine, "Hey, what are you using now that Screenhero is gone. And everyone seemed to have no answer for that. Eventually one day it seems like there was this great answer to this problem, that was a real problem, and then it went away. Now there just seems to be this gap in the market and no one has filled it and it's been years.
Ben: And so we said it sounds hard, it sounds technically difficult. It's not like what we've done before, but what if we just took a crack at it and could see if we could make this.
Erin: I'm smiling because you sound very much like how I sound in my own mind, which is being able to identify a place where a thing should exist and then having the skills needed to bring it to life.
Ben: Hmm. Yeah. Well it turns out we figured it out, but in the beginning, it was very unclear and that was the scariest thing about this whole transition actually, was that the technical complexity felt really high and we weren't sure if we were going to be able to actually build something good.
Erin: Okay. So the Tuple app helps developers pair program together. For folks who might not know this phrase or who might be new to the industry, could you tell us what pair programming is?
Ben: Yeah, it's kind of a fancy name for a pretty simple concept, which is just two programmers or maybe even more, but usually two, writing code together, usually on the same machine.
Ben: So if I were just like, "Hey, could you take a look at this with me?" Like, "Hey, Erin, you know this backend code by than I do. Could you help me with this whatever?"
Ben: And then we're sort of sitting there and you're watching while I'm typing or vice versa. That's pair programming. That's kind of all it is.
Erin: Can you tell me a bit about what was the driver for you from going from building things to running a company that builds things.
Erin: Is this an internal drive for you? Have you always thought, "Hey, I want to run my own thing." Or was it more, "Me and my buddies just like building stuff together? Let's do it more formally."
Ben: It was definitely more of the former. I felt for kind of a long time that this would be my eventual destiny. This seemed to be the best lifestyle possible if you could make it work. And so I've been trying to move myself in that direction for awhile.
Ben: And so a lot of the side projects and things I've taught myself over the years and things I took on at work were kind of designed with that long-term goal in mind. I was trying to teach myself the skills for how to run a software business while I was still making a normal developer's salary.
Erin: So you've been noodling on this for a while and kind of preparing yourself.
Ben: Yep. Noodling for sure, but also intentionally launching... Making things. I've launched a couple of really tiny SaaS apps in the past and eventually volunteered to run a SaaS app that my previous company had started. So I was trying to take action and learn these things while I could get paid for it.
Erin: Exactly. Yeah. Good for you. What advice would you have to folks who might be listening, who are kind of in the same boat as you and have a lot of the same drive as you do around wanting to shift from making their own apps to actually running a company.
Erin: What would you suggest that they can kind of weave into their professional lives right now to help them keep marching forward towards that? So what did you prioritize when you were making that transition?
Ben: My guess is for the average developer, you're going to be very strong on the "software" part of software company and not as strong on the "company" part.
Ben: So you're going to have all these technical skills, right? You'll know how to build the thing, but building the thing is a third of the problem or something. It's some non-dominant percentage of what it takes to run a software company, I think.
Ben: So because you're already so concentrated, your tech skills will be so far ahead of your other skills. So I would mostly not focus on tech once you're a couple of years into your career.
Ben: I would instead focus on the other pieces, like how do you actually get a person to pay you money for something?
Erin: Mm-hmm (affirmative).
Ben: And that's a complicated answer to that and there's a lot of answers and there's different shapes and all this. So I would try to get someone to do that. Part of the reason that we have been reasonably successful is that I've tried to get people to buy software that I wrote on the internet a bunch of times. And so you just learn, there's a lot of lessons you learn and things you realize that work or don't work. And I'm not sure there's a better way really than just trying to do it.
Ben: So I might ask myself if I were interested in eventually making this leap, what's a really small thing I could build that I could try to learn how to sell and learn how to market and learn how to do good customer development, and actually build something people really want, and then convince them to give you money. All that stuff that's outside the technical realm.
Erin: I really love this idea because it's basically prototyping a company, like pick some side project that maybe solves a problem you have or solves a problem enough people have. See if you can design it in a way and provide value in a way that people are willing to pay for it, but maybe not even have the expectation that it would develop into a full company; just giving yourself the practice of creating a product that you would sell as opposed to a project which you just kind of keep to yourself.
Ben: Yeah, I think if your bar is I want to go from making a developer salary to starting my very first SaaS app and have that eventually sustain me full time... That's really, really hard. I think doing that in like one go is kind of probably unrealistic for most people.
Erin: Mm-hmm (affirmative).
Ben: But a more realistic thing is to start your first three small things quickly and use them as learning experiences and do them while you have the safety net of a full time job. Launch them on the side, see what you can do.
Ben: If you can't get them anywhere, then you'll realize, okay, there are certain things I need to improve about my skillset or my knowledge and you'll be able to do that while it's not expensive and while you're not burning through savings and panicking.
Erin: Right, right. And it's also just a much more strategic approach, kind of trying to leap pad yourself forward.
Erin: You mentioned something just a moment ago, I think it had to do with wanting to leave your developer job. That's actually one of the questions I wanted to ask you today, which was what was it for you, either emotionally or structurally, changing so drastically, your day to day routine, right? Where you're a developer developing someone else's thing, you're getting a really steady paycheck and then all of a sudden you're kind of on your own, both in terms of what you do with your time and how you're bringing in money. What was that like?
Ben: It was actually kind of great. It was occasionally stressful but mostly really good. So I have two co-founders and we work in one of my co-founder's second bedroom in his condo.
Ben: My day-to-day looks like waking up, walking a few short blocks to the "office" and then working on this problem with people that I really like a lot and respect. The actual day-to-day was quite fun.
Ben: I was leaning on some interesting skills I had developed. I was learning new things. The being kind of having no one to answer to was kind of okay for me personally because I feel compelled to do a good job because I think we all kind of feel that for each other. We all want to contribute equally to the good of the company.
Ben: It was a bit stressful financially, of course. We all saved money, so we had a decent amount of runway going into it. But it almost doesn't matter how much is there. I think if every month it only goes down, it's just definitely stressful knowing, "Hey, I have a finite number of months left and I can see that number ticking down consistently."
Ben: So that was a bit hard, but we did early on while we were... So my two co-founders, Spencer and Joel, were doing most of the code. And so while they were writing the first version of the app, I was actually out selling it to people and getting people to sort of pre-commit to purchasing licenses to it.
Erin: Oh, okay. I'm sorry to interrupt. I just want to clarify this. So you were actually out selling the product before it was even finished?
Ben: Yeah. Before it was even anything. Way before it was launched.
Erin: Can you tell us a little bit more about that?
Ben: Yeah, totally. So in my mind there were basically two big risks when we got started. One was that no one actually wants this thing that we're making and the other was that people do want it, but we don't know how to make it. We're not capable.
Ben: So I wanted to start knocking those down early on so we wouldn't waste a year or multiple years. It turns out one of those just wasn't going to go our way. So for the first one, to make sure that we were making something people actually wanted, I started trying to sell it before it existed.
Ben: So I started with very warm connections like friends of mine, people I had met at conferences, other developer friends and said, "Hey, we're making a thing. Our inspiration is what Screenhero was, that tool that I know you used and liked. If we make this thing and it's good, I'd love you to be an early customer. Would you commit to paying a few hundred bucks for an annual account to be one of our first users? And in exchange, you're going to get a ton of access to us. You're going to get the ability to sort of shape of the project and you're going to get the product before anybody else gets it."
Erin: The reason why that's interesting to me is that most people I've come across who are building a thing that they eventually want to make money on are so desperate to get early feedback that they're practically giving it away or are literally giving it away. Did you consider doing that? Offering customers use of your product early on for free or... Just tell us more about why are you charging customers for something before you've built it?
Ben: It was mostly to de-risk it. It was to prove to ourselves that people would pay for it. Because we weren't interested in whether people would use it. We were interested in whether it was a viable business.
Ben: So giving it to people for free could show that they would use it, but it doesn't show that they will actually pay us money for it. People want to support you. Like if you tell them, "Hey, I'm working on a startup, it does this." Everyone wants to tell you what you want to hear, "Oh, that's so cool."
Ben: And if you were like, "Oh, would you use that if we made that?" They were like, "Oh yeah, totally. I could definitely see myself using that." Everyone will say yes to that question. But if you say, "Awesome. It's $400." They go, "Oh well, I'd actually have to think about it because X, Y, Z."
Ben: And then suddenly you have a lot more information when you actually try to get someone to give you a credit card.
Erin: Right. And a follow-on question to this is how did you come up with that initial price that you were tossing out?
Ben: Hmm. I didn't come up with a price. I actually tested lots of prices. So for every person I talked to, I would a different price. And I slowly basically walked... Mostly just walking it up as time went on. So I tested a huge... The highest price I tested was maybe five times bigger than the lowest price I tested.
Erin: And did you notice any trends depending on to what level you raised the price or who you were talking to or that kind of thing?
Ben: Yes, definitely. So there definitely is some price elasticity. Bigger companies in particular, they are not afraid of big numbers and so you could say, "Oh, it's $1,000 a person a year." And to them it's just like, "Whatever. That doesn't really matter. It's just fine."
Erin: Because they can write it off.
Ben: Yeah, it's not their money and they have a lot of it. And so there's definitely... It was interesting. I got some yeses at $200 a year and I got some yeses at $800 a year.
Ben: I did notice though that the higher prices pushed us into bigger companies that had slower purchasing processes. And so one of the things I had to sort of step back from is to sort of say, do I want to run a company where we are doing enterprise kind of sales that take three months to close? Sure we can make a lot of money on those things, but is it fun? Did we start this company to do stuff that's not fun or that we really don't like?
Erin: Right. It also adds an element of risk for you. Are you going to get paid? When are you going to get paid?
Ben: Yes. It's just that I find it kind of soul-sucking to fill out vendor qualification questionnaires and things that. And so the pricing we moved to actually over time was on the lower end of the range I tested because I was more interested in building a self-serve kind of business where people could just sign up and do it.
Ben: We actually do enterprise deals, like bigger deals with customers, but it's typically because they've sort of raised their hand and said, "Hey, we want this sort of special feature or custom terms of service" or whatever and we have a pretty reasonable... There would be like a sort of a floor on the size of those deals. It's like, "Okay, if you want us to do annoying things, it's going to cost you at least $10,000 bucks or whatever."
Erin: And just on a more I guess sentimental note, what was it like for you the first time a customer, maybe a big customer reached out to you as opposed to you having to go hunt people down?
Ben: It's amazing. I'm not sure I even remember the first time, but I can tell you even still... There's so many little fun things about having built your own thing.
Ben: I like to search for our company's name on Twitter. I only do it 20 or 30 times a day. But when someone tweets something positive that we didn't tell them to do or they just decided to share with the world that they like our app... It's so satisfying.
Erin: Oh, yeah. I can imagine.
Ben: So there's just a million little dopamine hits available to you when you're doing this.
Erin: One of the things that stood out to me as I was reading the Tuple website was that you all are not only self-funded but also sustainably profitable and I believe I'm remembering this correctly, you have not taken any investor funding, right?
Ben: Yep, totally true.
Erin: That is really, really rare in tech. Can you talk a little bit about each of those points, the self-funding, the sustainably profitable and why you chose not to take funding?
Erin: I don't know if that's in the cards in the future, but at least you've made it this far without it, right?
Ben: Yes, we have. I would say funding is probably not in the future. The reason we didn't look to funding... We had the option of doing it. We decided not to. And the reason was that we thought we could make it to ramen profitability without it.
Ben: And so rather than sell equity in the company early when it was worth the least, we figured we can probably get there without doing that. And if we want to do it, we can always do it later. And with every passing month, as long as revenue is trending up, the stock is getting more valuable, so we can get more for it later if we wait.
Ben: So it was part of it was financial, but probably an even bigger part was we liked that we were the only ones that had control. We didn't want to answer to somebody else. So much of the motivation for the three of us to start our own thing was the flexibility and the control that it would give us over our own destiny and lives and work-life balance and all of these things.
Ben: The idea that all that stuff would suddenly start to be influenced by outside investors was not something we were interested in.
Erin: I'm based in Silicon Valley, even though Heroku is mostly a distributed company. Here in Silicon Valley, you hear a lot about VCs throwing gobs and gobs of money at even just concepts trying to get market share. Is that something that you all have considered as well as you thought about whether or not to take funding? Just the idea that more money could help you reach more customers potentially and maybe stave off competition?
Ben: So we do think about... We do occasionally just sort of bring up the thought experiment of what would happen if we raised money just to sort of make sure we're not just writing it off once and never reconsidering it.
Ben: I would say the biggest argument I can think of in favor of us raising funding would be to hire some additional people. There's, of course, a ton of development work to be done and it would be amazing to have a designer on staff and things that.
Erin: Mm-hmm (affirmative).
Ben: So that's sort of the biggest argument for it. But I think where we've come down is still that we value the freedom and the flexibility and I kind of have this feeling like I want to earn it. I want to be able to hire somebody because we grew revenue to a point that we could afford them sustainably.
Ben: I think that would just feel so much better to me versus, "Oh, we raised a bunch of money and then we started hiring people and now we're negative. Remember when we were profitable? Well, we're not anymore. Now we're like burning money every month. We're back to where we were, like when we started."
Ben: And having achieved... Having crossed that line where we're sustainable to go out of that zone again feels bad to me.
Erin: I'd like to switch gears a little. I'm really curious to know what has surprised you about this evolution or what have you discovered about yourself or about this process that you may have been unprepared for?
Ben: I guess one thing that I've learned that was a bit surprising... I have seen this in myself, but I think the pressures of running our own thing have made it more apparent, which is it's really easy to get (for me in particular) to get focused on what has happened in the last couple of days or the last few weeks and extrapolate too much from there.
Ben: So I find myself a little bit too sensitive in both directions. Meaning like, if it's been really good, I assume that everything's going to be amazing. And if it has been not so good, I assume everything is going to be terrible.
Ben: The thing I'm working on for myself is just being like less... Like don't let myself get pulled in either direction until there's a longer term trend to pay attention to and then start to extrapolate from there.
Ben: We don't have investors, but we do have a group of advisors that are our friends and people we trust. And I send them an update about once a month from the company. And a recent one a few months ago, we had a not so great month and I sent this update and it was like, "Oh, the sky is falling, I feel terrible." And everyone was like, "Chill out dude. Everything's fine. Don't over extrapolate from one month."
Ben: And then the month after that we had our best month ever.
Erin: Oh, wow.
Ben: It turns out there's some noise in the signal and so if you react to every little up and down, you're just going to go crazy. At least I will.
Erin: So now that you... Actually, I should ask. How long have you all been running Tuple?
Ben: It's been about 18 months now.
Erin: And you're sustainably profitable. The trend is going up. So what are you working on now? I can imagine that the first few months you were coding furiously, doing sales furiously, trying to test the market. What sort of phase are you at now with the product and with the business?
Ben: In the short term, we've been focusing on stability. We had a nice amount of growth over the last handful of months and we actually hit our first sort of scaling challenges. So we had to spend some time-
Erin: That's a good problem to have.
Ben: It is totally, yeah. And because we are charging for it and customers are profitable to us, we can throw money at this problem, which is nice to just, "Give us a few more dynos. All right, here we go. Let's get back to work."
Ben: We're a little bit at a crossroads, honestly. So the app is actually in a state where we feel pretty good about it. There's lots of things we want to improve about it of course. And that will always be true, but people are mostly happy with it. Once people get in and get activated and use it, the reviews and the responses have been really positive.
Ben: So now we're sort of stepping back and saying, "Okay. We have this really great pair programming, remote pairing app for Mac." We're starting to see this thing happen where people are on Twitter, saying nice things about us. And they'll be like, "Oh Tuple is really great. If you have a Mac, you should check it out."
Ben: And we're all just kind of like, "Dammit. I wonder if we could just be a great pairing app, just period." Just a great multi-platform and take on that complexity.
Erin: And would that mean having everything completely done in a web browser or you maybe don't know that yet?
Ben: I'm pretty sure it wouldn't, actually. So our app is a native app on macOS. It's actually written in C++ mostly plus a little bit of Swift. And we did that because we needed full control and we need speed; because if you're a remote pairing app, latency matters too much.
Ben: So we briefly sort of explored the Electron world and running it inside a browser and it just was a no go for us. So I think what we'd be looking at is two more native apps.
Ben: And so there's this sort of big question which is like, "When do we do this? I think eventually we do this for sure, but when do we want to take on that complexity? Because it's nice to expand our market a whole bunch and serve more customers and make them happy and take advantage of this opportunity in front of us. But now we have like, upping the complexity with a small team is kind of a bit dangerous I would say.
Erin: Yeah, that is a really, really interesting question to think about. So the three of you, I understand, are pretty close and you have an advisory team as well. So how do you think you'll go about making that decision?
Ben: Well, we asked our advisors about it and I would say the consensus was kind of like a wait. There's still plenty more to do in the Mac world. And I think that is a very reasonable answer.
Ben: Honestly, I think we're feeling a little more ambitious than that. I think we can handle... It's going to be hard. I don't think it's going to be easier than we expect. I think it will be harder than we expect.
Ben: But we all are feeling kind of like... When we first started the company we just wanted to get ramen profitable, keep it a kind of small and niche little business. And now we're sort of stepping back and saying "There appears to be a pretty big opportunity here."
Ben: There's not a ton of great remote pairing app competitors out there that we feel. I think we have a chance of becoming a really great answer to this problem across platforms. I think cross-platform is part of the part of the package there to really do it right.
Ben: I would say actually we've pretty much made the decision that we're going to do this. It's just a question of timing. So in the next couple of months we're going to be doing some sort of preparatory refactoring to make the code that we do have more portable so that we can start bringing it to other operating systems more easily when we do do that.
Erin: Got it, got it. So you're pretty well aligned on this one.
Ben: Yeah, fortunately, yeah. We actually have been very well aligned pretty consistently. It's weird how little conflict we have.
Erin: Well that's a bummer because I was going to ask you a very important question about disagreements between co-founders. Do you have anything to share in that regard or has it not really come up yet for you?
Ben: We take different positions on things. We argue different positions as sort of devil's advocate from time to time. And I would say occasionally we have different preferences but we haven't had like a, "No. We should definitely do this. I'm convinced that I'm right and you're wrong." And the other person feels the same way. We haven't had anything like that.
Ben: I think it's we're all kind of flexible people pleasers, probably. And so I think we're pretty good at resolving those conflicts. And we also have this idea that I love that we... I think it was an Amazon thing which is "Disagree and commit." Which is like, okay, I don't think this is the right thing but I'm going to get on board. I've said my peace so I'll commit and do the thing and go with the team and not be a pain about this.
Erin: Can you tell us a bit about... you don't have to get into the specifics, but how your team approached ownership of the legal entity that I'm sure is behind Tuple. I know this is a question that a lot of co-founders have. Should it always be even? If it's not even, what should the proportions be? How did you all have that conversation?
Ben: Yeah, it is. I think that's actually a little bit interesting. So I came to this with a fairly large audience from having done a lot of teaching and conference speaking and launching previous projects. So it felt pretty clear that in the early days I was going to be able to provide a decent kickstart to our sales efforts because of this audience.
Ben: And so there was sort of this like (I got this sort of sense from Spencer and Joel) that they were like, "Well, if you thought you should start with a little bit more equity that seems kind of reasonable because of this asset that you're bringing to the table."
Ben: But I thought on it for awhile and decided that it might be true that in the beginning I was bringing a bunch to the table, but it's not a short process to make a company work, and I expect that we will be working at it for years. And maybe today, I'm doing this useful thing, but then six months from now you're doing this useful thing.
Ben: I was concerned that there would just be this weird resentment that would build up over time and I would feel bad about it. And it sounded kind of a recipe for bad news. So at the end of the day we just went with equal partnerships and we've been happy with that.
Erin: So to wrap things up on my end and then I'd love to turn it over to you, I would to spend a couple minutes talking about Heroku, why you guys chose Heroku, what you do with Heroku and how it's working for you at the moment.
Ben: Yeah, so I have been a Heroku fan actually since my days at ThoughtBot, which is a Ruby and Rails consultancy. And it was the default answer that we would have for our clients because we were designers and developers and had no interest in doing dev-opsy type things. And so we would just point our customers or clients at that, and that generally just got the job done.
Ben: And I am just a huge fan of that. I still am not interested in worrying about servers and things like that and making sure backups happened or that that type of thing. So I've been a fan for a while, been a customer for a long time and when we spun this up it was pretty clear to me that was the call again.
Erin: Awesome. So as I mentioned, I'm on the Heroku support team and coincidentally I actually responded to a ticket that you had submitted at some point within the last few months. So that was really fun for this to come full circle.
Erin: Can you tell us a little bit, without giving too much of your proprietary information away, tell us how you're using Heroku? What features of Heroku are helping to power Tuple.
Ben: Hmm. It's actually a pretty simple setup. So the app is complicated in what it does, but the complication mostly comes in peer-to-peer variety. So when you're doing a pairing session, the app is connected to the other app and it mostly doesn't flow through any servers that we own.
Ben: So the thing that we host on Heroku is our backend; so how you sign up and bill and send invites and things like that. I would say the most complicated piece is probably we do maintain an ActionCable connection like a WebSocket connection to every client.
Ben: So we send down their friends list and like who's online and when someone calls you we need be able to push our message to somebody. So we do actually have currently thousands of people connecting simultaneously via WebSocket and getting updates all day long about who's coming online, who went offline and things like that.
Ben: So being able to, as we scale, host more Rails processes and also just like go kind of horizontally by adding more dynos has truly been really useful because after you get a certain number of WebSocket connections on one server, it gets a little bit not so happy.
Erin: And are you all doing anything in terms of data storage on Heroku?
Ben: Yeah. We use Postgres. We just upgraded to a beefier Postgres database. I love that the backups just happen or could be turned on with one command. That's amazing.
Ben: Or database maintenance. I get an email and it's, "Oh, your database was upgraded, something, something." I'm like, "Cool." I love that it's not a thing I have to think about.
Erin: I think that's it from me, Ben. I'd love to turn it over to you. Do you have anything that you'd like to share with our listeners?
Ben: Sure. I will just say one thing, which is that there's a big trend happening in our industry and that is people are working remotely a lot more. Sometimes that's full-time remote, like a fully distributed company and sometimes that's like a satellite office. Sometimes it's just like working from home a couple of days a week.
Ben: Remote is super, super on the rise. And overall, I think that is a super good thing. I'm for it. I like it and I do it myself and it's great.
Ben: But I also think that there's a bit of a danger in getting a little bit lonely and getting a little bit isolated, especially if you are full-time remote. It's hard to feel as connected to your co-workers. And so I do want to just pitch if people are... If you feel this or think you might be at risk for this pair programming I think is a really great tool to have in your toolbox to sort of combat this.
Ben: So I think the code that you write when you're pairing is a bit better, but even if it weren't, it's just kind of more fun to bring somebody onto your machine and do something together and tackle a problem together and to get that kind of high bandwidth voice communication. It reduces the bad parts of remote and lets you keep the good parts, I think.
Ben: So whether you use a tool like ours or not, kind of irrelevant, but if you're a developer and you're working remote, I think it'd be good to just make sure you have a little bit of remote pairing on your calendar every so often to keep you sane.
Erin: I definitely agree. I came across, I don't know if it was a blog post or a little, you know those pretty little quotes that they post on Instagram sometimes? It was some kind of text, and the person who put it together said that even though she was an introvert, she was looking back about all the times in the past that she felt really connected and joyful. It turns out that all of those times were times that she was with other people. Maybe strangers that she was meeting while traveling or family or friends who meant a lot to her.
Erin: I really identified with that because I am also an introvert and I also love when I get to get on video with my colleagues. Heroku is remote, like I said. And I could probably go days without talking to anyone. I know that's not healthy. I could do it if I had to, but getting to see and talk to my colleagues, who I genuinely like, once or twice a day. It's really cool. So I'm totally on board with that.
Ben: Awesome. Glad to hear it.
Erin: Thanks so much for joining us, Ben. How can listeners reach out to you online?
Ben: Twitter is probably best. I'm R00K. I'm on there probably too much. You can also email me at firstname.lastname@example.org if you'd like. And if you are a fan of podcasts, which I'm guessing you might be, I host a weekly podcast called "The Art of Product" where I talk with my cohost about the sort of day-to-day behind the scenes of running a software company.
Erin: And of course the website Tuple.app if they're interested in checking out Tuple.
Ben: That'd be great.
Erin: Thanks again, Ben. It's been really fun chatting with you.
Ben: My pleasure. I had a great time.
A podcast brought to you by the developer advocate team at Heroku, exploring code, technology, tools, tips, and the life of the developer.
Platform Support Engineer, Heroku
Erin is a Platform Support Engineer at Heroku and loves helping customers get their software projects and products out into the world.
More episodes from Code[ish]
Tobie Langel and Chris Castle
When you think about it, it's kind of miraculous how the web as we know it works as well as it does. No matter the device, browsers are able to render sites fairly accurately--even those built over twenty years ago. How this happened is no... →
Matt Pfaltzgraf, Brian Wetzel, and Julián Duque
More and more people are turning towards fundraising platforms as a way of contributing to the causes they care about. Softgiving is one such service which prides itself on working closely with influencers, pairing them with charities that... →
Doug Fawley and Robert Blumen
A Remote Procedure Call (RPC) is a protocol for communication between a client and a server, and, while it's not a new concept, Google has evolved the idea with their own version: gRPC. Learn more about gRPC from Doug Fawley, who is the tech... →