I used to think there was a lot of value in the concept of pair programming but I think the Pull Request and Code Review model is simply superior. It allows for a lot of the benefits of pair programming but with lower costs. I've always found that even looking over someone's shoulder to help debug something slows to a crawl. It takes more discipline than most engineers have to keep it truly paired.
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.
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.
I agrer that these things have value too but some places do Developer Share Sessions where one developer does a short presentation on a complicated subsystem or tools they use or a new api that needs integrated.
That sounds terribly dull. Unlike during a programming exercise, there's no forcing function during a presentation that impels me to try and put this information in the right place in my mind. Certain note-taking strategies attempt to fabricate such a forcing function, but it's ersatz.
Most of my notes during presentations or long-winded meetings boil down to "what motivated this presenter to speak?" or "why do I have to sit through this?"
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.
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.
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.
To be honest, it has been a while but I did try it for developing code. The main issue is that (not bragging) I was working with an older, more "senior" developer but I was a much stronger developer. When he was driving, he wouldn't really have a plan for what to work on next. Maybe it was someone looking over his shoulder, I'm not sure. He also had trouble following when I was driving even though I spent extra energy trying to explain what I was doing. As has been discussed, it takes a lot of discipline and matched skill levels and approaches to be successful (imo) and I think that is the exception not the rule. ymmv, so to each their own.
ymmv for sure. i suspect that pairing is far less valuable if not used in tandem with other XP techniques (eg tdd, ci/cd, continuous process). but certainly pairing isn't the One True Agile Way ;)
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.
I think the experience difference and approach differences are difficult yo overcome. If you are pairing with mostly other senior engineers, maybe it is less of an issue. The other skill that varies greatly is the ability for abstract visualization. I build a model of what I'm working on almost immediately. It takes others time to slowly build it up and draw pictures, etc. I could tell them what I think it should be but they are supposed to be driving. Otherwise, I'm designing it and they are just implementing it and that doesn't feel very pair oriented.
I won't lie. They are difficult to overcome. I really advocate going a full XP style if you are going to do pair programming. Getting really good at TDD makes such a huge difference. You can drill down into one aspect of the design and build it up -- because you are isolating it, it reduces the amount of conversation necessary. You can say, "How about we start with object X and see where it takes us", even if you have a pretty good idea where it's going to go. Those who are lost are given something to hang on to and focus on. But it's also important to be flexible because often you have a whole architecture in your mind and your pair starts taking it in another direction. It's good to allow it to move forward, checking in code as you go, without fear that it's all somehow going to be ruined.
On my team, I often say that I know exactly one way to be really, really successful -- XP. There are other ways to be successful, I'm sure, but that's the way I know how to do it. If you start mixing and matching techniques, it gets harder and harder to find a path towards excellence -- because you are walking through the unknown. Although I'm a huge advocate for pair programming on an XP team, I don't really recommend it for other types of teams because I don't know how to make it work well.
(Just to be clear, I can be successful using other techniques, but the kinds of success I've had on highly functional XP teams, I've never seen anywhere else before)
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.
Not the OP, but as a frequent tmux pair programmer, I've never found wemux to be particularly relevant. It's useful if you don't know how to use the advanced features of tmux. Everything in wemux can be done in tmux -- you just need to know how to do it. Having said that, reading the tmux manual is something that might occupy you for more time than you would like to spend :-)
Yeah, tmux is pretty powerful all by itself, and perfectly suited for pair-programming, assuming ssh is set up. I wrote a little wrapper script a while ago to handle the setup of the ssh keys on a temporary basis (the partner's SSH key is allowed to attach to the appropriate tmux session only and is removed when disconnected): https://github.com/goerz/tmuxpair
I do something similar. I set up a "pair" user on the system whose login shell is just a script that attaches to the tmux session. The script that starts the tmux session, sets the group permissions on the socket to "pair". This means that even though the "pair" user has their ssh key in pair's authorised_keys file, they can't log in unless there is an ssh session with the appropriately shared socket. Also, they are never logged in as your user (though, sharing the session, they can do whatever you can do -- only you are guaranteed to be able to see it).
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.
What about a shared whiteboard, though? That's the one thing I'm missing at the moment. Using one of those with a couple of nice graphics tablets would be great.
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.
SmoothDraw[1] is what Kahn Academy uses, but it lacks those features you mention. Milton[2] is an open source stroke based application, so you get infinite canvas and infinite zoom. Neither are network-based though and it's tough to beat a physical whiteboard.
A little bit "out there" but I've been impressed with 'Dry Erase: Infinite VR Whiteboard'[0]. You get far more space to play with in a virtual environment than you can get on a screen. This would be killer if it supported multiple users over the internet, which is possibly being considered by the dev.[1]
You might be interested in https://gsuite.google.com/products/jamboard/ though I doubt your company would pay for each of you to have one at home. It's more of an office to office type of thing, I think.
Whiteboarding is one of the biggest problems working with offshore devs. I am kind of surprised that after all these years there still is nothing out there that works as well as a physical whiteboard.
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.
At my current place (team of 5), we set up Zerotier[0] to create a LAN between all of our computers and servers. This lets us directly ssh into each-other's machine, simplifies file sharing to an rsync, etc...
I find this works really well, as when someone has a bug and needs help, we can all access http://<hisip>:8000 to access the instance he's working on, and ssh into the machine to get access to the logs to try and help figure out what's wrong.
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?
