On today’s episode, we are joined by special guest, Ben Orenstein, to talk about remote pair programming. Ben is a developer, who after many years of working for other people decided to strike out on his own. He is the cofounder of an app called Tuple, which is specifically for remote pair programming. After Screenhero got shut down, Ben saw that there was a gap in the pairing market which had not been filled. Instead, from what he had gathered, people simply stopped using pairing platforms because there were not effective alternatives. Through his own career, he saw the value of pairing in developing skills both as an experienced and inexperienced developer. Not only this, but the quality of work is usually much higher when people work collaboratively. Ideally pairing would be done in person, but this is not always the case as remote work is an ever-growing reality in most work places. Remote pairing does have its difficulties in that your partner is not readily accessible and you cannot pick up on social cues, but Tuple provides some ways to work around this. Pairing should be a part of the way that you work because it expands your skill set and enables your growth as a developer. To learn about this and more, join us today!
Key Points From This Episode:
Transcript for Episode 259. Remote Pair Programming with Ben Orenstein
[0:00:01.9] MN: Hello and welcome to The Rabbit Hole, the definitive developer’s podcast live from the boogie down Bronx. My co-host, who is in fantabulous Chelsea, Manhattan.
[0:00:09.5] DA: Dave Anderson.
[0:00:10.8] MN: Our producer.
[0:00:12.0] WJ: William Jeffries.
[0:00:13.1] MN: We have a special guest. Ben Orenstein.
[0:00:17.2] BO: Hello there.
[0:00:17.8] MN: How’s it going?
[0:00:18.7] BO: Good man. I’m doing great.
[0:00:19.6] MN: Ben, tell us a little bit about yourself.
[0:00:21.2] BO: I’m a developer like you gentlemen but I have kind of taken on an entrepreneurial bent over the last handful of years. About a year and a half ago, I quit my cushy development job and struck out and started a company with two developer friends of mine called Tuple. And Tuple is an app for remote pair programming. So, we hacked on that for a while, we launched to our first customers, our sort of alpha back in January of this year and we are now generally available and we’ve been working on it ever since.
[0:00:50.8] MN: Awesome. Pair programming is usually done with two people in the same room, but this remote thing is a little different, I imagine. And there were some applications that we used to use before, rest in peace to Screenhero, that was like the thing to use. But that’s not available anymore, rest in peace.
So, why was the pair programming the application that you wanted to build?
[0:01:16.2] BO: Well, you actually hit on it which is I was a huge fan of Screenhero back in the day and so when Slack moved to shut them down, I started asking around my other developer friends what they were using now. And weirdly, the most common answer was like, “I’ve sort of just stopped pairing, I just stopped doing like remote collaboration because nothing I’ve used has been very good.”
And I just kept hearing that and I just kept thinking like you know, this really feels like an opportunity. There was a product that was good and people loved it and it solved this need, but then the product got taken away and I just didn’t see anyone else to step into that gap. And so, I kind of felt like if I didn’t take a shot at this, I’d be kicking myself for a long time.
[0:01:59.0] DA: And thank you for taking that shot at it. It definitely is a gap that we all have felt. We’ve talked about this in different episodes like working as a remote developer and you know, pair programming episode. You know, when you’re working remotely like you really rely on having a good set of tools that minimizes the friction that you have, collaborate with other people.
[0:02:20.6] BO: Right, there’s another part of this. The Screenhero missing was one reason. But also, the thing that really got my career and my skill level going was I took my first real development job at a place doing some Ruby and for maybe the first six to nine months, I sat right next to my boss who was a very experienced developer. And we paired for most of the day every day.
That period of time, I grew as a programmer more than any other in my life basically. And so, I had this love really in my heart for pairing and I just knew that I don’t think there’s a higher bandwidth more effective way of skilling up as a developer. I just think pairing is the best thing and it makes sense kind of like this apprentice model of like working next to someone that has more experience than you, is super, super old. We’re very wired as humans to learn from each other by watching someone do it next to us and so that’s, I was super excited to support that kind of thing.
I asked myself, if this company is very successful, what will happen? We’ll have a lot more pairing in the world and that’s even great to me.
[0:03:29.9] DA: Yeah, I think even as a more experienced developer, there are things that you do that you don’t realize that you do that you don’t realize that you do? Or things that you do that you don’t realize that you do that are very effective and other people don’t know about or don’t think about. And there are things also things that you do that you’re just like by habit, just keep doing them and don’t think about doing it in a different way because they work.
And by having that close collaboration with someone else, they kind of like is a jigger that shakes you out of your habits and like makes you reevaluate it.
[0:04:05.1] WJ: Yeah, I remember, I had autocomplete like tab auto complete broken in my VIM for like a while.
[0:04:14.3] DA: You’re just fine with it.
[0:04:15.3] WJ: Yeah.
[0:04:15.7] DA: This is my VIM kit, whatever.
[0:04:17.5] WJ: I used to not being able to tab autocomplete and then I paired with somebody and he was like, “dude, you know how much this sucks, right?” I was like, “no, is it? Wait. Yeah, those suck, let me fix this.” And you know, you get these little blind spots of develop over time and having somebody watching you, I think can help shake you out of it.
[0:04:43.0] BO: Absolutely. I said earlier that the big thing for me was pairing with someone more experienced but even now, as I’m often the one who has more experience, I think I learn something every time I pair with someone. You don’t just learn because the person you’re pairing with has a huge wealth of knowledge. I sometimes learn because someone will ask me like, “hey, how did you do that or why are you doing it this way?”
Sometimes I look into it and it’s like actually, you know, I don’t really know why I’m doing it this way, I just thought I always have and so we go read the docs or we try different approach. And it’s crazy how much you can learn by pairing with people of very different skill levels and it almost doesn’t matter who you’re pairing with. I feel like you’re going to learn something.
[0:05:20.0] DA: There’s such a various reasons for pairing with people and like another one besides like skilling up or like teaching someone or reframing things in your mind. I find that sometimes I get like a bit like analysis paralysis when I’m looking at a big task like I’ll just like keep digging in the code and keep digging and like planning and thinking and making an idea of what the best possible way to make this change is.
Having someone there with you just puts the social pressure on you to be like, “hey, why don’t we just do it? Why don’t we do a thing like anything.”
[0:05:56.1] BO: Yeah, as if it weren’t enough that each person in the pair is probably getting better, you’re probably also producing much higher quality code as a result.
[0:06:04.4] MN: Yeah, I do find that like regardless of the level whether I’m learning from someone who is more senior than me and I get to ask questions or someone who is more junior, who is asking me why we do certain things and then I have it to give an explanation. There’s always an opportunity to learn from that. A lot of people sometimes overlook pairing, even in person and I think people will choose not to pair at all if it’s remote. But applications such like Screenhero and now Tuple gives the ability for people to have the opportunity to pair which is pretty dope.
[0:06:40.4] WJ: What do you think is missing from the pairing experience when you do it remotely?
[0:06:46.2] BO: That’s a great question. I’ll actually be the first to admit that if I can pair in person with someone, that’s going to be my preference. Ideally, I can see the person and read their body language and see when they’re reaching their hands towards the keyboard versus not. That’s awesome. If you have that option, I would take that one.
But the reality is there are lots of people that you might want to pair with that might not be within 10 feet of you. The biggest thing you lose is sort of that out of the corner of your eye, read on their body language and how they’re feeling. So, you have to I think pay a little bit more attention when you're doing remote pairing and probably be more cognizant of, “hey, is it time for a break? Is the person I’m pairing with still into this? Am I still into this?”
You can’t read the room as well anymore I think. You can’t read the room as well anymore I think, it’s probably the biggest change.
[0:07:30.5] DA: More of a need for like vocalization.
[0:07:33.3] BO: Yeah, I think so. We recently added webcam support to Tuple so you could actually see people and people were very excited about that and there was like this steady drum beat of people asking for it before we had it. And it makes perfect sense because it’s hard just based on someone’s voice to read how they’re feeling. The webcam helps with that, but still I think the communication burden is probably higher with remote pairing even with a webcam.
[0:07:56.4] WJ: I was going to say the same thing about the body language. That makes perfect sense that the camera would be a commonly requested feature. I wonder if there’s something around switching drivers like – that is easier when you’re in person. I mean, it’s probably because of the body language, but you know, one thing that I remember doing in times when my pair and I had a hard time switching was getting a chess timer, you know, those chess clocks?
And they have a button on either end and you can slap your end and now your time is over and it’s the other person’s turn. So, we use that to try and measure how much each of us was spending driving which was pretty helpful because it revealed a trend you know, previously, we had no real data for. And it gave us immediate feedback so that we could start to course correct. And like, “ oh, I’m running out of time, I should probably start tagging out.”
[0:08:50.8] BO: Did you notice a qualitative difference in those pairing sessions? Did they feel better when your split was very close to even?
[0:08:57.1] WJ: I think that there were lots of pairing sessions where it wasn’t even and felt fine. But whenever it was really one sided, it always felt bad. You know, 75/25, that’s fine. When you get down to like 90/10, there’s something wrong.
[0:09:14.1] DA: Yeah, right. Then it’s like kind of like you may as well just be streaming on Twitch or something.
[0:09:21.9] BO: One thing I’ve noticed is that like driving versus navigating kind of fatigue different parts of your brain. And so, I think that’s like the best argument for switching is that paying attention to someone else driving for a long time is fatiguing, but it’s fatiguing in a different way than driving is. Swapping lets you rest the tired parts, each of you and that’s why I think it’s like a best practice.
It doesn’t have to be 50/50. I’m not sure that that’s the ideal number, but it kind of depends on who is involved I would say and like your level of familiarity with the code and what not. But I think some mixing of that is probably really important.
[0:09:54.2] DA: Are there any like rules or etiquette that you like to follow while pairing either remote or in person?
[0:10:00.0] BO: Yes, I would say that the highest level one and probably the most important one is just like being nice and some people are kind of – some people can get a little prickly and –
[0:10:09.6] MN: Yes.
[0:10:11.8] BO: Pairing is a collaborative act and it’s like kind of intimate in a way like an in person, you’re sharing physical space and it’s – if you want to have a good session, you kind of have to be a nice person and –
[0:10:22.3] WJ: Don’t be a prickly pear.
[0:10:26.6] MN: Rule number one.
[0:10:27.6] BO: Well done. Actually, right now having a shirt designs that plays in the pair programmer pun. So, we’ll see when that comes out. Just like being a good collaborative helpful person goes a long way. And one thing that I tell people when they’re new to pairing is like be aware that pairing is a skill and you might be pairing with someone that’s not very good at it.
So, some people have had like a really scarring, traumatic or negative first pairing experience and they write it off, which I think is super unfortunate. But it turns out that some people are just not that good at it and so you should not write of the whole practice just because you had a bad session.
[0:11:02.8] DA: Right, that kind of ties back into the mentorship or apprenticeship kind of aspect of it. The only way to learn it is by doing it, but if no one at your office really knows how to do it then who is going to teach people how, what good looks like?
[0:11:20.7] WJ: And I also think people should power through that because you know, it gets better. People get better, even if your pair is not very skilled, over time, they will get better, even if you don’t have any formal training. Most people learn from social situations like that.
[0:11:36.0] BO: Yup, I agree. I think it’s – one good thing that can help with that is to sort of include a debrief at the end of the pairing session and just like do like a mini retro basically and just ask like, “how is that for you, look who we’ve done to make that better or more pleasant or more effective?”
[0:11:51.1] DA: Yeah, I like that. There’s some teams at Stride that like, are very all in on pairing like 100% of the time, but as a result of that, they had to be very aware of all the nuances of it and make sure they’re getting those feedback loops and like being very open for that kind of asking those kind of questions.
[0:12:13.9] BO: Yup, you asked about rules and another thing I would say is this is a classic mistake. So, it’s not super important but it’s just commonly screwed up until I mentioned it which is pointing out typos as soon as you see them.
[0:12:29.4] DA: But that’s helping.
[0:12:30.4] BO: Yeah. I think people think that’s pairing, they think it’s helpful and like it sort of is but pointing out typos breaks your flow as the navigator and it also breaks the driver’s flow. And so, I think that the first rule of good navigating is like take a minute, give your driver a chance to spot the typos themselves and fix them. Even if they like – they start running the test or something. Wait a second, give them a moment to do it and it will feel better for both of you.
[0:12:54.7] WJ: Also trying to convert your pair to your preferred hot key, like pattern. There are an infinite number of ways that you could edit a line of code and get the same result. Being like, “dude, you know, this specific hotkey,” particularly for – I think this is more for VIM users.
[0:13:18.9] DA: Using surround.
[0:13:20.8] BO: I try to – when I’m navigating and someone who is a VIM user, I try to resist offering those tips until I see them do it like 20 times and then I’ll just say, “by the way, are you interested in a shortcut for this?” Just kind of phrase it in a friendly way.
[0:13:33.8] WJ: That’s a great approach.
[0:13:34.8] DA: Right, yeah. Make sure that they’re feeling the pain of not using that shortcut.
[0:13:41.1] BO: That’s a classic teaching technique which is like don’t teach a thing that doesn’t solve a pain a student has had already.
[0:13:45.9] MN: Yeah. I tend for both the typos and the hotkey situation, I like to use index cards to write notes for myself like to let the driver know, but not to immediately interrupt them I try to write it down, “like typo on line 125 and then facedown.” And then let’s finish like I want the driver to finish their thoughts onto the application or to the program and then from there, I’m like, “okay these index cards came up for the navigation.”
“So there is typo but we probably already caught that,” and then I like at the end of the Pomodoro, whatever break system we decide to use at that time, I try to bring up like the, “hey are you interested in learning a different way of doing the thing you did earlier?” Kind of thing. But rather than time them right then and there is not my cup of tea and I suggest people to get index cards to write their thoughts down so that –
[0:14:40.4] DA: I really like that because then you can also let go of it because I am thinking about the discipline that Ben is talking about where it’s like, “oh, just don’t talk about any typos.” But it’s like being a designer and seeing pixels being off or like the vertical alignments being off between elements, you want to shine a light on it and so it gets resolved. But I guess like if you put in the card then it is out of your system and you can do one thing –
[0:15:06.3] MN: I did do the typo one like the minute I write the typo like index card the person probably knows that it exists. So, there is no point in bringing up the typo although I do feel like I get that reaction like immediately I say typo like, “oh I am being helpful. Let me tell them to change it.” But the index cards definitely helps me out in that regard. Ben do you use any other tools like I mentioned index cards and Sharpie? Do you find yourself as a driver and navigator use different tools when you are pair programming?
[0:15:38.2] BO: Yeah, I love having a notebook handy. Actually, a couple of things, so first of all, I almost always bring a keyboard with me to a pairing session if I am in person. It is nice to really quickly be able to just type something. And so, to me, a pairing session should start with the navigator plugging in their keyboard to the driver’s computer so that if at any point you want to you can write some code quickly.
Beyond that I really like to have a notebook handy. So I had an interesting experience a couple of months ago where – so Tuple is written in C++ which is a language I don’t know and we had a bug in it that was really causing a lot of annoyance for our users. And so I sat down with one of my cofounders and I said, “let’s try to fix this bug even though I don’t know C++.” I took it on myself as navigator to just ask questions to narrow down the search space. So, I just kept saying things like, “okay, what are the symptoms of the bug and what could possibly explain these symptoms?”
And I would just take notes and write them down. I started building this document basically which is like here’s everything we know about the bug and then we would open up a file and I’ll be like, “what are these first 10 lines do roughly?” And just force my pair to explain it to me and I just started building this description of the bug, again the world around it and what we knew and what our suspicions were and our hypotheses and started checking them off.
And eventually, I was the one who was like, “I think we should check this line and for this thing because based on what you are saying, the bug could be this.” And eventually it turned out that that was correct. It was really striking to me that I could successfully and helpfully pair with someone despite not even knowing the language.
And I think that is a good way to think about the navigator role and so you should be able – you are like the external brain of the driver. And so, your job is to level them up and make them smarter and if you are doing it well enough, you shouldn’t even need to know the language they’re working in.
[0:17:23.3] DA: Right or have the full context. It is like just being their conscience like their Jiminy Cricket or sidekick or what have you.
[0:17:30.8] BO: Yeah and Mike what you are saying about the index card, I think that is a great system. You’re like their stack for them and then you don’t even have to think of it either because you have written it down, I think that’s great.
[0:17:41.0] MN: Yeah, notebooks are very important as you mentioned. I do like the idea of you like even before because as developers you just want to go in and fix the bug, find where the bug is and crush it as fast as possible. But in your example, you had more reserved approach of saying, “hey, like let us talk about this, where the pain point is happening, where would this possibly exist in the code base?”
And then figuring out exactly what line is causing the error as a navigator it is exactly stopping the driver from wanting to go in and crush all the things. That is a pretty dope tip.
[0:18:17.8] BO: Yeah thanks. And one thing that happened during the session was what you just said, which is like there were times where I was stopping the driver from doing something. He would start pulling the thread on a particular line and I said, “and how does this line work? I am not sure how this works.” And I would just kind of notice, “okay, we are three files deep now and it doesn’t really seem like this is where the bug is likely to lie based on what we know about it.”
And so, I just be like, “do you think we should keep moving on? Maybe just write this off and go back to it?” And he’d go, “okay sure,” and then we keep making progress and so sometimes good navigating I think is keeping your driver from diving too deep into rabbit holes so to speak.
[0:18:53.4] DA: Right as they say.
[0:18:56.3] WJ: A lot times people are too focused on driving because it is what resembles what they do solo and so navigating becomes a lot of waiting for your turn to drive and when you think about navigating as a separate skill with a separate set of tools like index cards and notepads and pick you –
[0:19:15.6] DA: It sure like grow maths.
[0:19:17.1] WJ: Yeah. I think it puts people in a better mindset for pairing.
[0:19:21.2] DA: When should you do remote pair programming? When should you use Tuple if in person pair programming is better?
[0:19:27.8] BO: Well like I said, I’d prefer in person if I can do it but the universe of people you can pair with in person is just so much smaller than the people you could pair with remotely. So, some folks are remote full-time and so remote pairing is their only option but I would say even people that work in person these days there’s almost no one is always in person, right? Probably just about all of us do some working on the road or some working from home or maybe you want to collaborate with someone that’s up a couple of stories in the building and you don’t feel like walking up there. Some people –
[0:19:57.7] WJ: Well we actually Tuple for in person pairing. If you have two people and they are both on MacBooks and nobody has an external keyboard, your only option for that more comfortable pairing set up where both people have access to a keyboard and mouse is remote screen share. I don’t think I have ever actually – I still have not used Tuple yet to pair with someone who is more than two feet away.
[0:20:20.6] MN: Oh interesting.
[0:20:22.1] BO: That’s hilarious.
[0:20:23.0] DA: Maybe it’s a peer pressure. I will just apply more peer pressure to try it out.
[0:20:26.4] BO: Damn it, William, the wrong people are using our product.
[0:20:31.1] DA: Yeah but the equipment and logistic aspects of the in person set up can often be daunting especially if you’re in a more inflexible work space where there’s a lot of people in there. You may not have a lot of like a big desk or a large monitor.
[0:20:49.6] WJ: Right, it is like a huge piece of inertia that your equipment is already set up a certain way. And so my external keyboards are already plugged into my laptop and my monitors are already plugged in my laptop and if you eliminate all of that then it’s like, “look I am just going to my tool bar and I click this button,” I don’t know I think that it makes it easier to grab a person and get them to start pairing with you.
My frustration is when the person is legitimately remote, like in another office maybe in another country and then I don’t really have any tools to help me aside from Slack to help me get them engaged in pairing. It’s like when you’re in person you can tell does this person look like he is free or she is free for pairing right now? Would she be responsive if I proposed this? Whereas when I am in Spain and you are in New York, it is just a much more difficult judgment call.
[0:21:44.2] DA: Yeah totally. I was working on a team where they started expanding and it was very challenging to hire in New York, hard to get the kind of people that they wanted. So they started hiring in Philadelphia and they hired a bunch of people and then all of a sudden half of my team is in Philadelphia and we had to figure out this whole new means of collaboration, go through all these hoops to figure out what kind of tools were available to help us collaborate a little bit more efficiently.
[0:22:11.2] MN: I think William brought up a good point with the idea that it’s easy to know when a person is available for pairing or whether they’re like, in it to pair. And Ben mentioned earlier that Tuple recently released the feature for the webcam like to being able to see the person’s face and whether they’re engaged in the pair programming.
Ben, is there any other features right now you think you would add to your remote pair programming application and if so, what it is?
[0:22:43.2] BO: There are a couple of things, yeah. They’re on the smaller side, but they’re sort of on my mind. One is sort of like a status. Right now, there’s a list of people that’s like, are these people busy or are they – do they want to pair it now and so we don’t have a way of kind of putting your hand up and saying, “hey, I’m available FYI if you want to call me.”
[0:22:58.4] MN: I see. You're looking for group, looking for pair.
[0:23:02.0] BO: Looking for group like that.
[0:23:02.2] DA: World of Warcraft kind of thing, yeah, awesome. Anything else?
[0:23:06.5] BO: That would be one and the other is just kind of – there’s an interesting social pressure or something that happens like when you call someone using an app like ours where it’s like you probably don’t want to call someone until they know you're going to call them. Just having some sort of feature where it’s like just like a button which is like, “hey, are you ready?” And then someone can quickly do a yes/no.
I don’t think it would add full chat, that seems kind of annoying, but if there was just like a rather than, “hey, there’s an incoming call, do you want to accept or decline.” There’s like a message as like, “can you start now?”
[0:23:36.9] MN: Like a ready check?
[0:23:37.1] BO: Exactly.
[0:23:39.1] MN: Seeing is the party is both available to talk or ready to pair rather.
[0:23:43.5] DA: It’s kind of funny how like kind of ubiquitous that notion is, at least among like our generation like I feel so bad giving someone a phone call. I have to send a text first, like,” is this okay? I’m about to invade your life right now.”
[0:24:00.4] BO: Totally, it’s 100% like a millennial thing.
[0:24:06.7] DA: Generation X people just won’t understand.
[0:24:10.9] BO: I had a call scheduled with – intro someone. A gentleman who is a bit on the older side and I was like, “hey, do you want to do a call on Friday at 3:00?” And he’s like, “yeah.” I was like, “great, here’s the link.” And he was like, “here’s my phone number.”
To me, a call equals we’re going to do a video chat and to him a call is like call me on the telephone. Yeah, I guess that makes sense.
[0:24:36.5] MN: Give him a Zoom like, I don’t know, here’s my phone number. And then you had to take the phone out of your pocket and then you have to dial it. That’s like weird and archaic, what is this?
[0:24:46.7] BO: I couldn’t see him at all.
[0:24:49.0] DA: Basically, a rotary phone, you know?
[0:24:51.9] BO: I called the operator asked her connect us.
[0:24:56.2] MN: The good old days. Ben, how can people contact you?
[0:25:00.0] BO: Hilariously or maybe unfortunately, I’m probably most responsive on Twitter which is embarrassing. I think my Twitter response times are faster than email so I’m r00k on Twitter because I used to love chess when I was a kid. If you want to email me, it’s just ben@tuple.app.
[0:25:19.4] MN: And announcement in terms of Tuple?
[0:25:21.1] BO: Sure, yeah, at some point soon, we’re going to full 1.0. We’re currently on version 0.44.1 which is very exciting, we’re in a good place now. So, our call quality ratings are high, we’ve crossed hundreds of customers now and people like the app. And so, we’re feeling really good about where it is, we don’t feel like we’re missing any major features anymore so we’re going to go and stamp a 1.0 pretty soon.
If you’re interested in trying it, you can just go to tuple.app and drop your email and we’ll shoot you an invite very quickly.
[0:25:48.1] MN: Awesome. 1.0 coming soon.
[0:25:51.1] WJ: You heard it here first ladies and gentlemen, we got the scoop.
[0:25:54.1] BO: Exclusive.
[0:25:56.5] MN: Ben, thanks so much for coming on down.
[0:25:58.5] BO: It was a pleasure, I enjoyed it.
[END OF INTERVIEW]
[0:25:58.9] MN: Follow us now on Twitter @radiofreerabbit so we can keep the conversation going. Like what you hear? Give us a five-star review and help developers like you find their way into The Rabbit Hole and never miss an episode. Subscribe now however you listen to your favorite podcast.
On behalf of our producer extraordinaire, William Jeffries and my amazing co-host, Dave Anderson and me, your host, Michael Nunez, thanks for listening to The Rabbit Hole.
[END]
Links and Resources:
