Tools for Remote Software Development and Pair Programming

What kind of pair programming have you engaged in, beyond the "debug over the shoulder" scenario?

I've had a occasionally successful pair-coding experiences, but I'd say I generally agree with you. Pull requests and code reviews have a lot of benefits. It lets the team work asynchronously, so you can collaborate more effectively with remote workers from around the world. As you make some changes, other people in your team might be interested in the reasoning which lead to that decision, and you can point to the pull request's discussion. In addition, it lets you think about the problem over a longer period of time, without putting anyone "on the spot"; sometimes you just need to let things stew for a bit.

> a lot of the benefits of pair programming

So much of the work I do as a programmer does not go into the repository.

Yeah, that's not ideal, but so much of the work I do is in the technique. In the keyboard shortcut, the ~/.bashrc, the discipline of red-green-refactor, of pomodoro.

None of that stuff goes into the pull request, and yet all of it is something my programming pair can experience and learn from. And when I enter an area that's bizarre to me — when I am picking up a new language, a new tool or paradigm — a partner is 1000x more productive than my incessant slacking of code snippets when her explanations easily become demonstrations, and not least of all because it means that helping me is not an interruption to your KPIs.

None of that comes across in a pull request.

Maybe if your work exists entirely within code, within languages that you know, with build toolchains that are done changing, and you're entirely satisfied with your development environment, habits, and methods. In that case, yeah, CI and a little PR review are probably all you need.

Meanwhile, pair programming actually decreases the discipline you need to be a good engineer.

Pair programming is a skill. Some people do it very well. Some people do it very poorly. It is a skill you can get better at if you practice regularly and have good guidance from people with experience.

I like pair programming -- though I personally prefer to do it remotely, believe it or not. I am never comfortable in other people's space (well, my wife being an exception, but I'm not willing to put in as much effort for a coworker ;-) ). Also, I have poor vision and I require a different setup on my computer than most people. Finally, I like being able to turn up or down the volume of the person I'm talking to (really, this is the killer feature for remote pairing).

But you are right that it takes a lot of discipline. Usually when I get a new person, we start with ping-pong (I write a failing test, you make it pass, you write the next failing test, I make it pass, I write the next failing test, etc, etc). This gets you used to the idea that it is a collaboration, not a demonstration.

Normally, switching "drivers" at most every 5 minutes is a good indicator of success. If you go more than 20 minutes with the same "driver", then you will almost always have problems.

I refer to the "non-driving" partner as the "navigator". Imagine a rally car race. The driver is concentrating on keeping the rubber on the downward side and not running into a tree. The navigator is concentrating on what's coming up and giving useful guidance like "3rd gear. left turn". By separating the two tasks, the car can go significantly faster -- especially in rough terrain.

In terms of programming, this usually comes out as descriptions of the next test, advice for refactoring, warning about YAGNI, keeping a todo list, etc. Normally the navigator should be giving short guidance, or asking quick questions. Occasionally the navigator should ask the question, "What are you doing?". If the driver goes silent, then it is up to the navigator to pull them out of their head.

Sometimes the navigator or driver can not explain what they are thinking in words. In those cases, they should take control of the keyboard and sketch their thoughts in code. This should take no more than 5 minutes, generally.

Many people I've worked with have difficult with pair programming. Usually these people have no trouble pairing with me. I don't say that to brag, it's just that it is a lot easier to pair with someone who has done it successfully for a long time (I started doing pair programming around the year 2000).

Most of the problems I see come down to one or more of the following:

- Personal problems between people. There are some people that don't get along (even some people don't get along with me ;-) ) Good programmers can mitigate this problem to a certain degree, but sometimes this requires an "organisational solution". Honestly, this is one of the best parts of pair programming because the hostility is going to come out one way or another. Making it obvious makes it easier to fix.

- Vast differences in approach. Pair programming works dramatically better with TDD IMHO. It is really difficult to get a good rhythm without it (although I'm sure there are ways to do it -- I just don't know what they are). If you are pairing with someone who really dislikes TDD, you are probably going to have problems. This is one of the places where I will usually back off on the pair programming and suggest other kinds of approaches.

- Experiential gaps. It is frustrating when your pair is sitting and looking at a blank screen with no idea what to do. It is equally frustrating when they start running off in a crazy direction because they don't know what they are doing. On the other side, it is often impossible to pair program with someone who charges ahead when you have no idea what's going on. It is embarrassing and frustrating to constantly have to ask them to stop and explain what they are doing. I could (and should) write a whole blog post about how to address these kinds of issues. The main thing is that you must hand over the keyboard every 5 minutes. If you do that, then the problems will become a lot more obvious.

