Counterpoint: I have found that too often people will not accept CR criticism unless it’s something trivial, usually actually addressed in official guidelines. If you actually bring up something tough like separation of concerns, they will not actually consider feedback and insist their solution is adequate, or even better, without even bothering to offer very good reasons. Even if you offer very concrete advice like pointing out that recursion could solve a problem in a much more elegant and clear way, you can get responses like “I tried that and it didn’t work” and you are forced to approve often significantly suboptimal code unless you literally implement it for them. I’ve noticed this is a lot worse in 100% remote orgs, and is one aspect I definitely think is detrimental vs. being able to establish regular face to face communication with someone. Admittedly, remote pairing doesn’t fully solve that problem, especially if it’s infrequent, and it’s obviously also related to culture and personality etc, but it’s definitely a pattern I’ve noticed. Pairing can build both the rapport and shared ownership necessary to avoid the siloing that can result when this sort of thing gets out of hand.
Yes to all of this and why I hate code review. Even when people are receptive to your feedback, you end up doing a suboptimal form of pairing anyway. That’s my rather pessimistic take (and experience) anyway. And again, it’s not like pairing magically solves it if you’re working with difficult people.
On another note I actually preferred pairing remote using Tuple to in person pairing. It solves the noise problem.
We’re also a fan of Tuple! My team is all remote, so we have to use something like that.
We “pair” all the time, but it’s mostly just asking questions, getting unstuck, boredom (just wanna hang out), or duck debugging (probably the most common). We don’t really pair in the official definition of it (i.e. 2 people developing a feature together).
We’ve definitely accepted some not great code because we felt bad about rejecting a PR for the 10th time… 
We just make a new PR cleaning things up, write lots of PR comments explaining why, and try not to make a big deal about it.
cough Things that cough just don’t happen cough with cough frequent pairing. cough
Sorry, I have a cough 
But ya, Tuple is great! If I ever work in an office again at a company that pairs, I would want to try using it IRL. I think the pointer tools would be much nicer than people vaguely pointing and saying “Change that over there!”
I’ve been on a team like this and I will fight fiercely to never allow such a way of work no matter where I go. This is just a way to avoid offending people who should not be so sensitive in a professional setting to begin with.
How would your business people react if you straight up told them: “We worked 2 times more on this feature because X would feel offended that we ripped his PR apart and we would have made him rewrite 80% of it”? They would be very unhappy with that suboptimal resource allocation and they’d be in their full right to be unhappy.
As in marriage, conflicts should be resolved early, proactively and to their full conclusion. And if that means somebody leaves that’s actually a mid-term win for everyone in the company.
Every time I hear “pair programming” I can’t help but think of
I am coming from a place where any and all coding I do is a solitary exercise that at a minimum provides an escape from the social pressures required by my actual job. I am sure that in real professional contexts it serves to improve a lot of workflow and team dynamic issues. I can also see that as a an on-boarding or educational paradigm it would be fantastic. But as a daily exercise that took up most of my programming time – no thanks.
Human psychology and interaction is very complex. Sometimes it’s worth appeasing/tolerating an issue for greater value later, imo.
I firmly believe that happy, confident developers will produce better in the long run. We try to cultivate that confidence early on, and sometimes a part of that is handing out some easy wins.
Overall, I agree with your sentiment, and I didn’t mean to imply this is “good” or “commonplace”, it’s more like war stories from being in the industry for so long.
100%! I absolutely agree.
Still, a balance must be struck. Plus from one seniority level and above people know when their work is not up to even their own standards so there are no hard feelings.
I suppose the right disclaimer is: it really depends on the new teammate. I personally don’t get depressed by a lack of quick easy wins, provided that the team has visibility on what am I working on and how am I progressing. But I know that doesn’t apply to everyone so again, yeah, I agree completely with your stated goals.
I have experience with using pair programming effectively. I also have experience with pair programming being inefficient.
In truth, “pair programming” just describes 2 people trying to work together. It depends a lot on the people involved, and the states of those people are not predictable. Pairing with someone on a day when they have meditated, exercised, eaten well and felt at peace is a very different experience to pairing with the same person when they have problems in their life, even if it is just for that day.
Despite having lots (totalling 1000s of hours) of pair programming experience, both at the same desk and remote, I am loathe to form an opinion on “pair programming” other than: It should be used freely but never prescribed.
In the IT department where I work, the number of programmers is increasing, but I’m the only one who uses Elixir. Now, the IT leader has asked for pair programming and code reviews among developers. The obstacle is that most of them program in JS, and they know little or nothing about functional programming (some have developed with Ramda). Several posts have given me ideas on how to teach them some Elixir, along with explaining the logic of the code, but I still have doubts about where to start.
I think that starting with pair programming if they never wrote a line of elixir is a mistake, everyone has to take their time until the language “clicks” for them, at the very least they should understand clearly what is pattern matching and how processes work (I would leave recursion out of the picture at the beginning as it tends to bring more trouble than it is worth), otherwise you risk overwhelming them with information, since there are a lot of moving things in a real-world project.
