39

We've been utilizing pair programming (or something like it) for a few years. As a senior engineer on the team - I find that pairing actually negatively impacts the team's throughput.

  • The common pattern is that more senior devs generally end up handholding more junior devs throughout the whole process - basically coding while looking at a screenshare. "Scroll up", "Add a console statement", "Go to file X", "Can you write Y after line Z", etc.
  • Side conversations often come up during pairing sessions, distracting away from the work at hand
  • Solving complex problems often takes much longer, because many engineers need heads down time to actually design a solution - doing so on a call takes longer and often results in analysis paralysis.

There are so many stories where I feel like I'm coding through someone, and a story that would have taken me 30 minutes ends up taking 3 hours, meanwhile, I question whether the more junior devs actually learn.

21
  • 6
    I'm not sure how to objectively answer this question. Can you clarify the problem you are trying to solve, keeping in mind that this community does not support subjective questions? Feb 22, 2023 at 18:54
  • 6
    Pair programming != training . When you develop in pair you should pair senior with senior and junior with junior. When you do training you should pair senior with junior
    – GACy20
    Feb 23, 2023 at 9:21
  • 7
    Pair programming != training however, it is possible to pair senior and junior. Sure training will end up happening and slow things down. But that's going to happen anyway. Doesn't mean effective pairing can't happen. Feb 23, 2023 at 15:16
  • 6
    I paired with an intern who had no idea how our system worked. We needed to talk to a printer and had code that sent the printer a command that needed to be recompiled every time you changed the command. I decided to turn that into a command shell. Explained what I was doing to the intern. Wrote up a bare bones version in front of him. Got to point where it was working and I was tired and said, "Want to take it from here?" "Sure!" He did great. Polished it up right then and there. Feb 23, 2023 at 15:19
  • 3
    @AntiGamer it sounds like your chief problem isn't juniors slowing you down. It's management over stressing you on productivity. Can't tell if that's them or you. Keep in mind, they really have no idea about the technical stuff. But if you feel like you're underperforming they always pick up on it and assume you're right. Feb 23, 2023 at 15:26

6 Answers 6

71

If pair programming makes you feel like you're an air traffic controller trying to talk down an air plane piloted by a fidgety 12 year old you're doing it wrong.

The reason that's wrong is because you aren't miles away talking on a radio. You're right there and can take the keyboard at any time. It should feel like being a co-pilot. You aren't giving over control because you have to. You're doing it because you can.

One thing pair programming is not is mentoring. A teacher-stundent relationship feels very different from two people working together as equals even if one has significantly more experience. It takes time to get used to pair programming so don't worry if it feels awkward at first.

extremeprogramming.org - Pair Programming

What you need to grasp is the point of pairing. It isn't so you can say "we were pairing". It's so you can communicate in your natural language: code.

The awesome thing here is you can type a line of code and ask, "does that make sense?" That's a tight feed back loop. You can sort out when code is too clever fast.

"Scroll up", "Add a console statement", "Go to file X", "Can you write Y after line Z", etc.

If this is all you're going to say while we pair then just take the keyboard already. Rather than spoon feed me a walk through, tell me what's going on. Why we're doing this. How I could have known to do this myself.

Tell me that. Don't just take the keyboard, click some mysterious keyboard shortcuts and make magic happen. Show me how the trick works.

Also, don't just dictate the entire agenda. Carve out work I can do. Let me jump in and be part of this. Hell you may get lucky and learn something from me. The keyboard should be sliding back and forth.

Side conversations often come up during pairing sessions, distracting away from the work at hand

Oh take a moment and be a human. Convince me I'm talking to someone who considers me a human.

Solving complex problems often takes much longer, because many engineers need heads down time to actually design a solution

