Anyone has experience with using pair programming effectively

Hey! We will be pairing or mobbing on all production code, and a Lead Engineer needs to be able to lead a team in teaching and coaching extreme programming practices.

Hearing about some academical practices is nice, I wanted to know more about practical implications of this from someone who used it successfully to solve a practical problem with actual efficiency results.

One of my first full time dev jobs regularly used pair programming, but primarily as a mentoring tool. Essentially the junior would talk through a new feature or bug report one on one with a senior, and decide on required changes, then observe the senior implementing those changes, asking questions and occasionally–ideally–making suggestions. After a couple weeks they would switch and the junior would “drive”, with the mentor mainly answering questions and making suggestions only when they observed the junior heading down a questionable path. However, the idea was that after a certain amount of time, the junior would “graduate” and start working solo, until they themselves were in a position to act as a mentor. So, obviously this was mainly a tool for “leveling” up juniors who often were not expected to have much if any experience with the framework (Rails) as efficiently as possible.

This job description makes it sound like pairing has a more fundamental role there, although I expect in principle it works the same, albeit with more role switching. I think the benefits are obvious. Two heads are better than one, right? And even experienced devs can occasionally misjudge, misinterpret, or plainly not know the best solution for a given problem. Hell, even in the mentoring model juniors would occasionally come up with great ideas the seniors didn’t, and you just can’t get the same benefit of that kind of mind-sharing with CR alone. The only disadvantage of pair programming in my mind is the resource cost. I really enjoyed my experience with it and honestly this would be a big draw for me if I was in the market for a new FT position.

This is very interesting approach. I had the possibility to teach elixir to juniors a few years ago, and I can relate that the biggest problem was not the fact that they didn’t know how to write code but it was the fact that their thought process was all over the place, I tried to discipline them at that time with small tasks, detailed review, however I think that pair programming would be much more efficient in that case.

This is why I saw it peculiar at that time, however I think that one of the reasons 2 seniors would do pair programming would be to either pass the company culture for writing the code or the philosophy of the ecosystem if the person comes from different background.

Pair programming definitely can work and is a much faster way to help train somebody. But not only that; as a senior I didn’t need much training in most of my positions in the last 7-ish years, however being onboarded in the quirky and company-specific practices definitely was faster when I have composed 2 separate merge requests together with the CTO or another supervisor.

And it’s done mostly as @tfwright described: leave the person to code, observe and don’t interject (a lot). Though that’s the ideal theory f.ex. I had a supervisor using vim with super minimal syntax highlighting and when we swapped places – he wanted to demonstrate how would he write a function – I had trouble following what was happening because it was almost as if somebody coded in Notepad (lol).

Still, it’s a very successful hands-on approach (when done correctly). And I’ll emphasize: leave various code styles and tastes out of it. You can ask “hey, why don’t you do this with with and not with a chain of small functions?” but don’t overdo it, and don’t ask too many of these because the main point of a pair programming session is to help somebody learn something on a higher level and not on minutia. (Though I’ve also been in a team once where they were pretty adamant about which Elixir idioms to use and which to never write.)

I have spent most of my career doing pair programming and I currently teach people how to do pair programming. For me, it’s probably the best method of creating code, but it’s not for everyone. It requires a fair amount of empathy and social understanding.

The biggest advantages of pairing are:

• You have another set of eyes to help you solve the story that you are working on
• Onboarding tends to be faster
• If you are doing pair swapping, it removes silos and allows all engineers on a team to understand the entire code base since they have all worked in every part of it
• Done properly, it removes the need for pull requests and, mixed with TDD, allows for trunk-based development
• Results in faster cycle time for stories and higher code quality

From my experience, pair programming can either be very productive and rewarding or a really bad time. And sometimes it’s just work.

To avoid having a bad time, make sure both team and management are ready to give it a real chance. A lot of advantages of pair programming are not obvious in the short term, but idle keyboards can look very expensive and seem non-productive to anyone who is not on board.

It’s also important to pay attention to who you are pairing with. Align your expectations for the pairing session. If it’s someone you haven’t paired with before, spend some time getting comfortable with the process and each other. Build trust before speed. This is more important if you’re pairing with someone who’s not on your level of experience.

If you are pairing with someone who has less experience with the codebase, it can be beneficial to focus more on learning rather than doing. And then it’s important to make sure you’re not just shouting syntax at your partner. Give them time to read up on the basics. This will give you time to sit and think ahead about the problem you’re working on.

