Think about pair programming as a tool in your tool belt. Don’t think of it as a religion you need to adopt or a crazy practice that needs to be spread around your team.
Welcome back! For this week’s episode, we’re going to replay our live AMA session with Ben Orenstein, co-founder and CEO of Tuple!
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!
You can also find a simplified version of the transcript below.
If you’ve enjoyed this episode, please consider leaving a review on iTunes!
The podcast is also available on your favourite players: iTunes, Google Podcast, Castro, Overcast, Spotify, Stitcher, Player.fm, and Tune In.
Follow us on Twitter to get updates.
Looking to hire the best remote talent? See how Arc can help you:
⚡️ Find the world’s top developers, designers, and marketers
⚡️ Hire 4x faster with fully vetted candidates
⚡️ Save up to 58% with global hires
Hire top talent with Arc risk-free →
Mentioned resources:
- Tuple
- Ben’s Twitter
- How to pair with a junior developer
- Basecamp
- Shape Up
- The Manager’s Handbook
- Clearbit
- Alex MacCaw
- Extreme Programming
- Learntopair.com
Simplified transcript:
Jovian: And we are live. Hey, everyone. Thank you so much for joining us. My name is Jovian, your host for today and welcome to Arc’s 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.
Ben: Thanks. Great to be here.
Jovian: Super 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’ll also chat a bit about Ben’s and Tuple’s startup journey so far.
Before we start, we just wanna say we hope everybody’s staying safe. We know some of you are under quarantine and hopefully this event will brighten up your day a bit. So here’s 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’ll get into it.
So without further ado, let’s get rolling. So Ben, again, great to have you here today. So to kick things off:
Q: Can you please share a bit about your background and how Tuple came about?
Ben: Sure. My background is programming basically. So I think I’ve 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, “I get paid to do this? This is way too fun.”
But so yeah. I’ve 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’t find any solutions out there for remote pairing that we liked.
We had tried a bunch of options out there and I just kept noticing that I would ask friends, “Hey, what are you using for this?” And there was not a great answer. And so it felt like, “Hey. 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.”
Q: Do you see pair programming as even more important in remote teams?
Ben: Yeah. I would say it’s probably more important. There’s a lot of benefits to pairing but one of them that I think is particularly useful if you’re a remote team is that it’s less lonely. So there are times where it’s fun to just like work by yourself and get really in the zone and crank out some code and I still love that.
But if you’re full time remote or distributed, it can get a little bit lonely. So it’s 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.
Like maybe you’re about to work on a piece of the app that you know is terrible to work on or you’re super unfamiliar and often it’s just really nice to be able to add another human to that.
Q: In what ways have you seen pair programming has helped teams, on every level, either they’re early stage startups or even like 100 or a 1,000 people companies and how can pair programming help these companies?
Ben: Yeah, so I think there’s sort of three benefits to the pair programming tool. So one is what I just touched on, just socially, I think it’s nice. I think it makes it kinda more fun. It helps people feel more connected.
The other is that it helps with sharing knowledge around the team. So there’s knowledge of the application and I think most good companies want to spread that around so you don’t have a single point of failure.
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.
So I don’t think I’ve 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’t 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.
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.
Q: Why do you think the practice of pair programming has not yet been adopted more widely in the industry?
Ben: I think a major one is that there’s 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, “So you’re telling me I’m gonna have two programmers write the same code? Doesn’t that mean I’m gonna get half as much done?”
And the fact that that is such an easy, quick argument to make and it seems like it’s right I think is probably like the biggest marketing problem that pair programming has or definitely one of the biggest.
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’s the wrong mental model so…
Every time you sit down to write code, I think you’re producing an asset and you’re 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’s required to make that happen. So if I can make a million dollars a month off 100 lines of code, clearly that’s better than making the same amount of money off a million lines of code, right?
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, “Won’t two programmers together write half as much code when pairing?” And the answer is, “Hopefully, they’ll write even less.”
So I think that’s probably the biggest thing. But there’s more. There’s other things and I’ll respond to a couple of other things.
So I think another marketing problem that pairing has is that people assume it’s some mystical, difficult, weird practice. And like they’re either into it or they’re not.
And it’s like religion and you have to kind of accept the pairing religion or you have to reject the pairing religion.
And in reality, I think more programmers have paired than they think because if you’ve ever said, “Hey, 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?” And then you like look at it together. Boom. Pair programming. You’re doing it right there.
It’s just programmers working together on code. There’s no special rules about who’s typing, who’s 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’s pair programming.
If there’s a pair of you or more, great, you’re pairing.
Jovian: Right. 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’t make sense. And yeah. So I think it’s also, in my opinion, like you mentioned pair programming is kinda hard to market, especially in the bigger companies, enterprises where you’re dealing potentially with non-technical executives. But again, every job is a sales job as you go up.
Ben: I 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’t go and be like, “We need to get permission from management to see if I can pull someone over to my desk when I have a question.” Right? That’s…no one would think that was rational and reasonable. And so I think this idea of, “Hold on, time out. We need to get permission to pair program,” is just…
I feel like if you work in an organization that’s micromanaging you at that level, the problem is the organization. It’s not pair programming.
Q: What advice do you have for teams who have not implemented a process but they’re 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’s the first one?
Jovian: First one is download Tuple, I guess. Install Tuple.
Ben: I mean, sure. Tuple helps you if you’re remote. It’s a nice way to do it when you’re remote but if you’re in…I mean you’re probably not in person now but if you’re in person you can sit down at the same desk.
When I would pair at my last job, I would often bring my own keyboard and plug that in because it’s nice to have. It’s nice to just be able to type when you want.
But again I think it’s useful and I think of this as not a big deal like, “Okay, here we go. We’re gonna try pairing.” It’s like, “All right. How about you just sit down for five minutes with someone who wrote the code you’re about to change and say can you just walk me through this real quick?”
And then they walk you through it and you say, “Okay, so I’m thinking about changing here and here.” And they go, “Yep.” You’re like, “Great.”
And then they leave and, okay, you just paired. That’s great. Congrats. It’s no big deal. It’s okay. It doesn’t have to be scary.
I mean, start small if it intimidates you.
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’s always hard.
It’s easy to misunderstand each other. It’s easy to have different communication styles, it’s easy to accidentally offend someone and that’s just true any time that people are communicating.
So recognize that the burden for brain cycle spent on communicating and making sure someone understands you is higher. That’s sort of the cost of pairing there.
But beyond that, maybe just don’t worry about it too much. Just try it and see how it goes.
Q: I want to switch gears a little bit here to the journey of Tuple itself. How big is Tuple right now?
Ben: So we have…so 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.
*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?*
Ben: Yeah. We definitely are thinking about that a lot. Like a lot of companies right now, we’re figuring out how to do this well.
I don’t think we do it super well to the point where I would feel like you should do it the way we’re doing.
I will say that one thing that I’m 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.
Particularly as I get questions from the person who’s helping us out with sales, I take that question, and then rather than answer the question wherever it happened I say, “Oh, I updated this Notion page with, you know…on that topic.”
And this way, you know, training future people becomes easier. There’s a place to check if you need it later. Writing it down has probably been the biggest meta habit I think that I’ve seen benefit from.
Jovian: Yeah. I think writing it down, like, the documentation culture has to come from the top up because I feel like it’s not natural for humans to just write down stuff. It’s easier to just chat or just go into like a quick Zoom meeting and whatnot. So yeah. Great approach you have there.
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?
Ben: I don’t know. I mean, so I’ve hired three quarters of one full time person so far. And so I don’t 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 “The Manager’s Handbook” from Clearbit and they have a lot of really good detailed info on how to do that. And we’re more or less trying to steal their playbook because they’re at 100 something people and have thought about this a lot more deeply than we have.
Q: Any other best practices aside from pair programming for remote…advice for remote engineering teams to collaborate and communicate better?
Ben: I mean, again, we’re still figuring this out ourselves so I wouldn’t 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.
Actually, like doing a code review, which is that when you move from in person communication to written communication, it’s really easy to accidentally make someone feel like you’re attacking them.
Feedback…so I noticed this in PR is where you could accidentally make it seem like you’re…as opposed to asking like, “Hey, why wasn’t this method extracted?” Someone can read that and say, “Why wasn’t this method extracted, you idiot? Like how could you think that this was…this belonged here?”
And it’s a weird thing about brains that when we don’t 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.
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’s really, really easy to accidentally get mistaken in the other direction.
Audience Q&A
Q: Any insights on initial project planning and brainstorming for remote teams?
Ben: That’s a good question. I don’t 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.
Even if you decide not to use their process, I think there’s some interesting truths in that work and one of the central ones is that there’s this work that has to happen before the work can start. And it’s 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.
I’ve seen this happen at our company where I’ll say…like 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.
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.
Q: Do you have any advice for the different types of pair programming, master-novice, novice-novice or master-master?
Ben: I actually did write a blog post about this or an article about this on our pairing guide called “How to pair with a junior developer” and I think I also wrote the flip of that, the converse of that, like how to pair with someone more experienced than you.
I would say the biggest thing if you’re pairing with someone less experienced is probably to realize that they’re probably a little bit nervous.
It’s kinda natural for someone if they’re pairing with someone who’s got a lot more experience, they’re 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’s gonna be extra important for you to make it clear you’re not frustrated with them or that they’re taking too long.
It’s really easy to just kind of like brusquely shove aside someone who’s thinking again like just type out the answer or make them feel underappreciated or judged or something. So be aware of that.
As far as people pairing at the same level, I think that’s less of a problem but still just be aware of that human tendency. Like it’s just…you’re gonna have to devote more brain cycles than normal to making sure you’re communicating well and establishing a good rapport with the person you’re pairing with regardless of what your relative skill levels are.
Q: So two questions here that I feel like we can answer together. “What are communication best practices while pairing?” which is something that you have touched on just now. “And when does pair programming become inefficient or less productive? You know, not learning and just arguing.” So have you ever had this experience or even hear about the stories where pair programming just doesn’t work?
Ben: Yeah. I think probably the failure mode you’re 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…if the person driving is much more experienced or knows the code that’s being edited or written much better, it’s 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.
At that point that’s you’re not really pairing anymore. You just have an observer that’s adding not that much value. I tend to recommend or I think it’s usually a pretty good practice to switch who’s driving somewhat regularly, like who actually has hands on the keyboard or the mouse and who’s controlling things.
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.
Q: I’m on a small team, two junior devs, one senior. We’re 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%?
Ben: I 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’s two…a pair and there’s another…a third person. So I would say start off by: don’t 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’s this idea that if you take two programmers and put them on one problem, it gets…you’re getting sort of half as much done because they’re working at the same speed they did before but that’s definitely not true in my experience.
It’s 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’t know what’s going on. You’re like, “This should totally work. I’m completely mystified as to how this is not working.” And you spend time here googling, poking, debugging and you don’t know what’s going on. It’s way harder.
It’s more than twice as hard I think to block two people. And so what I find is when I’m pairing, progress usually just kinda happens pretty continuously. It’s almost like a linear progress towards the goal versus when I’m pairing alone, I’ll 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.
And so you may just find if you don’t ask for permission and just say, “Hey, why don’t you pair with me for an hour today and I’ll pair with you for an hour tomorrow?” You may actually find that you’re getting even more done than before because people have different sets of knowledge.
That’s why I think it’s harder to get blocked. There’s two sets of eyes so it’s easier to spot typos or silly mistakes. When someone is navigating as opposed to driving, they can be looking at documentation or spotting…it’s easier to spot problems and bugs when you’re not actually typing the code.
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.
This just kind of occurred to me for a second. You probably wouldn’t ask…you almost certainly would not ask your manager for permission to use a new text editor. Right?
Think about pair programming as a tool in your tool belt. Don’t 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, “This 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.”
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.
Q: You’ve 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?
Ben: I mean, I think it’s all the same problems of human communication that you’re used to which is that it’s easy to be misunderstood, it’s easy to possibly offend somebody. If someone’s sitting next to you, maybe you need to take a shower more often than you would otherwise or something. Like there’s all these different human concerns that happen all of a sudden when you combine forces as opposed to working separately.
I’m not sure there’s that much there that is programming specific. So if you’re 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.
So at the end of a pairing session, a really good habit to get into is like, “How did that go? Like what were some…what were a couple of good things and what were a couple of things that we could do better next time?” And just try to solicit feedback explicitly and make that part of your process and then…because 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.
Q: What lessons did you learn from your previous projects that you applied to Tuple as cofounder?
Ben: I mean, I don’t know. Probably hundreds of them. It’d 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’ve done this in a bunch of…I’ve launched a couple of SaaSs and a couple of one-off purchase products before this or actually a few of them, maybe three.
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’s hard to charge people…like get people to sign up for subscriptions. That’s challenging.
It’s hard to build the right thing code wise. That’s also hard. So before…think 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.
Q: What are the biggest mistakes you’ve made as a founder and as a manager? I think you’ve touched a bit on the founder side but I wonder if you have anything on the manager side?
Ben: TBD 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…almost every time that I think I and my cofounders agree on what’s about to get built and how it will work and what it will look like but we don’t write it down, there’s a mismatch there. Basically every time I think, “Okay, this feature is so small, I don’t need to…we don’t need to write anything up. This is fine. Like you definitely understand what we’re thinking.” And then sometimes it’d be like, “Wow, we still…we actually…we’re still we’re talking past each other.”
So I’ve been surprised by the necessity for that to avoid, you know, unfortunately like wasted time or a code that needs to be rewritten.
Q: What is the product roadmap of Tuple? Could you share some new features we’ll see in the near future?
Ben: Maybe. So I’ve sort of…I’ve been burned by this a little bit before about talking about stuff that we’re 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, “We’re gonna do X, Y, Z.” And then something happens.
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’re 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’t burn your CPU, high quality audio, good latency. We’ve sort of gotten the basics that we wanted to get in place. Like the…you 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, “Could we make a business based on this idea?” has been validated, it’s working.
Now it’s 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’t even really realize as a problem or that the world has never seen a good solution to? And so that’s where my head is over the next handful of months and quarters. And we have…we’ve been doing some interesting explorations there and I think there’s…we have some good stuff in the pipeline that people will go, “Oh, nice. Like this is a pain point I had that I’ve never seen anyone solve before.” And that to me is like our greater mission. So that’s kind of the big post.
The other is that we’re macOS only right now and it’s a shame that you can’t pair with people on Linux or Windows. And so long-term I think it’s highly likely that we end up moving towards those platforms as well.
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’s machine?
Ben: Yeah, I think that’s actually kind of a good way to do it is like, if I drove for 40 minutes and then we’ll take a break and then maybe you drive for 40 minutes but let’s just put it on your machine. You know, I’ll push my changes, you pull them down. I’m a big, big believer in customizing the crap out of your setup. Like my VIMRC is probably 1,000 lines long and I’ve been working on it for…like it’s like literally a decade old. It’s 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.
Q: What are the biggest future trends you see affecting engineering in the next few years?
Ben: Well, 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.
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.
There’s gonna be…this is like I presume a brand-new concern that I think will always kinda be there.
**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.
Ben: I don’t know. I actually haven’t dealt with this particular problem. I would say hopefully you’re using some tool that lets you have remote control because sometimes I find even among native speakers of the same language it’s 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.
Like if you’re saying like, “No, less than. No, no, less than or equals. No, this thing. The capital A,” than like… It’s just better to just grab the keyboard for a second. Like hopefully you have remote control. Like, “Let me show you what I mean.” It’s like tap, tap, tap, tap, tap and then it’s a lot clearer. So that might be a good option for this. Like if you’re having trouble being understood, have that other person grab control for a second and write the code that you’re thinking of.
Jovian: I feel like it’s 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?
Ben: That’s right, yep.
Jovian: Yeah, so I think there’s also like…right, sorry.
Ben: Well, yeah. We have basically a drawing feature. So you can paint on another person’s screen. So sometimes like a little diagram is like the clearest way to explain like what’s going on.
Jovian: Yeah, so I feel like it’s…like just another channel or like where to increase the fidelity of communication, especially when you have a language barrier which is absolutely interesting.
Q: If you pair program continuously, do you feel there is still a value in code reviews?
Ben: Yeah, I like that question.
I think you’re 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.
So let’s 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.
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.
The problem is it’s really hard to do good code review. It is a big, it’s an interruption in your day. If you don’t do it quickly, the person who wrote the code is blocked so you’re holding up this feature from shipping.
And it’s hard to do well in the best circumstances but it’s particularly challenging because the thing you’re 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, “Is there a reason you didn’t use this thing?” And they go, “Yes, I tried that because X, Y, Z.” Like, “Oh, but could you maybe do this?” “Oh, no. Yeah, I tried that too and it just didn’t work.”
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’s gonna be hard, right. It’s too much. It’s overwhelming. It’s 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’s just super challenging.
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’s 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’s just this…I think there’s less tendency of…so let’s say you take a kind of ugly shortcut while you’re writing code separately and then I see it in the PR and I’m like, “You really shouldn’t have done it this way but like I don’t really wanna go make him rewrite this.”
There’s this like, “You know you shouldn’t have done it. I don’t really want you to have done it but like between the two of us, it’s gonna be hard to…it’s hard socially for me to ask you to go rewrite it. I feel bad.” But if we’re doing it together and when we reach that decision point like,
“Oh, should I take the hacky thing or should I do it…?” Maybe you have a conversation and you say, “What do you feel about the shortcut?” And you go, “Why don’t we just…let’s try it the other way for five minutes and see if we can get it.” And then maybe you end up with a better product after that.
I think most programmers really enjoy writing code and I think…I would imagine that most programmers don’t enjoy reviewing code nearly as much. Like I think of doing code review as kind of a necessary chore.
So if you can swap a code review habit after the fact with a pairing habit, you’re trading code review for more coding which to me as a programmer sounds more fun.
Q: How does Tuple handle different keyboard layouts? I’ve had a lot of problems with other tools when my partner remotes into my machine and has a different keyboard layout.
Ben: This 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.
I didn’t actually write this code so I don’t 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’m not a QWERTY user. And I can pair just fine with people using QWERTY. So there’s 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.
Q: How do you address insights after the code is written? Isn’t there a different perspective after a code is written that an unbiased third-party could see?
Ben: Oh, 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’re definitely gonna end up with some insights and maybe better code as well. But keep in mind, now you’re investing three people’s 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.
If a pair wrote the code, I would tend to say, “Don’t add a third person as a code reviewer unless you think it’s worth it.” Like is this billing code? Is it particularly sensitive to errors? Maybe bring an extra set of eyes in there.
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.
Ben: I don’t tend to like to look at individual commits during review. I would rather see… 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’s a good thing for your reviewers to use. I could see it. It does kind of help address the whole like, “Here’s a giant change. I don’t know how to like parse it out,” versus, “Here’s a commit that changes something small. Here’s another commit that changes something small.” That’s kind of nice.
One thing that I do… 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’m about to make a change to some code, I’ll say, “Oh, 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.” And so I’ll actually do that refactoring and open it as a new PR just for the refactoring. Like no behavior change, just refactor. And then I’ll 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.
And one great thing that falls out of that habit is that sometimes you’ll do the refactoring and then in the interim priorities change and you decide not to do the new change to that code but you’ve shipped like a nice refactoring that hopefully has tidied things up and made it easier to change in the future.
Q: In your own experience, can you handle as many hours of pair programming in one day as you are solo programming?
Ben: Great question. Definitely not. It is much more draining to pair program than to program alone. And it’s 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’re at and read their emotions and understand the communication between the two of you.
And pairing definitely necessitates a higher level of communication. So that’s more draining. And also, you’re probably gonna work harder actually. If you block off two hours to pair with someone, you are not flipping over to your email. You’re not jumping on Slack. You’re not jumping on Twitter. You’re probably just working except for explicit brakes for most of that time.
And so it’s a bit more draining to just work harder, and I do think that’s 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’re waiting for something to build or tests to run or something like that.
So I would plan. If you’re 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.
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?
Ben: No. We’re pretty agnostic on what kind of programming you do because we share the whole desktop and with the remote control. So it doesn’t matter if you have a terminal, it doesn’t matter what editor you’re using, what tools you’re using, are you in the browser, are you in the terminal, are you using Sketch. We’re agnostic as to what’s on the screen and how you’re using it. So we optimize for things that technical people tend to care about, programmers in particular. But beyond that, we don’t say “Oh, this is better for web devs or something.”
Q: Saw a Shopify engineer on your website that is a customer. Any interesting case study you can share?
Ben: This is sort of on my list of things to do for the company. It’s 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, “Do you think that adopting Tuple increased the amount of pairing you did?” And 71% of them said yes. So in aggregate it does seem like we’re working…we’re 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…as a group, it’s kind of working.
Q: Any experience pairing with non devs instead of in the thing actually?
Ben: Pair with non devs? So I’ve 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.
But it’s been pretty rare. I think like I can only think I’ve 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’s like, “Hey, this is what we have so far. Does this look right to you?” Not quite pairing but the same idea.
Q: Where can people learn more about your journey and Tuple and what’s next for the company?
Ben: The best answer to that is probably my podcast. So I host a more or less weekly podcast. And I talk about what’s going on in the company and what our thoughts are week to week. So if you’re interested in the nitty-gritty of running a software company, that’s probably the best bet. And that is at artofproductpodcast.com. The podcast is called “The Art of Product”.
Jovian: Ben, thank you so much for your time today. I really learned a lot. And yeah.
Ben: My pleasure. Thanks for having me.
You can also try Arc, your shortcut to the world’s best remote talent:
⚡️ Access 350,000 top developers, designers, and marketers
⚡️ Vetted and ready to interview
⚡️ Freelance or full-time