True. Some need heads up time spent throwing pencils at ceiling tiles. Some need rubber duck time (a sounding board if you're of the silver hair set). Pair programming isn't for every problem all the time.

  • doing so on a call takes longer and often results in analysis paralysis.

Yes pairing can take longer than coding alone. But if you're doing it right you're also getting an instant informal peer review as well as some on the spot collaboration.

The easy cure for analysis paralysis is doing something stupid and making people explain to you why it's wrong. Iterate on that until you run out of wrong.

I question whether the more junior devs actually learn.

Keep questioning. Learn what works and what doesn't. There isn't just one perfect way to do this. But doing it only because we're supposed to do it is definitely wrong.

7
  • 27
    The easy cure for analysis paralysis is doing something stupid and making people explain to you why it's wrong. Iterate on that until you run out of wrong. this is gold... it works in any situation. Training your TDD & bottom-up design skills, doing in-site tech challenges or deciding between 2 movies you surely will hate but your gf doesn't care... just "do something", spin the wheel and let yourself be carried away by inertia
    – Laiv
    Feb 22, 2023 at 21:43
  • 5
    "The awesome thing here is you can type a line of code and ask, "does that make sense?"" And this is why pair programming is an utter waste of time. No competent programmer needs to ask that about a single line of code. You need to ask that about the entire coherent block of functionality, not a single line - and you don't have that until the programmer is done. It's based entirely on the belief that programming is the main source of errors in the end product, and this has been extensively proven to be a false belief.
    – Graham
    Feb 23, 2023 at 8:53
  • 7
    @Graham Often, a single line is a coherent block. Sometimes, it's represents a change to a single block, and I want to know whether it makes sense in context. Other times I've done something clever-but-obvious, and I want to know if it merits a detailed or a short comment. Be charitable!
    – wizzwizz4
    Feb 23, 2023 at 13:45
  • 19
    The irony here is I’m getting feedback on a single line and wishing I’d have gotten it sooner. Feb 23, 2023 at 14:12
  • 9
    @Graham I'm really interested in what you're saying about errors not primarily coming from the source code - do you have a citation(s) for that as I would be interested to learn more.
    – T. Kiley
    Feb 23, 2023 at 14:21
19

The common pattern is that more senior devs generally end up handholding more junior devs throughout the whole process

First of all, pair programming does not inherently entail tutoring or mentoring. With a sufficient seniority imbalance, you have to accept that a chunk of the time is spent on training rather than working. This should already shift your expectations of immediate results.

If you want your pair programming to be completely focused on delivery, not learning, then you have to pair equal developers with equal experience, or as close to it as you can. You're not doing this, so you're inherently either going to hamstring your seniors (by having to go at the junior's pace) or needing to instruct the juniors about the work (since it's being done at a senior's pace).

basically coding while looking at a screenshare. "Scroll up", "Add a console statement", "Go to file X", "Can you write Y after line Z", etc.

That's not pair programming, that's dictating. It's both unproductive as a delivery mechanism (it takes two people to follow one train of thought) and as a learning tool (blindly copying as you're told does not foster understanding).

I would seriously reconsider the seniority of a developer if they are only able to focus on how to fix an issue and are not able to properly guide a junior developer. That is the distinguishing difference between a junior (can do the work but needs oversight), medior (can do their own work without much oversight) and senior profile (can do their own work and provide oversight for others).

Side conversations often come up during pairing sessions, distracting away from the work at hand

Non-work-related conversations would've happened if these two people sat adjacent without pair programming, and is therefore not relevant when judging that value of pair programming.

Work-related conversations are precisely the point of pair programming; it allows the pair to convey their knowledge to each other and/or helps them work together to learn something that's new to both of them.

Solving complex problems often takes much longer, because many engineers need heads down time to actually design a solution - doing so on a call takes longer and often results in analysis paralysis.

First of all, it's not called pair designing. You can't just arbitrarily lump these two together.

Secondly, pair programming does not entail that both sets of eyes are looking at the same thing at the same time, all the time, and nothing else. It's perfectly possible for the senior to do something else, whether it is looking at the next task's design, reading documentation, ... while the junior performs a more trivial task where the senior is either not needed or is able to juggle both activities at the same time.


The basis for your question comes across as a confused one. You implemented a system, structured it a particular way, and only then did you start noticing that the system doesn't actually help with the things that are seemingly important to you. That's putting the cart before the horse.

It makes more sense to first understand the problem you're trying to solve, then look for a system, confirm that it would indeed solve the problem, and only then start implementing it.

1
  • "First of all, it's not called pair designing. You can't just arbitrarily lump these two together." -- I believe this cuts right to the heart of the OP's question. Not every task or interaction is appropriate for pair programming. Feb 24, 2023 at 15:38
5

I think that two pilots in the aircraft is the closest I can think, so let's have some overview how the problems you address are solved there. In aviation, then there are two pilots, there is a pilot flying and the pilot monitoring. The pilot monitoring is also fully in the course and can take over at any time. This works very well and is unlikely to change, even if technically these aircraft could be flown by a single human.

I am not myself a pilot, I am software engineer with long experience. But I used to be quite active on Aviation Stack Exchange, reading both questions and answers posted by real pilots, so think should be able to provide some overview. It may be useful for us.

Sterile cockpit

Conversations not related to the flight are strictly prohibited in the cockpit. Same should be between the pair programmers. As simple as that.

Decisions

Tiny decisions are made by the pilot flying, but the pilots communicate when making bigger decisions. Pilots also follow checklists that describe many standard actions they should take. If something goes wrong, the pilots pull out say "unreliable airspeed reading" checklist and follow steps there rather than starting from long discussion that should be done. If the Captain is absolutely sure, he has a priority to decide quickly, overriding any rules, any directions from the control tower and with no discussion but this is not lightly done. When the Captain disregards the instructions from the control tower, he must tell about this immediately.

Hence I expect the lead developer to have right for say something like "the approach X creates much better code exactly here, so we use it, even if general rules call for something different", but this should not come very often.

Work division

Pilots divide the time each of them controls the aircraft more or less equally but there are tricky tasks like flying 747 with three engines only or landing at Heraklion airport where it is officially stated that "the Captain must do the flying". Otherwise, both pilots are fully trained and qualified to fly that aircraft and do not need very in depth micro-management.

Hence I would expect the pair programmer active with the code to type and scroll as he wants, with another just observing and only interfering if he has notable thing to say. I also do not expect one of the programmers to be always typing and another just always watching.

Captain training

Finally, to understand the role better, a new Captain is first trained with another, more experienced Captain that is a "real Captain" of the aircraft but while the flight goes well, plays the role of the second pilot. After that, the young Captain is paired to fly with much more experienced (by the flight hours) second pilot. Only then the Captain is considered ready to fly with someone he may see as less capable.

Dual controls

Aircraft intended to be flown by two pilots normally have dual controls. To follow this pattern, it is a good idea to connect at least the second mouse if not the keyboard. This allows to pass the "driving" between developers very quickly.

0
4

If the two doing this are not roughly equals you don't get the pairing benefit, where the one doing the design does not get the immediate feedback from the one doing the typing.

A junior-senior combination should have the senior mentor or teach the junior. That takes time which it doesn't sound like you have at the moment, probably because you are not clear in your mind why you are doing this.

You may want to try having two senior developers doing this as an experiment. The outcome may surprise you.

2

I find pair programming the most valuable when hunting down a bug/problem. One person has been trying everything he can think of, a fresh perspective is required. Then with two different people you are more likely to find the culprit.

For writing something new from scratch I do not see a benefit. Then you will just need some constraints and a review.

0

One person writes the code, focusing on details like for loops and function parameter order, and the other person is keeping track of bigger picture things that the coder doesn't see because he is focused on the tiny details.

It's not really supposed to be for one guy microcontrolling another or for teaching someone how to code.

Not the answer you're looking for? Browse other questions tagged or ask your own question.