- Schedule conflicts. Get to work at 8:30. Coworker has slept in. Do some admin until 9:30 when the coworker shows up. But you aren't done, so you suggest that you start at 10. Coworker, gets grabbed by someone to look over a design and doesn't get back until 10:30. By then you have been asked to pair on a quick and urgent bug. At 11:00 you are both free. After you get the pleasantries out of the way, you start coding. You get 1 pomodoro done and it's 11:45. Your coworkers are yelling at you to run out to the burrito restaurant before it gets busy. You've worked 3 and a half hours and have done 1 pomodoro :-P Unfortunately you need to be really, really disciplined. Pairing starts on time and finishes on time. If someone is late, you make sure that you start ASAP. This takes a lot of practice.

Finally, wrt to debugging, there are times when pairs should split. Debugging is usually one of them. It's another great reason to remote pair because it is trivial to split and then come back together again. As soon as you find the problem, you shout at the other person (or ping them on the computer) and you go back to pairing. Another time this happens is when you have to read documentation, or do google searches to figure out how to do the next bit.

Having said that, if you spend any non-trivial amount of time debugging, then you are failing at TDD. I say this having written very, very large system before. You virtually never need to debug code that you have TDDed well, because you can write a failing test more easily (the only time you can't is when you can't reproduce the failure, which hopefully will be rare ;-) ). Of course, if you are dealing with legacy code (even if it's your own legacy!) that's of scant help -- so you will have to split to debug. But it should give you at least a small benchmark to see if your TDDing has been effective.

Edit: formating

No PR + Code Review process is going to help with the cognitive load of programming.

When you begin to juggle multiple open files, moving program flows between them, rewriting or moving tests and methods, etc., those times when you are refactoring part of your architecture, for this kind of task I think there's no better tool than pair programming (or even mob programming) for example.

Also you are right on it: it takes discipline. It's exhausting by the end of the day but some of my most productive days were after a 6 hours session of pure pair programming, while refactoring or splitting up a service that grew too big. Or implementing some convoluted business logic where my head couldn't properly hold all of the pieces together.

I don't think PR + Code Reviews would help on those cases, if done properly it can probably come to the same end result but with a muuuch longer feedback loop.

You can avoid a lot of back tracking that happens during PR process by just simple applying human contact and clear communication during the feature implementation. I really don't like when people who are unable to work with others force everyone in to asocial PR mindset.

I much prefer pair programming because: 1) I am sharing a thought process in-the-moment, and bringing my unique thoughts. This drives out a lot of the biases that engage when reviewing someone else's thinking after-the-fact. 2) Conversely with #1, my code is actually much better when I have paired with someone. They challenge me in-the-moment so I am able to have more powerful insights about what's a better way to go. I think better with someone who knows how to pair. 3) The results of a pair programming session are that both of us are intimately familiar with the codebase we just created. This is great for the business -- no silos. When I review someone's code, I have passing familiarity, but since I spent a fraction of the time with it, I haven't built up a strong memory stream of why, what, and how we built what we built. So if my partner or I end up needing to go somewhere else, there is no real hit to the organization. I feel like I brought a high level of professionalism and can leave with a clear conscience.

And more. There really is no substitute that I've found.

I am not sure that Floobits is really that widely known. I only heard about it for a short time 2 years ago (where it didn't work when trying it), and never since.

NET::ERR_CERT_REVOKED Issuer: StartCom Class 2 IV Server CA

Is Wemux (https://github.com/zolrath/wemux) still relevant?

tmate is fantastic for exactly this. You can share a session on your local machine, the pair doesn't need tmux, and obviously you don't need a remote machine setup for development.

https://tmate.io/

I have lamented the lack of a good online whiteboard experience for decades now. I think the real problem is that for a proper whiteboard, we need obscenely large and high-resolution displays.

Analog is much better than digital in this particular.

It's very bare-bones, but the solution that works most reliably for me is still https://awwapp.com (has been around for ages)

That still leaves a lot of room for improvement. I'd love to see something that has a native iOS app with great Pencil support, as well as clients for other platforms (anything that people tend to use with a pen, like MS Surface), and also a web-app as a fall-back, at least read-only. Low-latency is a must. There are a bunch of solutions I've tried, but most take something like 20 seconds for things to shop up on all the clients (or longer, like a shared One-Note notebook). That just doesn't work for a video conference.

Guessing you're talking about Screenhero.

https://screenhero.com/

Works better for me without https

http://localhost.run/

How's the latency with VNC these days? I haven't used it in probably 10 years, but it was pretty bad back then and basically only useful for emergencies in my experience.

Edit: IIRC VNC being awful was why Citrix became so popular way back when. Something something thin client something proprietary compression algorithm. Is that ringing any bells?