I’ve heard about pair programming only when working at my last job, seemed peculiar for me at that time but it seems that more companies are adopting this: Lead Elixir Engineer - Maersk, Copenhagen, Denmark .
It would be interesting to know if you have any experience with this and where would you use this technique (for example when teaching or introducing a person to the project) and if it is effective or it just a different way to write code?
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:
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 
I find it useful for brainstorming through complex problems. It is also useful for combining code review with programming, which can sometimes be faster than the time it takes for a code reviewer to understand your code without any pairing.
Yeah, exactly. I can’t use pair programming 100% of the time, it exhausts me mentally and physically and doesn’t allow for creative alone-time when you are trying to figure out a problem (somebody more experienced in the said problem directly telling you the solution does not exactly inspire you to think).
To me pairing was indeed most useful for:
I respect people who use it all the time but I suppose I always found companies that are scared to use 2 devs for what they perceive only 1 should be able to do, don’t know. But I am also glad I wasn’t forced into 100% pairing.
If I wanted non-stop interaction I never would have migrated to remote work in the first place. 
I would have stayed in offices.
This was a big thing I didn’t mention. Really I just put it as “we don’t do code review when pairing”. This is one of the contributors to pairing being faster. I personally really hate code reviews. Obviously you need them if something was written by one person, but if done properly you’re pulling someone off of what they are doing so they can start reading and trying to understand brand new code. Then you get into covos like, “Why didn’t you do it this way?” “I thought of that but because of this I couldn’t” and so on and so forth. Those convos are much better to have with two people with the same context while the code is being written. At worst code reviews are people being pulled off of what they are doing just so they can say “LGTM!”.
Of course, I’ve never worked somewhere that had a really good code review process.
I personally am not a fan of pairing sessions that go on for longer than 15 minutes unless both of you are in a good groove and find it productive. Pairing sessions also don’t always need to consist of pure coding.
My process is usually:
I actual like it for brainstorming deep technical problems like designing a library, before thinking alone, and then breaking off and polishing after coming up with a direction sketch.
I won’t add too much because a lot of good information has already been posted here.
One thing I want to add is that a lot of people are commenting on “I” do/don’t always like it. I’d like to argue that things like pairing and especially mobbing (or known as well as ensembling/teaming) is that it’s not optimised for personal productivity but for work/ team effectiveness.
It’s not something intuitive but personal productivity of every developer in a team doesn’t lead to the best team productivity necessarily.
This is so important and why I don’t focus on the mentoring aspect when talking about the merits of pairing. For example, @linusdm said:
In my mind, letting this person run wild on their own is about as bad as telling a junior to solve something however they want. I don’t want this person on my team or even in my org if they are going to demand to work solo all the time and produce work only they can understand. I’m just speaking personally as someone who prefers to be in collaborative environments—lots of orgs are full of these people, I just don’t want to work there 
In my opinion it is awkward. There are ways to collaborate and share knowledge without having to be beside each other while coding.
I also found (in my experience only) that orgs adopting this tend to also encourage “collaboration” in toxic ways. i.e. accepting poor solutions that you know will cause prod issues to not hurt people’s feelings. Or giving medal of honors to people for creating poor solutions and then sacrificing their nights/weekends fixing them when customers are affected.
edit: sorry I didn’t mean to reply to you directly. just meant as a comment in general. not sure how to fix it.
Ya, like any methodology it is easy to get wrong. Like I had a very good experience with Agile because the org I worked at studied the material (ie, they RTFM’d) and understood how to use the framework without drinking too much Kool-Aid. All my other experiences with Agile have been orgs blindly adopting random SCRUM practices and forcing everyone to do them without truly understanding why (for example one place story-pointed everything, often multiple times, but no one ever looked at them). It’s the same for pairing.
For what it’s worth, my experience was not at all like you described. My 100%-pairing job is the only job that I never once had to work evenings or weekends—unless I got pinged while on-call which, btw, happened only once in my 3.5 years there. Working outside of office hours was actively discouraged and if you did it anyway, you would receive no accolades for it. Places that like are rare, though.
And ya, I think it’s impossible to delete a “respond-to” mention. I’ve accidentally done that several times before.
© Copyright Elixir Forum | Terms | Privacy & Cookies
