{"id":553,"date":"2020-04-29T17:46:00","date_gmt":"2020-04-29T14:46:00","guid":{"rendered":"https:\/\/arc.dev\/employer-blog\/?p=553"},"modified":"2025-06-11T12:55:40","modified_gmt":"2025-06-11T04:55:40","slug":"pair-programming-ama-ben-orenstein","status":"publish","type":"post","link":"https:\/\/arc.dev\/employer-blog\/pair-programming-ama-ben-orenstein\/","title":{"rendered":"All About Pair Programming: An AMA with Ben Orenstein of Tuple"},"content":{"rendered":"\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\"><p>Think about pair programming as a tool in your tool belt. Don\u2019t think of it as a religion you need to adopt or a crazy practice that needs to be spread around your team.<\/p><\/blockquote>\n\n\n\n<p>Welcome back! For this week\u2019s episode, we\u2019re going to replay our live AMA session with Ben Orenstein, co-founder and CEO of\u00a0<a href=\"https:\/\/tuple.app\/\" target=\"_blank\" rel=\"noreferrer noopener\">Tuple<\/a>!<\/p>\n\n\n\n<p>We covered a lot of grounds in this session, including the benefits of pair programming in remote teams, best practices in pairing, the ups and downs of running a bootstrapped startup, and more!<\/p>\n\n\n\n<p>You can also find a simplified version of the transcript below.<\/p>\n\n\n\n<p>If you\u2019ve enjoyed this episode, please consider leaving a review on\u00a0<a href=\"https:\/\/podcasts.apple.com\/us\/podcast\/outside-the-valley\/id1481937930\" target=\"_blank\" rel=\"noreferrer noopener\">iTunes<\/a>!<\/p>\n\n\n\n<p>The podcast is also available on your favourite players:\u00a0<a href=\"https:\/\/podcasts.apple.com\/us\/podcast\/outside-the-valley\/id1481937930?ign-mpt=uo%3D4\" target=\"_blank\" rel=\"noreferrer noopener\">iTunes<\/a>,\u00a0<a href=\"https:\/\/podcasts.google.com\/?feed=aHR0cHM6Ly9mZWVkcy50cmFuc2lzdG9yLmZtL291dHNpZGUtdGhlLXZhbGxleQ%3D%3D&hl=en-TW\" target=\"_blank\" rel=\"noreferrer noopener\">Google Podcast<\/a>,\u00a0<a href=\"https:\/\/castro.fm\/podcast\/5a2c6978-e8e7-4f02-a47d-ca3474778329\" target=\"_blank\" rel=\"noreferrer noopener\">Castro<\/a>,\u00a0<a href=\"https:\/\/overcast.fm\/itunes1481937930\/outside-the-valley\" target=\"_blank\" rel=\"noreferrer noopener\">Overcast<\/a>,\u00a0<a href=\"https:\/\/open.spotify.com\/show\/5qzXgcHzieXIRtXglSmUE8?si=rMPobXZtQwSU0wQ3grTAxA\" target=\"_blank\" rel=\"noreferrer noopener\">Spotify<\/a>,\u00a0<a href=\"https:\/\/www.stitcher.com\/podcast\/outside-the-valley\" target=\"_blank\" rel=\"noreferrer noopener\">Stitcher<\/a>,\u00a0<a href=\"https:\/\/player.fm\/series\/outside-the-valley\" target=\"_blank\" rel=\"noreferrer noopener\">Player.fm<\/a>, and\u00a0<a href=\"https:\/\/tunein.com\/podcasts\/Technology-Podcasts\/Outside-The-Valley-p1251704\/\" target=\"_blank\" rel=\"noreferrer noopener\">Tune In<\/a>.<\/p>\n\n\n\n<p>Follow us on\u00a0<a href=\"https:\/\/twitter.com\/arcdotdev\" target=\"_blank\" rel=\"noreferrer noopener\">Twitter<\/a>\u00a0to get updates.<\/p>\n\n\n\n<p><em>Looking for top talent fast? See how <\/em><a href=\"https:\/\/arc.dev\/\">Arc<\/a><em> can help you:<\/em><\/p>\n\n\n\n<p><em>\u26a1\ufe0f Find developers, designers, marketers, and more<br>\u26a1\ufe0f Freelance or full-time remote + fully vetted<\/em><em><br>\u26a1\ufe0f Save up to 80% with global hires<\/em><\/p>\n\n\n\n<p><a href=\"https:\/\/arc.dev\"><strong>Hire top talent with Arc risk-free \u2192<\/strong><\/a><\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"mentioned-resources%3A\">Mentioned resources:<\/h3>\n\n\n\n<ul class=\"wp-block-list\"><li><a href=\"https:\/\/tuple.app\/\" target=\"_blank\" rel=\"noreferrer noopener\">Tuple<\/a><\/li><li><a href=\"https:\/\/twitter.com\/r00k\" target=\"_blank\" rel=\"noreferrer noopener\">Ben\u2019s Twitter<\/a><\/li><li><a href=\"https:\/\/tuple.app\/pair-programming-guide\/how-to-pair-with-a-junior-developer\" target=\"_blank\" rel=\"noreferrer noopener\">How to pair with a junior developer<\/a><\/li><li><a href=\"http:\/\/basecamp.com\/\" target=\"_blank\" rel=\"noreferrer noopener\">Basecamp<\/a><\/li><li><a href=\"https:\/\/basecamp.com\/shapeup\" target=\"_blank\" rel=\"noreferrer noopener\">Shape Up<\/a><\/li><li><a href=\"https:\/\/themanagershandbook.com\/\" target=\"_blank\" rel=\"noreferrer noopener\">The Manager\u2019s Handbook<\/a><\/li><li><a href=\"http:\/\/clearbit.com\/\" target=\"_blank\" rel=\"noreferrer noopener\">Clearbit<\/a><\/li><li><a href=\"https:\/\/twitter.com\/maccaw\" target=\"_blank\" rel=\"noreferrer noopener\">Alex MacCaw<\/a><\/li><li><a href=\"https:\/\/en.wikipedia.org\/wiki\/Extreme_programming\" target=\"_blank\" rel=\"noreferrer noopener\">Extreme Programming<\/a><\/li><li><a href=\"https:\/\/tuple.app\/pair-programming-guide\" target=\"_blank\" rel=\"noreferrer noopener\">Learntopair.com<\/a><\/li><\/ul>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"simplified-transcript%3A\">Simplified transcript:<\/h3>\n\n\n\n<p><strong>Jovian:<\/strong>\u00a0And we are live. Hey, everyone. Thank you so much for joining us. My name is Jovian, your host for today and welcome to Arc\u2019s live webinar with Tuple, the best remote pair programming app on macOS that is also used by companies like Shopify, Basecamp, TaskRabbit, Intercom and more. So very excited to be joined by Ben Orenstein, the CEO and cofounder of Tuple. Ben, welcome.<\/p>\n\n\n\n<p><strong>Ben:<\/strong>\u00a0Thanks. Great to be here.<\/p>\n\n\n\n<p><strong>Jovian:<\/strong>\u00a0Super excited to have you here. In this webinar we are going to talk about how pair programming can level up your remote engineering team, actionable advice from Ben for engineering majors and engineers of teams who are already doing pair programming or looking to start adopting pairing into your product development and workflow. And we\u2019ll also chat a bit about Ben\u2019s and Tuple\u2019s startup journey so far.<\/p>\n\n\n\n<p>Before we start, we just wanna say we hope everybody\u2019s staying safe. We know some of you are under quarantine and hopefully this event will brighten up your day a bit. So here\u2019s how it goes. So we have prepared some questions for Ben. And this is also a live AMA by the way so if you have any questions for Ben, ask away on the chat box and we\u2019ll get into it.<\/p>\n\n\n\n<p>So without further ado, let\u2019s get rolling. So Ben, again, great to have you here today. So to kick things off:<\/p>\n\n\n\n<p><strong>Q: Can you please share a bit about your background and how Tuple came about?<\/strong><\/p>\n\n\n\n<p><strong>Ben:<\/strong>\u00a0Sure. My background is programming basically. So I think I\u2019ve been writing code professionally for something like 12 years now. I studied computer science in college. I was not a good student so I actually had a wandering career path after school. I did not graduate. So it took me a little while to break my way into the tech field. But eventually I did and got to start writing code for money which at the time felt like ridiculous to me. I felt like I was cheating. I was like, \u201cI get paid to do this? This is way too fun.\u201d<\/p>\n\n\n\n<p>But so yeah. I\u2019ve been writing code for a while now. The last good chunk of time has been mostly Ruby, writing Rails apps. And about two years ago I quit my job and along with two cofounders started Tuple which is a remote pair programming app and we did it because we didn\u2019t find any solutions out there for remote pairing that we liked.<\/p>\n\n\n\n<p>We had tried a bunch of options out there and I just kept noticing that I would ask friends, \u201cHey, what are you using for this?\u201d And there was not a great answer. And so it felt like, \u201cHey. Maybe if we focus on this particular use case, we can make something the developers will like better than like more generic screen sharing solutions.\u201d<\/p>\n\n\n\n<p><strong>Q: Do you see pair programming as even more important in remote teams?<\/strong><\/p>\n\n\n\n<p><strong>Ben:<\/strong>\u00a0Yeah. I would say it\u2019s probably more important. There\u2019s a lot of benefits to pairing but one of them that I think is particularly useful if you\u2019re a remote team is that it\u2019s less lonely. So there are times where it\u2019s fun to just like work by yourself and get really in the zone and crank out some code and I still love that.<\/p>\n\n\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\"><p>But if you\u2019re full time remote or distributed, it can get a little bit lonely. So it\u2019s nice to be able to pull somebody in and write some code and I think humans are pretty social by nature and we like collaborating on things.<\/p><\/blockquote>\n\n\n\n<p>Like maybe you\u2019re about to work on a piece of the app that you know is terrible to work on or you\u2019re super unfamiliar and often it\u2019s just really nice to be able to add another human to that.<\/p>\n\n\n\n<p><strong>Q: In what ways have you seen pair programming has helped teams, on every level, either they\u2019re early stage startups or even like 100 or a 1,000 people companies and how can pair programming help these companies?<\/strong><\/p>\n\n\n\n<p><strong>Ben:<\/strong>\u00a0Yeah, so I think there\u2019s sort of three benefits to the pair programming tool. So one is what I just touched on, just socially, I think it\u2019s nice. I think it makes it kinda more fun. It helps people feel more connected.<\/p>\n\n\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\"><p>The other is that it helps with sharing knowledge around the team. So there\u2019s knowledge of the application and I think most good companies want to spread that around so you don\u2019t have a single point of failure.<\/p><\/blockquote>\n\n\n\n<p>Like, how do the various pieces work? That happens very naturally as you pair on things. But also like knowledge of the meta stuff around programming.<\/p>\n\n\n\n<p>So I don\u2019t think I\u2019ve ever paired with someone and not learned something about how they write code, like an interesting macOS tip or something cool they did with Git that I didn\u2019t know you could do or some new Ruby method I had not seen before, so spreading that kind of programming skill stuff around along with the application knowledge.<\/p>\n\n\n\n<p>And then finally I think the code that you get when two people are writing it together is higher quality which helps you keep shipping quickly as time goes on.<\/p>\n\n\n\n<p><strong>Q: Why do you think the practice of pair programming has not yet been adopted more widely in the industry?<\/strong><\/p>\n\n\n\n<p><strong>Ben:<\/strong>\u00a0I think a major one is that there\u2019s a very easy to make argument against it which also I think happens to be wrong but it seems so logical on its face which is, \u201cSo you\u2019re telling me I\u2019m gonna have two programmers write the same code? Doesn\u2019t that mean I\u2019m gonna get half as much done?\u201d<\/p>\n\n\n\n<p>And the fact that that is such an easy, quick argument to make and it seems like it\u2019s right I think is probably like the biggest marketing problem that pair programming has or definitely one of the biggest.<\/p>\n\n\n\n<p>And the problem with that argument to me is that it sort of assumes the way you value the output of programmers is code. And I actually think that\u2019s the wrong mental model so\u2026<\/p>\n\n\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\"><p>Every time you sit down to write code, I think you\u2019re producing an asset and you\u2019re producing a liability. And the asset is problems solved for customers that they will pay you money for. And the liability is the code that\u2019s required to make that happen. So if I can make a million dollars a month off 100 lines of code, clearly that\u2019s better than making the same amount of money off a million lines of code, right?<\/p><\/blockquote>\n\n\n\n<p>If you agree with that, I think you have to kind of accept the premise that code is actually the cost that we pay in order to solve the problems for the customers. So saying, \u201cWon\u2019t two programmers together write half as much code when pairing?\u201d And the answer is, \u201cHopefully, they\u2019ll write even less.\u201d<\/p>\n\n\n\n<p>So I think that\u2019s probably the biggest thing. But there\u2019s more. There\u2019s other things and I\u2019ll respond to a couple of other things.<\/p>\n\n\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\"><p>So I think another marketing problem that pairing has is that people assume it\u2019s some mystical, difficult, weird practice. And like they\u2019re either into it or they\u2019re not.<\/p><\/blockquote>\n\n\n\n<p>And it\u2019s like religion and you have to kind of accept the pairing religion or you have to reject the pairing religion.<\/p>\n\n\n\n<p>And in reality, I think more programmers have paired than they think because if you\u2019ve ever said, \u201cHey, Jovian, can you look at this bug with me real quick? You wrote the user parser. Would you mind just taking a look at this?\u201d And then you like look at it together. Boom. Pair programming. You\u2019re doing it right there.<\/p>\n\n\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\"><p>It\u2019s just programmers working together on code. There\u2019s no special rules about who\u2019s typing, who\u2019s mousing, whose turn it is, how to switch. Like you can decide all of that for yourself depending on what works for you and what you like and the people that are involved and that\u2019s pair programming.<\/p><\/blockquote>\n\n\n\n<p>If there\u2019s a pair of you or more, great, you\u2019re pairing.<\/p>\n\n\n\n<p><strong>Jovian:<\/strong>\u00a0Right. I love what you say about the measuring the output of a programmer based on the lines of code. I think Bill Gates said something about this. Like using the lines of code as a measurement is like measuring an airplane performance based on its weight, like it doesn\u2019t make sense. And yeah. So I think it\u2019s also, in my opinion, like you mentioned pair programming is kinda hard to market, especially in the bigger companies, enterprises where you\u2019re dealing potentially with non-technical executives. But again, every job is a sales job as you go up.<\/p>\n\n\n\n<p><strong>Ben:<\/strong>\u00a0I think the idea of you needing to sell pairing to your management is sort of the wrong way of thinking about it. Like you probably wouldn\u2019t go and be like, \u201cWe need to get permission from management to see if I can pull someone over to my desk when I have a question.\u201d Right? That\u2019s\u2026no one would think that was rational and reasonable. And so I think this idea of, \u201cHold on, time out. We need to get permission to pair program,\u201d is just\u2026<\/p>\n\n\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\"><p>I feel like if you work in an organization that\u2019s micromanaging you at that level, the problem is the organization. It\u2019s not pair programming.<\/p><\/blockquote>\n\n\n\n<p><strong>Q: What advice do you have for teams who have not implemented a process but they\u2019re looking to start tomorrow? What are the actionable steps that they can do like assuming they already have their green light and they just can do it? What\u2019s the first one?<\/strong><\/p>\n\n\n\n<p><strong>Jovian:<\/strong>\u00a0First one is download Tuple, I guess. Install Tuple.<\/p>\n\n\n\n<p><strong>Ben:<\/strong>\u00a0I mean, sure. Tuple helps you if you\u2019re remote. It\u2019s a nice way to do it when you\u2019re remote but if you\u2019re in\u2026I mean you\u2019re probably not in person now but if you\u2019re in person you can sit down at the same desk.<\/p>\n\n\n\n<p>When I would pair at my last job, I would often bring my own keyboard and plug that in because it\u2019s nice to have. It\u2019s nice to just be able to type when you want.<\/p>\n\n\n\n<p>But again I think it\u2019s useful and I think of this as not a big deal like, \u201cOkay, here we go. We\u2019re gonna try pairing.\u201d It\u2019s like, \u201cAll right. How about you just sit down for five minutes with someone who wrote the code you\u2019re about to change and say can you just walk me through this real quick?\u201d<\/p>\n\n\n\n<p>And then they walk you through it and you say, \u201cOkay, so I\u2019m thinking about changing here and here.\u201d And they go, \u201cYep.\u201d You\u2019re like, \u201cGreat.\u201d<\/p>\n\n\n\n<p>And then they leave and, okay, you just paired. That\u2019s great. Congrats. It\u2019s no big deal. It\u2019s okay. It doesn\u2019t have to be scary.<\/p>\n\n\n\n<p>I mean, start small if it intimidates you.<\/p>\n\n\n\n<p>I will admit, the challenge of pairing I think is actually around the communication and the fact that you now have two humans trying to communicate with each other. And that is always challenging, right? That\u2019s always hard.<\/p>\n\n\n\n<p>It\u2019s easy to misunderstand each other. It\u2019s easy to have different communication styles, it\u2019s easy to accidentally offend someone and that\u2019s just true any time that people are communicating.<\/p>\n\n\n\n<p>So recognize that the burden for brain cycle spent on communicating and making sure someone understands you is higher. That\u2019s sort of the cost of pairing there.<\/p>\n\n\n\n<p>But beyond that, maybe just don\u2019t worry about it too much. Just try it and see how it goes.<\/p>\n\n\n\n<p><strong>Q: I want to switch gears a little bit here to the journey of Tuple itself. How big is Tuple right now?<\/strong><\/p>\n\n\n\n<p><strong>Ben:<\/strong>\u00a0So we have\u2026so I have two cofounders and the three of us are the only fulltime people and we currently have three part-time contractors working, two developers and one person in sales.<\/p>\n\n\n\n<p>*<em>Q: Got it. So now that you guys are growing, as the CEO and co-founder are there any particular things that you have started to think about now that you are hiring more remote team members? Have you started thinking about, oh, how to document stuff and the communication?*<\/em><\/p>\n\n\n\n<p><strong>Ben:<\/strong>\u00a0Yeah. We definitely are thinking about that a lot. Like a lot of companies right now, we\u2019re figuring out how to do this well.<\/p>\n\n\n\n<p>I don\u2019t think we do it super well to the point where I would feel like you should do it the way we\u2019re doing.<\/p>\n\n\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\"><p>I will say that one thing that I\u2019m having success with is trying to be a little bit more deliberate about writing things down in places where they kinda durably last like in a Wiki sort of thing.<\/p><\/blockquote>\n\n\n\n<p>Particularly as I get questions from the person who\u2019s helping us out with sales, I take that question, and then rather than answer the question wherever it happened I say, \u201cOh, I updated this Notion page with, you know\u2026on that topic.\u201d<\/p>\n\n\n\n<p>And this way, you know, training future people becomes easier. There\u2019s a place to check if you need it later. Writing it down has probably been the biggest meta habit I think that I\u2019ve seen benefit from.<\/p>\n\n\n\n<p><strong>Jovian:<\/strong>\u00a0Yeah. I think writing it down, like, the documentation culture has to come from the top up because I feel like it\u2019s not natural for humans to just write down stuff. It\u2019s easier to just chat or just go into like a quick Zoom meeting and whatnot. So yeah. Great approach you have there.<\/p>\n\n\n\n<p><strong>Q: Another thing that I want to talk about is about how do you approach hiring in general. How are you approaching this in general or any tips for other hiring managers or CEOs out there?<\/strong><\/p>\n\n\n\n<p><strong>Ben:<\/strong>\u00a0I don\u2019t know. I mean, so I\u2019ve hired three quarters of one full time person so far. And so I don\u2019t think I have a lot of great stuff to share there yet. I will point to a different resource actually that I think is good which is this thing called \u201cThe Manager\u2019s Handbook\u201d from Clearbit and they have a lot of really good detailed info on how to do that. And we\u2019re more or less trying to steal their playbook because they\u2019re at 100 something people and have thought about this a lot more deeply than we have.<\/p>\n\n\n\n<p><strong>Q: Any other best practices aside from pair programming for remote\u2026advice for remote engineering teams to collaborate and communicate better?<\/strong><\/p>\n\n\n\n<p><strong>Ben:<\/strong>\u00a0I mean, again, we\u2019re still figuring this out ourselves so I wouldn\u2019t point to us as a shining example. But I will share a lesson that I learned in a previous life and I learned it in the context of code reviews.<\/p>\n\n\n\n<p>Actually, like doing a code review, which is that when you move from in person communication to written communication, it\u2019s really easy to accidentally make someone feel like you\u2019re attacking them.<\/p>\n\n\n\n<p>Feedback\u2026so I noticed this in PR is where you could accidentally make it seem like you\u2019re\u2026as opposed to asking like, \u201cHey, why wasn\u2019t this method extracted?\u201d Someone can read that and say, \u201cWhy wasn\u2019t this method extracted, you idiot? Like how could you think that this was\u2026this belonged here?\u201d<\/p>\n\n\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\"><p>And it\u2019s a weird thing about brains that when we don\u2019t have a face and a tone to latch onto and to use to establish a context for what was said, it could often just go negative for some reason.<\/p><\/blockquote>\n\n\n\n<p>And so something I try to do in code review but then also just in written communication in general is to try to be almost like too smiley, exclamation-pointy, emoji friendly. You know, just too affable I guess because it\u2019s really, really easy to accidentally get mistaken in the other direction.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"audience-q%26a\">Audience Q&A<\/h3>\n\n\n\n<p><strong>Q: Any insights on initial project planning and brainstorming for remote teams?<\/strong><\/p>\n\n\n\n<p><strong>Ben:<\/strong>\u00a0That\u2019s a good question. I don\u2019t know if I have much to share there. I will say that we have read with interest and attempted Shape Up, the Shape Up process from Basecamp which I think is a really excellent resource on this.<\/p>\n\n\n\n<p>Even if you decide not to use their process, I think there\u2019s some interesting truths in that work and one of the central ones is that there\u2019s this work that has to happen before the work can start. And it\u2019s very easy for different people to misunderstand what the work is gonna be. So the work of understanding what the work is, is significant and can help prevent a lot of pain.<\/p>\n\n\n\n<p>I\u2019ve seen this happen at our company where I\u2019ll say\u2026like someone will say we should make it so users can edit their profile or something. And the person that says that is envisioning something and the person that hears that is envisioning something else and the disconnect is not discovered until work has been done, maybe time has been wasted, unfortunate decisions have been made perhaps.<\/p>\n\n\n\n<p>And so the Shape Up process recommends this explicit shaping step where someone figures out the answers to the questions and then writes a clear, high level, not totally prescriptive description of what the work is that needs to be done in order to help make sure everyone really understands what is this about, what are we trying to do here, what are the goals and what are the non-goals.<\/p>\n\n\n\n<p><strong>Q: Do you have any advice for the different types of pair programming, master-novice, novice-novice or master-master?<\/strong><\/p>\n\n\n\n<p><strong>Ben:<\/strong>\u00a0I actually did write a blog post about this or an article about this on our pairing guide called \u201cHow to pair with a junior developer\u201d and I think I also wrote the flip of that, the converse of that, like how to pair with someone more experienced than you.<\/p>\n\n\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\"><p>I would say the biggest thing if you\u2019re pairing with someone less experienced is probably to realize that they\u2019re probably a little bit nervous.<\/p><\/blockquote>\n\n\n\n<p>It\u2019s kinda natural for someone if they\u2019re pairing with someone who\u2019s got a lot more experience, they\u2019re gonna be a little bit more timid. They might need a little more time to think through things. And getting back to that communication misunderstandings, it\u2019s gonna be extra important for you to make it clear you\u2019re not frustrated with them or that they\u2019re taking too long.<\/p>\n\n\n\n<p>It\u2019s really easy to just kind of like brusquely shove aside someone who\u2019s thinking again like just type out the answer or make them feel underappreciated or judged or something. So be aware of that.<\/p>\n\n\n\n<p>As far as people pairing at the same level, I think that\u2019s less of a problem but still just be aware of that human tendency. Like it\u2019s just\u2026you\u2019re gonna have to devote more brain cycles than normal to making sure you\u2019re communicating well and establishing a good rapport with the person you\u2019re pairing with regardless of what your relative skill levels are.<\/p>\n\n\n\n<p><strong>Q: So two questions here that I feel like we can answer together. \u201cWhat are communication best practices while pairing?\u201d which is something that you have touched on just now. \u201cAnd when does pair programming become inefficient or less productive? You know, not learning and just arguing.\u201d So have you ever had this experience or even hear about the stories where pair programming just doesn\u2019t work?<\/strong><\/p>\n\n\n\n<p><strong>Ben:<\/strong>\u00a0Yeah. I think probably the failure mode you\u2019re most likely to accidentally fall into is one person programming and one person watching. So especially if you have a skill mismatch. So if you have like\u2026if the person driving is much more experienced or knows the code that\u2019s being edited or written much better, it\u2019s possible that you end up in a situation where the junior person is just kind of observing and acting maybe as a glorified typo checker.<\/p>\n\n\n\n<p>At that point that\u2019s you\u2019re not really pairing anymore. You just have an observer that\u2019s adding not that much value. I tend to recommend or I think it\u2019s usually a pretty good practice to switch who\u2019s driving somewhat regularly, like who actually has hands on the keyboard or the mouse and who\u2019s controlling things.<\/p>\n\n\n\n<p>And that way it becomes less likely that that one person checks out entirely or is just thinking about something else or is checking their email or something like that.<\/p>\n\n\n\n<p><strong>Q: I\u2019m on a small team, two junior devs, one senior. We\u2019re all working on different problems at the same time. How do you convince management to cut the number of problems the team is working on by 33%?<\/strong><\/p>\n\n\n\n<p><strong>Ben:<\/strong>\u00a0I think I understand the question though which is this idea that, okay, if we pair on this, we can only have at most like two things happening at once because there\u2019s two\u2026a pair and there\u2019s another\u2026a third person. So I would say start off by: don\u2019t ask. If on Monday you pair with me and on Tuesday I pair with you, then two people working together should go much faster than one person working alone. So there\u2019s this idea that if you take two programmers and put them on one problem, it gets\u2026you\u2019re getting sort of half as much done because they\u2019re working at the same speed they did before but that\u2019s definitely not true in my experience.<\/p>\n\n\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\"><p>It\u2019s really, really hard to block two people. And that I think is one of the big things that slows down development is where you get stuck and you don\u2019t know what\u2019s going on. You\u2019re like, \u201cThis should totally work. I\u2019m completely mystified as to how this is not working.\u201d And you spend time here googling, poking, debugging and you don\u2019t know what\u2019s going on. It\u2019s way harder.<\/p><\/blockquote>\n\n\n\n<p>It\u2019s more than twice as hard I think to block two people. And so what I find is when I\u2019m pairing, progress usually just kinda happens pretty continuously. It\u2019s almost like a linear progress towards the goal versus when I\u2019m pairing alone, I\u2019ll make a lot of progress and then I get stuck, stuck, stuck, stuck, stuck, stuck and then make a little progress and then get stuck.<\/p>\n\n\n\n<p>And so you may just find if you don\u2019t ask for permission and just say, \u201cHey, why don\u2019t you pair with me for an hour today and I\u2019ll pair with you for an hour tomorrow?\u201d You may actually find that you\u2019re getting even more done than before because people have different sets of knowledge.<\/p>\n\n\n\n<p>That\u2019s why I think it\u2019s harder to get blocked. There\u2019s two sets of eyes so it\u2019s easier to spot typos or silly mistakes. When someone is navigating as opposed to driving, they can be looking at documentation or spotting\u2026it\u2019s easier to spot problems and bugs when you\u2019re not actually typing the code.<\/p>\n\n\n\n<p>But then also people just have disparate knowledge. So it may just be that I understand this subsystem or this API a lot better than you do and so when an error happens then I can just get us unstuck right away.<\/p>\n\n\n\n<p>This just kind of occurred to me for a second. You probably wouldn\u2019t ask\u2026you almost certainly would not ask your manager for permission to use a new text editor. Right?<\/p>\n\n\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\"><p>Think about pair programming as a tool in your tool belt. Don\u2019t think of it as a religion you need to adopt or a crazy practice that needs to be spread around your team. Think of it like, \u201cThis is a thing I reach for when it makes sense to me and when I find it useful and in the amount that seems useful to me.\u201d<\/p><\/blockquote>\n\n\n\n<p>And so think of it less as a thing you would ask for permission for and just more a practice you might occasionally have that could be useful.<\/p>\n\n\n\n<p><strong>Q: You\u2019ve mentioned the social nature and sharing of knowledge as positive aspects of pair programming. What are some obstacles to look out for that might be getting in the way?<\/strong><\/p>\n\n\n\n<p><strong>Ben:<\/strong>\u00a0I mean, I think it\u2019s all the same problems of human communication that you\u2019re used to which is that it\u2019s easy to be misunderstood, it\u2019s easy to possibly offend somebody. If someone\u2019s sitting next to you, maybe you need to take a shower more often than you would otherwise or something. Like there\u2019s all these different human concerns that happen all of a sudden when you combine forces as opposed to working separately.<\/p>\n\n\n\n<p>I\u2019m not sure there\u2019s that much there that is programming specific. So if you\u2019re doing your communication best practices in the world and it can be really good. By the way, one way to help address these things if you work with people that are willing to give you feedback is ask for it.<\/p>\n\n\n\n<p>So at the end of a pairing session, a really good habit to get into is like, \u201cHow did that go? Like what were some\u2026what were a couple of good things and what were a couple of things that we could do better next time?\u201d And just try to solicit feedback explicitly and make that part of your process and then\u2026because there are some skills to be learned here and to some extent I think pairing is overcomplicated or sort of has a reputation of overcomplication but there are some things to learn that are more challenging than working alone. So asking for feedback or giving two-way feedback at the end of the session is probably a really good habit to get into.<\/p>\n\n\n\n<p><strong>Q: What lessons did you learn from your previous projects that you applied to Tuple as cofounder?<\/strong><\/p>\n\n\n\n<p><strong>Ben:<\/strong>\u00a0I mean, I don\u2019t know. Probably hundreds of them. It\u2019d be hard to really tease it apart. Like I think part of the reason Tuple has gone well is that I launched lots of smaller SaaS and products before this. So Tuple is not the first time I tried to charge money to people on the internet. I\u2019ve done this in a bunch of\u2026I\u2019ve launched a couple of SaaSs and a couple of one-off purchase products before this or actually a few of them, maybe three.<\/p>\n\n\n\n<p>So each time I think I got a little bit better and I learned a little bit more about it. Kind of too many lessons to summarize there but I guess the sort of bigger lesson there is if you do one day wanna start a software company, start other things now because SaaS is actually kind of the hardest business to grow, I think probably. It\u2019s hard to charge people\u2026like get people to sign up for subscriptions. That\u2019s challenging.<\/p>\n\n\n\n<p>It\u2019s hard to build the right thing code wise. That\u2019s also hard. So before\u2026think of SaaS kind of as running and think of trying to get like $5 from someone on the internet for something you made as like walking. Like what could you do that looks like that? Start there. Start like an eBook kind of thing.<\/p>\n\n\n\n<p><strong>Q: What are the biggest mistakes you\u2019ve made as a founder and as a manager? I think you\u2019ve touched a bit on the founder side but I wonder if you have anything on the manager side?<\/strong><\/p>\n\n\n\n<p><strong>Ben:<\/strong>\u00a0TBD kind of. Like I think my bigger mistakes are probably in front of me but I will say, and this is something I touched on, is that not\u2026almost every time that I think I and my cofounders agree on what\u2019s about to get built and how it will work and what it will look like but we don\u2019t write it down, there\u2019s a mismatch there. Basically every time I think, \u201cOkay, this feature is so small, I don\u2019t need to\u2026we don\u2019t need to write anything up. This is fine. Like you definitely understand what we\u2019re thinking.\u201d And then sometimes it\u2019d be like, \u201cWow, we still\u2026we actually\u2026we\u2019re still we\u2019re talking past each other.\u201d<\/p>\n\n\n\n<p>So I\u2019ve been surprised by the necessity for that to avoid, you know, unfortunately like wasted time or a code that needs to be rewritten.<\/p>\n\n\n\n<p><strong>Q: What is the product roadmap of Tuple? Could you share some new features we\u2019ll see in the near future?<\/strong><\/p>\n\n\n\n<p><strong>Ben:<\/strong>\u00a0Maybe. So I\u2019ve sort of\u2026I\u2019ve been burned by this a little bit before about talking about stuff that we\u2019re going to do because we are a startup and so a lot of the times the landscape changes out from under us. And so I think like, \u201cWe\u2019re gonna do X, Y, Z.\u201d And then something happens.<\/p>\n\n\n\n<p>Like as you can imagine, like the last month has completely upended the things that we thought were top priorities versus not. So I will sort of say that in the long term, we\u2019re interested in pushing the state of the art of remote pair programming forward. So we now have really high-quality screen share, an efficient application that doesn\u2019t burn your CPU, high quality audio, good latency. We\u2019ve sort of gotten the basics that we wanted to get in place. Like the\u2026you can use it as a pairing app and it works well for that and a lot of our customers find that it works better than other generic tools. So the initial sort of idea like, \u201cCould we make a business based on this idea?\u201d has been validated, it\u2019s working.<\/p>\n\n\n\n<p>Now it\u2019s like, to me the interesting thing is, what are the unsolved problems in doing pair programming remotely that no one has solved, that maybe people don\u2019t even really realize as a problem or that the world has never seen a good solution to? And so that\u2019s where my head is over the next handful of months and quarters. And we have\u2026we\u2019ve been doing some interesting explorations there and I think there\u2019s\u2026we have some good stuff in the pipeline that people will go, \u201cOh, nice. Like this is a pain point I had that I\u2019ve never seen anyone solve before.\u201d And that to me is like our greater mission. So that\u2019s kind of the big post.<\/p>\n\n\n\n<p>The other is that we\u2019re macOS only right now and it\u2019s a shame that you can\u2019t pair with people on Linux or Windows. And so long-term I think it\u2019s highly likely that we end up moving towards those platforms as well.<\/p>\n\n\n\n<p><strong>Q: How do you deal with different editor preferences, either different shortcuts or entirely different IDEs, headers? When you switch driver\/navigator, do you switch to the driver\u2019s machine?<\/strong><\/p>\n\n\n\n<p><strong>Ben:<\/strong>\u00a0Yeah, I think that\u2019s actually kind of a good way to do it is like, if I drove for 40 minutes and then we\u2019ll take a break and then maybe you drive for 40 minutes but let\u2019s just put it on your machine. You know, I\u2019ll push my changes, you pull them down. I\u2019m a big, big believer in customizing the crap out of your setup. Like my VIMRC is probably 1,000 lines long and I\u2019ve been working on it for\u2026like it\u2019s like literally a decade old. It\u2019s got like changes in there from like 10 years ago. So it would be unreasonable for me to expect that you could just drop in on my setup and feel very comfortable and it would be better if we can each work in our highly customized, super tuned environment, I think. So I like longer driving blocks followed by a break followed by swapping machines ideally.<\/p>\n\n\n\n<p><strong>Q: What are the biggest future trends you see affecting engineering in the next few years?<\/strong><\/p>\n\n\n\n<p><strong>Ben:<\/strong>\u00a0Well, controversial opinion but I think remote is perhaps gonna get and stay more popular. So like one of the reasons we chose Tuple of the business ideas we had was that we suspected that there would be more and more remote developers every year. There has been a dramatic acceleration in that trend for obvious reasons. I think that trend is here to stay.<\/p>\n\n\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\"><p>I think there are lots of people who, having experienced remote work will want to do it at least part-time in the future. So I think tools and processes and habits for supporting remote work are basically permanent now.<\/p><\/blockquote>\n\n\n\n<p>There\u2019s gonna be\u2026this is like I presume a brand-new concern that I think will always kinda be there.<\/p>\n\n\n\n<p>**Q: Tips for pair programming across a language barrier? My team is in Germany and Lithuania. Everyone speaks English but accents get confusing and the founder really struggles to communicate in English sometimes.<\/p>\n\n\n\n<p><strong>Ben:<\/strong>\u00a0I don\u2019t know. I actually haven\u2019t dealt with this particular problem. I would say hopefully you\u2019re using some tool that lets you have remote control because sometimes I find even among native speakers of the same language it\u2019s you end up dictating the code you want them to write which is like just an antipattern I think you should steer away from when pairing.<\/p>\n\n\n\n<p>Like if you\u2019re saying like, \u201cNo, less than. No, no, less than or equals. No, this thing. The capital A,\u201d than like\u2026 It\u2019s just better to just grab the keyboard for a second. Like hopefully you have remote control. Like, \u201cLet me show you what I mean.\u201d It\u2019s like tap, tap, tap, tap, tap and then it\u2019s a lot clearer. So that might be a good option for this. Like if you\u2019re having trouble being understood, have that other person grab control for a second and write the code that you\u2019re thinking of.<\/p>\n\n\n\n<p><strong>Jovian:<\/strong>\u00a0I feel like it\u2019s also the matter of fidelity. Like for example, I know in Tuple you also have like the whiteboarding option where you can do something. Am I correct?<\/p>\n\n\n\n<p><strong>Ben:<\/strong>\u00a0That\u2019s right, yep.<\/p>\n\n\n\n<p><strong>Jovian:<\/strong>\u00a0Yeah, so I think there\u2019s also like\u2026right, sorry.<\/p>\n\n\n\n<p><strong>Ben:<\/strong>\u00a0Well, yeah. We have basically a drawing feature. So you can paint on another person\u2019s screen. So sometimes like a little diagram is like the clearest way to explain like what\u2019s going on.<\/p>\n\n\n\n<p><strong>Jovian:<\/strong>\u00a0Yeah, so I feel like it\u2019s\u2026like just another channel or like where to increase the fidelity of communication, especially when you have a language barrier which is absolutely interesting.<\/p>\n\n\n\n<p><strong>Q: If you pair program continuously, do you feel there is still a value in code reviews?<\/strong><\/p>\n\n\n\n<p><strong>Ben:<\/strong>\u00a0Yeah, I like that question.<\/p>\n\n\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\"><p>I think you\u2019re pretty justified to skip a code review if the two people paired on a feature. And I think this is one of those lesser known benefits of pair programming.<\/p><\/blockquote>\n\n\n\n<p>So let\u2019s compare after the fact code review with pairing for a second. So if your team is, and this, by the way, if you are in a place where you have to make the argument for pairing, this might help you.<\/p>\n\n\n\n<p>If you are on a team that has already been sold on the value of code review which hopefully is a lot of them, you have someone write the code and then someone else has to come in after the fact and try to review the code.<\/p>\n\n\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\"><p>The problem is it\u2019s really hard to do good code review. It is a big, it\u2019s an interruption in your day. If you don\u2019t do it quickly, the person who wrote the code is blocked so you\u2019re holding up this feature from shipping.<\/p><\/blockquote>\n\n\n\n<p>And it\u2019s hard to do well in the best circumstances but it\u2019s particularly challenging because the thing you\u2019re seeing at the end is a finished artifact. It is the end result of problems that that person ran into along the way and decisions they made and ways they solved it. And a lot of that is not there in the final diff. So sometimes a code review is like, \u201cIs there a reason you didn\u2019t use this thing?\u201d And they go, \u201cYes, I tried that because X, Y, Z.\u201d Like, \u201cOh, but could you maybe do this?\u201d \u201cOh, no. Yeah, I tried that too and it just didn\u2019t work.\u201d<\/p>\n\n\n\n<p>And a lot of the context has to be reconstructed after the fact or the code review suffers. If I hand you a 1,000-line diff, you can maybe give me a good code review but it\u2019s gonna be hard, right. It\u2019s too much. It\u2019s overwhelming. It\u2019s gonna take me 45 minutes to load all the context into my head and understand what it used to look like, how it works now, is this a good thing, are we doing what we said we wanted to do. It\u2019s just super challenging.<\/p>\n\n\n\n<p>Versus if I wrote this code with you, then all of that context, all of the decisions I made along the way are automatically reviewed by two people. There\u2019s basically a continuous review happening and you have that subtle pressure of someone else writing this code with me, I should do it the right way. I think there\u2019s just this\u2026I think there\u2019s less tendency of\u2026so let\u2019s say you take a kind of ugly shortcut while you\u2019re writing code separately and then I see it in the PR and I\u2019m like, \u201cYou really shouldn\u2019t have done it this way but like I don\u2019t really wanna go make him rewrite this.\u201d<\/p>\n\n\n\n<p>There\u2019s this like, \u201cYou know you shouldn\u2019t have done it. I don\u2019t really want you to have done it but like between the two of us, it\u2019s gonna be hard to\u2026it\u2019s hard socially for me to ask you to go rewrite it. I feel bad.\u201d But if we\u2019re doing it together and when we reach that decision point like,<\/p>\n\n\n\n<p>\u201cOh, should I take the hacky thing or should I do it\u2026?\u201d Maybe you have a conversation and you say, \u201cWhat do you feel about the shortcut?\u201d And you go, \u201cWhy don\u2019t we just\u2026let\u2019s try it the other way for five minutes and see if we can get it.\u201d And then maybe you end up with a better product after that.<\/p>\n\n\n\n<p>I think most programmers really enjoy writing code and I think\u2026I would imagine that most programmers don\u2019t enjoy reviewing code nearly as much. Like I think of doing code review as kind of a necessary chore.<\/p>\n\n\n\n<p>So if you can swap a code review habit after the fact with a pairing habit, you\u2019re trading code review for more coding which to me as a programmer sounds more fun.<\/p>\n\n\n\n<p><strong>Q: How does Tuple handle different keyboard layouts? I\u2019ve had a lot of problems with other tools when my partner remotes into my machine and has a different keyboard layout.<\/strong><\/p>\n\n\n\n<p><strong>Ben:<\/strong>\u00a0This was like a month of work last year and then occasional fixups along the way. We started and we only supported US ASCII support and then we added international support and different layouts and all that.<\/p>\n\n\n\n<p>I didn\u2019t actually write this code so I don\u2019t actually know how it works under the hood but I do know that we have people using different languages, different layouts. I actually use the Dvorak keyboard layout so I\u2019m not a QWERTY user. And I can pair just fine with people using QWERTY. So there\u2019s basically a mapping layer that we do before we send the keystrokes over to figure out how we should model this thing on the other side. So it works, is the answer.<\/p>\n\n\n\n<p><strong>Q: How do you address insights after the code is written? Isn\u2019t there a different perspective after a code is written that an unbiased third-party could see?<\/strong><\/p>\n\n\n\n<p><strong>Ben:<\/strong>\u00a0Oh, sure. Yeah, yeah. I mean, if you wanna bring a third person in to review the code after two people have written it, yeah, you\u2019re definitely gonna end up with some insights and maybe better code as well. But keep in mind, now you\u2019re investing three people\u2019s time in the same bit of code. Would you write code by yourself and then have two people review it? Maybe, sure, yeah, that could be worth it depending on, you know, the calculus of your business and how bad an error is and how important is the code to be high quality and all these factors.<\/p>\n\n\n\n<p>If a pair wrote the code, I would tend to say, \u201cDon\u2019t add a third person as a code reviewer unless you think it\u2019s worth it.\u201d Like is this billing code? Is it particularly sensitive to errors? Maybe bring an extra set of eyes in there.<\/p>\n\n\n\n<p><strong>Q: How do you feel about mechanical refactoring commits such as extract method, etc.? I tend to make lots of tiny commits like that. It helps with the review because you have many small diffs instead of one huge commit.<\/strong><\/p>\n\n\n\n<p><strong>Ben:<\/strong>\u00a0I don\u2019t tend to like to look at individual commits during review. I would rather see\u2026 Personally, I tend to just look at the unified diff. I guess you can pull it out into commit by commit and see that. Maybe that\u2019s a good thing for your reviewers to use. I could see it. It does kind of help address the whole like, \u201cHere\u2019s a giant change. I don\u2019t know how to like parse it out,\u201d versus, \u201cHere\u2019s a commit that changes something small. Here\u2019s another commit that changes something small.\u201d That\u2019s kind of nice.<\/p>\n\n\n\n<p>One thing that I do\u2026 so I guess my answer to that is that that seems reasonable if it works for your reviewers and you. That seems like a totally legitimate way to go about it. One thing that I do like as a sort of tactic is the pre-refactoring commit or PR. So sometimes if I\u2019m about to make a change to some code, I\u2019ll say, \u201cOh, you know, this would be really easy if instead of this stuff being duplicated in three places, we had it extracted to whatever and there were only one place to change this.\u201d And so I\u2019ll actually do that refactoring and open it as a new PR just for the refactoring. Like no behavior change, just refactor. And then I\u2019ll start to branch off that PR or off that branch that actually implements my new changes. And so like the PR, the refactoring PR can get reviewed and merged and then my code can get reviewed and merged.<\/p>\n\n\n\n<p>And one great thing that falls out of that habit is that sometimes you\u2019ll do the refactoring and then in the interim priorities change and you decide not to do the new change to that code but you\u2019ve shipped like a nice refactoring that hopefully has tidied things up and made it easier to change in the future.<\/p>\n\n\n\n<p><strong>Q: In your own experience, can you handle as many hours of pair programming in one day as you are solo programming?<\/strong><\/p>\n\n\n\n<p><strong>Ben:<\/strong>\u00a0Great question. Definitely not. It is much more draining to pair program than to program alone. And it\u2019s like living with someone versus living by yourself or something. You now have this overhead, right, of another human. And so, you have more brain work to do, you have to think about where they\u2019re at and read their emotions and understand the communication between the two of you.<\/p>\n\n\n\n<p>And pairing definitely necessitates a higher level of communication. So that\u2019s more draining. And also, you\u2019re probably gonna work harder actually. If you block off two hours to pair with someone, you are not flipping over to your email. You\u2019re not jumping on Slack. You\u2019re not jumping on Twitter. You\u2019re probably just working except for explicit brakes for most of that time.<\/p>\n\n\n\n<p>And so it\u2019s a bit more draining to just work harder, and I do think that\u2019s one of the things that falls out of pairing is like it becomes socially a little uncomfortable to just like hop over to Twitter as soon as you get blocked by something or while you\u2019re waiting for something to build or tests to run or something like that.<\/p>\n\n\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\"><p>So I would plan. If you\u2019re newer to pairing, plan short sessions, maybe shorter than you would guess. And also just realize like four hours of pairing in a day is probably more draining than eight hours of programming by yourself.<\/p><\/blockquote>\n\n\n\n<p><strong>Q: So for Tuple, are you targeting one type of developer over another? For example, web versus game dev? And how does that affect your future map?<\/strong><\/p>\n\n\n\n<p><strong>Ben:<\/strong>\u00a0No. We\u2019re pretty agnostic on what kind of programming you do because we share the whole desktop and with the remote control. So it doesn\u2019t matter if you have a terminal, it doesn\u2019t matter what editor you\u2019re using, what tools you\u2019re using, are you in the browser, are you in the terminal, are you using Sketch. We\u2019re agnostic as to what\u2019s on the screen and how you\u2019re using it. So we optimize for things that technical people tend to care about, programmers in particular. But beyond that, we don\u2019t say \u201cOh, this is better for web devs or something.\u201d<\/p>\n\n\n\n<p><strong>Q: Saw a Shopify engineer on your website that is a customer. Any interesting case study you can share?<\/strong><\/p>\n\n\n\n<p><strong>Ben:<\/strong>\u00a0This is sort of on my list of things to do for the company. It\u2019s like actually right up like experience report. I can share one data point which is that we surveyed our customers at one point and we said, \u201cDo you think that adopting Tuple increased the amount of pairing you did?\u201d And 71% of them said yes. So in aggregate it does seem like we\u2019re working\u2026we\u2019re like effectively increasing the amount of pairing. So if you buy the argument that pairing is good and more is better, then it seems like the\u2026as a group, it\u2019s kind of working.<\/p>\n\n\n\n<p><strong>Q: Any experience pairing with non devs instead of in the thing actually?<\/strong><\/p>\n\n\n\n<p><strong>Ben:<\/strong>\u00a0Pair with non devs? So I\u2019ve paired with designers before which actually was a really cool experience. So like combining writing the back-end code with also like doing some of the front-end work.<\/p>\n\n\n\n<p>But it\u2019s been pretty rare. I think like I can only think I\u2019ve done that like maybe two or three times. Also occasionally doing like a screen share, not really pairing anymore but just showing something to a stakeholder is totally, you know, a normal part of the process where it\u2019s like, \u201cHey, this is what we have so far. Does this look right to you?\u201d Not quite pairing but the same idea.<\/p>\n\n\n\n<p><strong>Q: Where can people learn more about your journey and Tuple and what\u2019s next for the company?<\/strong><\/p>\n\n\n\n<p><strong>Ben:<\/strong>\u00a0The best answer to that is probably my podcast. So I host a more or less weekly podcast. And I talk about what\u2019s going on in the company and what our thoughts are week to week. So if you\u2019re interested in the nitty-gritty of running a software company, that\u2019s probably the best bet. And that is at artofproductpodcast.com. The podcast is called \u201cThe Art of Product\u201d.<\/p>\n\n\n\n<p><strong>Jovian:<\/strong>\u00a0Ben, thank you so much for your time today. I really learned a lot. And yeah.<\/p>\n\n\n\n<p><strong>Ben:<\/strong>\u00a0My pleasure. Thanks for having me.<\/p>\n\n\n\n<p><em>You can also try <\/em><a href=\"https:\/\/arc.dev\/\">Arc<\/a><em>, your<\/em><em> shortcut to the world\u2019s best remote talent:<\/em><\/p>\n\n\n\n<p><em>\u26a1\ufe0f Access 450,000 top developers, designers, and marketers <br>\u26a1\ufe0f <em>Vetted and ready to interview<\/em><br>\u26a1\ufe0f Freelance or full-time<\/em><\/p>\n\n\n\n<p><a href=\"https:\/\/arc.dev\"><\/a><a href=\"https:\/\/arc.dev\"><strong>Try Arc and hire top talent now \u2192<\/strong><\/a><\/p>\n","protected":false},"excerpt":{"rendered":"<p>Ben Orenstein from Tuple talked about pair programming, running a bootstrapped company, and more in this Q&#038;A session.<\/p>\n","protected":false},"author":4,"featured_media":555,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[18],"tags":[],"class_list":["post-553","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-thought-leadership"],"yoast_head":"<!-- This site is optimized with the Yoast SEO plugin v27.6 - https:\/\/yoast.com\/product\/yoast-seo-wordpress\/ -->\n<title>All About Pair Programming: An AMA with Ben Orenstein of Tuple<\/title>\n<meta name=\"description\" content=\"Ben Orenstein from Tuple talked about pair programming, running a bootstrapped company, and more in this Q&amp;A session.\" \/>\n<meta name=\"robots\" content=\"noindex, nofollow\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"All About Pair Programming: An AMA with Ben Orenstein of Tuple\" \/>\n<meta property=\"og:description\" content=\"Ben Orenstein from Tuple talked about pair programming, running a bootstrapped company, and more in this Q&amp;A session.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/arc.dev\/employer-blog\/pair-programming-ama-ben-orenstein\/\" \/>\n<meta property=\"og:site_name\" content=\"Arc Employer Blog\" \/>\n<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/arcdotdev\" \/>\n<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/arcdotdev\" \/>\n<meta property=\"article:published_time\" content=\"2020-04-29T14:46:00+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2025-06-11T04:55:40+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/arc.dev\/employer-blog\/wp-content\/uploads\/2020\/04\/ben-orenstein-pair-programming.png\" \/>\n\t<meta property=\"og:image:width\" content=\"996\" \/>\n\t<meta property=\"og:image:height\" content=\"556\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/png\" \/>\n<meta name=\"author\" content=\"Arc Team\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:creator\" content=\"@arcdotdev\" \/>\n<meta name=\"twitter:site\" content=\"@arcdotdev\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Arc Team\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"35 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\\\/\\\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\\\/\\\/arc.dev\\\/employer-blog\\\/pair-programming-ama-ben-orenstein\\\/#article\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/arc.dev\\\/employer-blog\\\/pair-programming-ama-ben-orenstein\\\/\"},\"author\":{\"name\":\"Arc Team\",\"@id\":\"https:\\\/\\\/arc.dev\\\/employer-blog\\\/#\\\/schema\\\/person\\\/534b43ea0aa8f80095964abb1228a38f\"},\"headline\":\"All About Pair Programming: An AMA with Ben Orenstein of Tuple\",\"datePublished\":\"2020-04-29T14:46:00+00:00\",\"dateModified\":\"2025-06-11T04:55:40+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\\\/\\\/arc.dev\\\/employer-blog\\\/pair-programming-ama-ben-orenstein\\\/\"},\"wordCount\":8009,\"publisher\":{\"@id\":\"https:\\\/\\\/arc.dev\\\/employer-blog\\\/#organization\"},\"image\":{\"@id\":\"https:\\\/\\\/arc.dev\\\/employer-blog\\\/pair-programming-ama-ben-orenstein\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/arc.dev\\\/employer-blog\\\/wp-content\\\/uploads\\\/2020\\\/04\\\/ben-orenstein-pair-programming.png\",\"articleSection\":[\"Thought Leadership\"],\"inLanguage\":\"en-US\"},{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/arc.dev\\\/employer-blog\\\/pair-programming-ama-ben-orenstein\\\/\",\"url\":\"https:\\\/\\\/arc.dev\\\/employer-blog\\\/pair-programming-ama-ben-orenstein\\\/\",\"name\":\"All About Pair Programming: An AMA with Ben Orenstein of Tuple\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/arc.dev\\\/employer-blog\\\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\\\/\\\/arc.dev\\\/employer-blog\\\/pair-programming-ama-ben-orenstein\\\/#primaryimage\"},\"image\":{\"@id\":\"https:\\\/\\\/arc.dev\\\/employer-blog\\\/pair-programming-ama-ben-orenstein\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/arc.dev\\\/employer-blog\\\/wp-content\\\/uploads\\\/2020\\\/04\\\/ben-orenstein-pair-programming.png\",\"datePublished\":\"2020-04-29T14:46:00+00:00\",\"dateModified\":\"2025-06-11T04:55:40+00:00\",\"description\":\"Ben Orenstein from Tuple talked about pair programming, running a bootstrapped company, and more in this Q&A session.\",\"breadcrumb\":{\"@id\":\"https:\\\/\\\/arc.dev\\\/employer-blog\\\/pair-programming-ama-ben-orenstein\\\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/arc.dev\\\/employer-blog\\\/pair-programming-ama-ben-orenstein\\\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/arc.dev\\\/employer-blog\\\/pair-programming-ama-ben-orenstein\\\/#primaryimage\",\"url\":\"https:\\\/\\\/arc.dev\\\/employer-blog\\\/wp-content\\\/uploads\\\/2020\\\/04\\\/ben-orenstein-pair-programming.png\",\"contentUrl\":\"https:\\\/\\\/arc.dev\\\/employer-blog\\\/wp-content\\\/uploads\\\/2020\\\/04\\\/ben-orenstein-pair-programming.png\",\"width\":996,\"height\":556,\"caption\":\"ben orenstein pair programming podcast episode\"},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\\\/\\\/arc.dev\\\/employer-blog\\\/pair-programming-ama-ben-orenstein\\\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\\\/\\\/arc.dev\\\/employer-blog\\\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"All About Pair Programming: An AMA with Ben Orenstein of Tuple\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\\\/\\\/arc.dev\\\/employer-blog\\\/#website\",\"url\":\"https:\\\/\\\/arc.dev\\\/employer-blog\\\/\",\"name\":\"Arc Employer Blog\",\"description\":\"Insights on hiring and remote work\",\"publisher\":{\"@id\":\"https:\\\/\\\/arc.dev\\\/employer-blog\\\/#organization\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\\\/\\\/arc.dev\\\/employer-blog\\\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Organization\",\"@id\":\"https:\\\/\\\/arc.dev\\\/employer-blog\\\/#organization\",\"name\":\"Arc.dev\",\"url\":\"https:\\\/\\\/arc.dev\\\/employer-blog\\\/\",\"logo\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/arc.dev\\\/employer-blog\\\/#\\\/schema\\\/logo\\\/image\\\/\",\"url\":\"https:\\\/\\\/arc.dev\\\/employer-blog\\\/wp-content\\\/uploads\\\/2022\\\/02\\\/Arc-alternate-logo.png\",\"contentUrl\":\"https:\\\/\\\/arc.dev\\\/employer-blog\\\/wp-content\\\/uploads\\\/2022\\\/02\\\/Arc-alternate-logo.png\",\"width\":512,\"height\":512,\"caption\":\"Arc.dev\"},\"image\":{\"@id\":\"https:\\\/\\\/arc.dev\\\/employer-blog\\\/#\\\/schema\\\/logo\\\/image\\\/\"},\"sameAs\":[\"https:\\\/\\\/www.facebook.com\\\/arcdotdev\",\"https:\\\/\\\/x.com\\\/arcdotdev\",\"https:\\\/\\\/www.instagram.com\\\/arcdotdev\\\/\",\"https:\\\/\\\/www.linkedin.com\\\/company\\\/arcdotdev\",\"https:\\\/\\\/www.youtube.com\\\/c\\\/Arcdotdev\"]},{\"@type\":\"Person\",\"@id\":\"https:\\\/\\\/arc.dev\\\/employer-blog\\\/#\\\/schema\\\/person\\\/534b43ea0aa8f80095964abb1228a38f\",\"name\":\"Arc Team\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/a0ede409fa33fc8968402c9e39b820b22e501e28ec7700d038eedfc80652d3aa?s=96&d=mm&r=pg\",\"url\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/a0ede409fa33fc8968402c9e39b820b22e501e28ec7700d038eedfc80652d3aa?s=96&d=mm&r=pg\",\"contentUrl\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/a0ede409fa33fc8968402c9e39b820b22e501e28ec7700d038eedfc80652d3aa?s=96&d=mm&r=pg\",\"caption\":\"Arc Team\"},\"description\":\"The Arc team provides articles and expert advice on tech careers and remote work. From helping beginners land their first junior role to supporting remote workers facing challenges at home or guiding mid-level professionals toward leadership, Arc covers it all!\",\"sameAs\":[\"https:\\\/\\\/arc.dev\\\/developer-blog\\\/\",\"https:\\\/\\\/www.facebook.com\\\/arcdotdev\",\"https:\\\/\\\/www.instagram.com\\\/arcdotdev\\\/\",\"https:\\\/\\\/www.linkedin.com\\\/company\\\/arcdotdev\",\"https:\\\/\\\/x.com\\\/arcdotdev\",\"https:\\\/\\\/www.youtube.com\\\/c\\\/Arcdotdev\"],\"url\":\"https:\\\/\\\/arc.dev\\\/employer-blog\\\/author\\\/arcteam\\\/\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"All About Pair Programming: An AMA with Ben Orenstein of Tuple","description":"Ben Orenstein from Tuple talked about pair programming, running a bootstrapped company, and more in this Q&A session.","robots":{"index":"noindex","follow":"nofollow"},"og_locale":"en_US","og_type":"article","og_title":"All About Pair Programming: An AMA with Ben Orenstein of Tuple","og_description":"Ben Orenstein from Tuple talked about pair programming, running a bootstrapped company, and more in this Q&A session.","og_url":"https:\/\/arc.dev\/employer-blog\/pair-programming-ama-ben-orenstein\/","og_site_name":"Arc Employer Blog","article_publisher":"https:\/\/www.facebook.com\/arcdotdev","article_author":"https:\/\/www.facebook.com\/arcdotdev","article_published_time":"2020-04-29T14:46:00+00:00","article_modified_time":"2025-06-11T04:55:40+00:00","og_image":[{"width":996,"height":556,"url":"https:\/\/arc.dev\/employer-blog\/wp-content\/uploads\/2020\/04\/ben-orenstein-pair-programming.png","type":"image\/png"}],"author":"Arc Team","twitter_card":"summary_large_image","twitter_creator":"@arcdotdev","twitter_site":"@arcdotdev","twitter_misc":{"Written by":"Arc Team","Est. reading time":"35 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/arc.dev\/employer-blog\/pair-programming-ama-ben-orenstein\/#article","isPartOf":{"@id":"https:\/\/arc.dev\/employer-blog\/pair-programming-ama-ben-orenstein\/"},"author":{"name":"Arc Team","@id":"https:\/\/arc.dev\/employer-blog\/#\/schema\/person\/534b43ea0aa8f80095964abb1228a38f"},"headline":"All About Pair Programming: An AMA with Ben Orenstein of Tuple","datePublished":"2020-04-29T14:46:00+00:00","dateModified":"2025-06-11T04:55:40+00:00","mainEntityOfPage":{"@id":"https:\/\/arc.dev\/employer-blog\/pair-programming-ama-ben-orenstein\/"},"wordCount":8009,"publisher":{"@id":"https:\/\/arc.dev\/employer-blog\/#organization"},"image":{"@id":"https:\/\/arc.dev\/employer-blog\/pair-programming-ama-ben-orenstein\/#primaryimage"},"thumbnailUrl":"https:\/\/arc.dev\/employer-blog\/wp-content\/uploads\/2020\/04\/ben-orenstein-pair-programming.png","articleSection":["Thought Leadership"],"inLanguage":"en-US"},{"@type":"WebPage","@id":"https:\/\/arc.dev\/employer-blog\/pair-programming-ama-ben-orenstein\/","url":"https:\/\/arc.dev\/employer-blog\/pair-programming-ama-ben-orenstein\/","name":"All About Pair Programming: An AMA with Ben Orenstein of Tuple","isPartOf":{"@id":"https:\/\/arc.dev\/employer-blog\/#website"},"primaryImageOfPage":{"@id":"https:\/\/arc.dev\/employer-blog\/pair-programming-ama-ben-orenstein\/#primaryimage"},"image":{"@id":"https:\/\/arc.dev\/employer-blog\/pair-programming-ama-ben-orenstein\/#primaryimage"},"thumbnailUrl":"https:\/\/arc.dev\/employer-blog\/wp-content\/uploads\/2020\/04\/ben-orenstein-pair-programming.png","datePublished":"2020-04-29T14:46:00+00:00","dateModified":"2025-06-11T04:55:40+00:00","description":"Ben Orenstein from Tuple talked about pair programming, running a bootstrapped company, and more in this Q&A session.","breadcrumb":{"@id":"https:\/\/arc.dev\/employer-blog\/pair-programming-ama-ben-orenstein\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/arc.dev\/employer-blog\/pair-programming-ama-ben-orenstein\/"]}]},{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/arc.dev\/employer-blog\/pair-programming-ama-ben-orenstein\/#primaryimage","url":"https:\/\/arc.dev\/employer-blog\/wp-content\/uploads\/2020\/04\/ben-orenstein-pair-programming.png","contentUrl":"https:\/\/arc.dev\/employer-blog\/wp-content\/uploads\/2020\/04\/ben-orenstein-pair-programming.png","width":996,"height":556,"caption":"ben orenstein pair programming podcast episode"},{"@type":"BreadcrumbList","@id":"https:\/\/arc.dev\/employer-blog\/pair-programming-ama-ben-orenstein\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/arc.dev\/employer-blog\/"},{"@type":"ListItem","position":2,"name":"All About Pair Programming: An AMA with Ben Orenstein of Tuple"}]},{"@type":"WebSite","@id":"https:\/\/arc.dev\/employer-blog\/#website","url":"https:\/\/arc.dev\/employer-blog\/","name":"Arc Employer Blog","description":"Insights on hiring and remote work","publisher":{"@id":"https:\/\/arc.dev\/employer-blog\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/arc.dev\/employer-blog\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Organization","@id":"https:\/\/arc.dev\/employer-blog\/#organization","name":"Arc.dev","url":"https:\/\/arc.dev\/employer-blog\/","logo":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/arc.dev\/employer-blog\/#\/schema\/logo\/image\/","url":"https:\/\/arc.dev\/employer-blog\/wp-content\/uploads\/2022\/02\/Arc-alternate-logo.png","contentUrl":"https:\/\/arc.dev\/employer-blog\/wp-content\/uploads\/2022\/02\/Arc-alternate-logo.png","width":512,"height":512,"caption":"Arc.dev"},"image":{"@id":"https:\/\/arc.dev\/employer-blog\/#\/schema\/logo\/image\/"},"sameAs":["https:\/\/www.facebook.com\/arcdotdev","https:\/\/x.com\/arcdotdev","https:\/\/www.instagram.com\/arcdotdev\/","https:\/\/www.linkedin.com\/company\/arcdotdev","https:\/\/www.youtube.com\/c\/Arcdotdev"]},{"@type":"Person","@id":"https:\/\/arc.dev\/employer-blog\/#\/schema\/person\/534b43ea0aa8f80095964abb1228a38f","name":"Arc Team","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/secure.gravatar.com\/avatar\/a0ede409fa33fc8968402c9e39b820b22e501e28ec7700d038eedfc80652d3aa?s=96&d=mm&r=pg","url":"https:\/\/secure.gravatar.com\/avatar\/a0ede409fa33fc8968402c9e39b820b22e501e28ec7700d038eedfc80652d3aa?s=96&d=mm&r=pg","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/a0ede409fa33fc8968402c9e39b820b22e501e28ec7700d038eedfc80652d3aa?s=96&d=mm&r=pg","caption":"Arc Team"},"description":"The Arc team provides articles and expert advice on tech careers and remote work. From helping beginners land their first junior role to supporting remote workers facing challenges at home or guiding mid-level professionals toward leadership, Arc covers it all!","sameAs":["https:\/\/arc.dev\/developer-blog\/","https:\/\/www.facebook.com\/arcdotdev","https:\/\/www.instagram.com\/arcdotdev\/","https:\/\/www.linkedin.com\/company\/arcdotdev","https:\/\/x.com\/arcdotdev","https:\/\/www.youtube.com\/c\/Arcdotdev"],"url":"https:\/\/arc.dev\/employer-blog\/author\/arcteam\/"}]}},"_links":{"self":[{"href":"https:\/\/arc.dev\/employer-blog\/wp-json\/wp\/v2\/posts\/553","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/arc.dev\/employer-blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/arc.dev\/employer-blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/arc.dev\/employer-blog\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/arc.dev\/employer-blog\/wp-json\/wp\/v2\/comments?post=553"}],"version-history":[{"count":0,"href":"https:\/\/arc.dev\/employer-blog\/wp-json\/wp\/v2\/posts\/553\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/arc.dev\/employer-blog\/wp-json\/wp\/v2\/media\/555"}],"wp:attachment":[{"href":"https:\/\/arc.dev\/employer-blog\/wp-json\/wp\/v2\/media?parent=553"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/arc.dev\/employer-blog\/wp-json\/wp\/v2\/categories?post=553"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/arc.dev\/employer-blog\/wp-json\/wp\/v2\/tags?post=553"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}