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.

candied_orange
  • 102,279
  • 24
  • 197
  • 315
antonpug
  • 561
  • 4
  • 5
  • 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? – Greg Burghardt Feb 22 '23 at 18:54
  • 2
    I've worked on safety-critical software. Stuff fails, people die. None of the places I've worked have never used pair programming. So if your people have some belief that it works, ask for evidence. MISRA doesn't want it, DO178B doesn't want it. What they want is reviews - and pair programming is not a review process. – Graham Feb 23 '23 at 08:49
  • 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 '23 at 09:21
  • 2
    @GACy20 I echo this. For OP, you might be conflating training with pair programming. The most productive sessions I've had in my teams when I was paired with one expert (ex: an expert at shading) with me (I hope I can count myself as an expert in image and mesh processing). Together we designed the most effective texture pipeline that I couldn't have possibly done on my own, and he couldn't have possibly done on his own, since we have gaps in our expertise. But we weren't training each other so much. We were just filling in some gaps we had in each other. – Anti Gamer Feb 23 '23 at 14:46
  • Like you don't pair Maverick with a rookie in Top Gun or else Maverick will waste so much time training the rookie. You pair him with Iceman. Pair programming should operate on a similar hierarchical level of skill, experience, and I dare say even like-mindedness. Some level of contrast is good, but you don't pair a Michaelangelo with someone who is still trying to figure out how perspective works. That's going to be so counter-productive making Michaelangelo have to teach the basics in your team which is even the most mediocre artist can do and an inefficient use of him. – Anti Gamer Feb 23 '23 at 14:48
  • 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. – candied_orange Feb 23 '23 at 15:16
  • 1
    @candied_orange It's a tough balance in my experience! Maybe I just haven't found the right team yet. I really love training, but not when I'm expected to deliver at the same rates I do when I'm not training. So my dream is to train but sometimes we just have to ship, and I think that's when pairing junior with senior can be so counter-productive. Companies shouldn't operate this way, but either I've had the worst luck or almost all do in my experience. They don't realize the value of training. – Anti Gamer Feb 23 '23 at 15:18
  • 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. – candied_orange Feb 23 '23 at 15:19
  • 1
    @candied_orange Actually my company experiences are sorta horrific in terms of their stinginess. For example, I worked for one which had millions of customers but our build server for OSX was running on the cheapest iMac. We were waiting 2 hours sometimes in queues to build our C++ code on it when far more powerful hardware was available and for less than what they paid each of us per month. It's so silly -- anyway, I hope you'll forgive my rambling. I really think at least my side of the industry (realtime computer graphics) is doing things so wrong. – Anti Gamer Feb 23 '23 at 15:22
  • 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. – candied_orange Feb 23 '23 at 15:26
  • @candied_orange Definitely so! I look at training people as an investment, and these days I'm getting old so I think maybe if the company could give me just a little bit more time training, I will create for them someone far superior to me. They are all so sharp and bright. But the idea of this "investment" as I see it doesn't seem to click with my superiors. Some can't even be bothered to buy proper hardware for build servers. – Anti Gamer Feb 23 '23 at 15:28
  • 2
    @AntiGamer professionals take responsibility for doing things no one asked for because they know they provide things someone did. Training can be as informal and simple as telling someone where the bathroom is. Don't worry about your superiors approving you providing help unless they've told you not to. Long as you get your stuff done. – candied_orange Feb 23 '23 at 15:35
  • 1
    @candied_orange I think one thing I did wrong my entire life is that I really navigate the most bare minimum dangerous zone for time estimates. Need a cutting-edge path tracer that beats everything in the film industry? 6 weeks! A sane estimate is more like 10 years. But I have come to deliver on those estimates, and always without sleep, and my company expects me to continue to deliver time and time again. So if I'm paired with a junor who doesn't even know how spatial indices work, and I'm still expected to deliver the next cutting-edge thing 2 weeks from now, I'm screwed. – Anti Gamer Feb 23 '23 at 15:42
  • 2
    @candied_orange It's also something I find I'm doing even with my wife. Like I love her so much but I think it is time-consuming to be married now with a family. I could be spending more time programming and I haven't properly factored in marriage just yet into my programming time estimates, since I always assumed I didn't have a wife before. I still want my wife but I made my whole life about doing things better in a fraction of the time that everyone else requires since I made my estimates as a bachelor working 120 hours a week, and not a married man whose wife wants to spend time together. – Anti Gamer Feb 23 '23 at 15:46
  • Let us [continue this discussion in chat](https://chat.stackexchange.com/rooms/143115/discussion-between-candied-orange-and-anti-gamer). – candied_orange Feb 23 '23 at 15:55
  • 2
    @Graham Regarding "MISRA doesn't want it, DO178B doesn't want it." Sources for this? I too have worked on safety-critical software, and while I am not a fan of pair programming ("not a fan" is an extreme understatement), it would be good to see evidence behind those claims. While MISRA and DO-178 B/C do care about what the development process produces, including an end product that works to spec and only to spec, they do not dictate how the development process works. Agile and related techniques can be and have been successfully adapted to the development of high reliability software. – David Hammen Feb 24 '23 at 10:27
  • 2
    Possible duplicate of https://softwareengineering.stackexchange.com/questions/93820/pair-programming-how?rq=1 – Michael Freidgeim Feb 24 '23 at 10:45
  • @DavidHammen Sadly they're paid-for standards. They very much do specify the process, because the point is that safety isn't something you tack on the end. So they do specify requirements for requirements traceability, reviewing, and the level of testing required (especially DO-178B), for a given SIL. Pair programming is only considered as another way to do reviews. – Graham Feb 24 '23 at 14:14
  • 1
    @Graham: David's correct. And the standards certainly do not specify pair programming as a way to do reviews. That sounds like some manager hoping to save the cost of doing software inspections (which are much more than reviews and cannot be replaced by pair programming alone) – Ben Voigt Feb 24 '23 at 15:17
  • 2
    Pair programming done right is certainly more than merely "another way to do inspections" it's also another way to do collaboration. It's also not the same thing as a formal peer review. It provides vital feedback timely but can cause problems due to the role being different. As a fellow author of the code your pair partner is subject to [the curse of knowledge](https://en.wikipedia.org/wiki/Curse_of_knowledge) and [go fever](https://en.wikipedia.org/wiki/Go_fever) same as you. Your pair gives you a warm reading of the code. Your peer reviewer gives you a cold reading. These are not the same. – candied_orange Feb 24 '23 at 17:13
  • 1
    As you mention "screenshare", could you clarify whether you are sitting at the same computer or doing this remotely? – Paŭlo Ebermann Feb 25 '23 at 00:35

6 Answers6

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.

candied_orange
  • 102,279
  • 24
  • 197
  • 315
  • 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 '23 at 21:43
  • 4
    @Laiv The ultimate authority in any meeting resides in a flipped coin. Always bring a coin if you want to get out the meeting in time for lunch. – candied_orange Feb 22 '23 at 21:48
  • 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 '23 at 08: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 '23 at 13:45
  • 19
    The irony here is I’m getting feedback on a single line and wishing I’d have gotten it sooner. – candied_orange Feb 23 '23 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 '23 at 14:21
  • @T.Kiley have you ever heard the say "it's not a bug, it's a feature"? – Laiv Feb 25 '23 at 11:39
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.

Flater
  • 44,596
  • 8
  • 88
  • 122
  • *"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. – Greg Burghardt Feb 24 '23 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.

h22
  • 905
  • 1
  • 5
  • 15
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.

Thorbjørn Ravn Andersen
  • 1,297
  • 10
  • 14
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.

Martin Maat
  • 18,218
  • 3
  • 30
  • 57
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.

CaptainCodeman
  • 1,895
  • 2
  • 15
  • 14