If none of you are sure how to best approach the problem, it’s usually better to split up and do some research one by one (or ask someone who might know!). Long sessions of pair googling are (in my experience) neither effective nor fun.

It’s also not just about writing code. Talk through the problem you’re going to solve. Many times it’s more effective to start at the whiteboard, rather than at the keyboard. Spending 20 or 30 minutes to outline half a days worth of work is time well spent. And much better done in pairs than on your own.

When pairing works for you and your team, it is easier for any team member to jump into any part of the code to extend or improve it. You receive feedback on your work immediately, like squiggly lines in an IDE, so there’s no waiting for code review. You get a good sense of camaraderie, and you’ll know if someone on your team is not feeling well and needs some time to deal with life outside of work. It also keeps your team focused, so you’re not all working on different problems all the time.

I was on a team for 2.5 years where pair programming was our default—we did it all the time and the only time someone solo’d was when there were an uneven number of us. I enjoyed it immensely and found it mostly positive. It was far more about de-siloing, creating a shared style, and bonding than it was about mentoring. People paired up regardless of level and we actually switched pairs daily. This means that if a story took three days to complete then the two people who started it weren’t the same two people who finished it. This was rough to get used to but once we did it was great.

Also as mentioned, “pairing” in our definition didn’t mean you couldn’t decide to break off and think through things on your own for a bit. We actually wouldn’t do that too often but when we did we would still pair off each morning. This gives you a dedicated point of contact for the day.

Some of the downsides have been mentioned. One particular one for sure is that it’s exhausting, but I found it to be a good kind of exhausting. And of course, if you don’t get along with your teammates then it can’t work. You also have to be pretty mature about being able to reach quick consensus (ie, get really good at “disagree and commit”, which is a key skill to have even outside of pairing).

I see the big positives as de-siloing and shared ownership. There was no code that “belonged” to anyone. No one ever said, “I don’t want to touch that because it’s so-and-so’s code”. Also, no one was afraid to go on vacation because at least three people had fairly intimate knowledge of each part of the system.

Also in my experience pairing is faster than soloing. Again, this is something that is only true if you’ve developed a rapport with and trust your team members. When you get on other peoples’ wavelengths, however, you stop feeling you need all of that time alone to think through a problem and it becomes fun working out a solution with someone. Again, this can involve stretches of solo time where you split up then reconvene.

I could go on and on about this and have been meaning to write about it but still haven’t gotten around to it (I have a small draft… not counting all this, lol).

I was lucky enough to start my programming carrier at a team that did full-time pair programming. In a team of 10 to 15 people we switched pairs daily. In retrospect, this was an awesome way to learn a lot of the agile practices, and get to learn from more senior people on the job. It was great, but as mentioned before, could be very exhausting. After having spent seven years in this full-time pairing setup, I had to take a break after what could be called a burnout.
I’ve since learned that for my personality type (introvert, hsp, but seeking deep personal interactions nonetheless), pairing 100% of the time is just too much. I now have defaulted to a more adhoc way of pair programming. I still like to sit together and work on a problem with someone else. There were some great advices mentioned above to make this work. But I also like to work on my own, without someone watching over my shoulder.

One of the things I’ve learned is that some people are not a good fit with this kind of programming. They just can’t adapt or have a balanced way of communicating. Often it’s the “geniuses” that are awfull pairing partners (or team members in general). They have ways of bending their brains in ways I can’t imagine, which makes them solve very difficult tasks. But at the same time they have no incentive to simplify or adapt their solution, so it’s better designed or understandable by their mortal teammates. I’ll choose the better communictor with mediocre skills (but great potential!) over the lone genius cowboy every time.

I won’t ever go back to full-time pair programming. But I will try to do it whenever I feel there is a good opportunity (even if it’s just about education). I often won’t even call it “pair programming”, but I’ll just roll my chair to the other desk, and sit there for a few hours.
But since I’m not a group-thinker, I also need that time alone for deep work.

I also gotta re-echo statements here that pairing is not for anyone and no one should be forced into it. I do wish orgs would nurture it, though, perhaps having teams that pair and teams that don’t. This is a bit tough to get right, though the company I used to work at encouraged pairing but lots of teams didn’t. There was one team that even mobbed almost exclusively! I have a hard time with mobbing myself so yes, to each their own