Pair programming – you'll never guess what happens next!

The only thing pair programming does

While I can see pair programming being useful for people joining the team, I really don't see any benefit to enforcing it. People naturally come together to solve problems and naturally divide when working on individual tasks.

Forcing it just slows everyone down to half speed. If I wanted to do that I can browse the web for half the time.

Dumb idea.

Good developers are by nature introverted beasts I think, plus there's always the thinly-disguised contempt for everyone else's perceived lunatic way of doing things.

the coding equivalent of design by committee

I imagine having to explain every single line of code written, as it was written, to someone hovering at your shoulder would be intensely irritating. Particularly when you are "in the zone". You really don't want to have to keep breaking your train of thought to vocalise your thinking.

And conversely, sitting at someone's shoulder without access to the keyboard, while they write code that doesn't look quite right and they assure you they'll "get back to explain as soon as I've finished it", would also be incredibly frustrating.

I'm all for peer reviewing, but pair programming sounds like the coding equivalent of design by committee. Hellish.

You mean...

... like this?

https://www.youtube.com/watch?v=u8qgehH3kEQ

It's probably a useful tool for neophyte programmers learning the ropes, but when I'm in the zone, I can code more efficiently than I can speak. I have been forced to try this idiotic method on two occasions, neither have turned out well, with mostly a "please, just shut the fuck up while I get this down" ... which basically lasted for 4 hours, by which time the pair has lost interest and usually glazed over, or it boiling with so many "why the hell did you do that?" questions ... its simply unworkable for experienced programmers.

Complementary Coders.

Done it a couple of times for short periods and it can work. If you match the pairing the properly.

I am not a keyboard wizard my typing speed and accuracy are slow compared to most others even with automatic syntax checkers. But what I think I am good at is mid-sized algorithms. I don't mean the Ins and Outs of tournamanent sort vs bubble sort or the big stuff of client server architecture, but ways to arrange classes into methods and properties that allow for generic design and re-use of code.

That's not me being arrogant, but because I don't write code fast, I tend to think of ways that mean I can write less code.

When I've paired with others who are keyboard wizards the net result has been worthwhile. They tend to write lots of lines of code quickly to acheive a result. It also means we can try ideas and accept or reject then very quickly.

I have been continually amazed at their production rate whilst on occasion I've had them say "How did you think of that?"

LIke all things doesn't suit everyone all the time but it can definitely have a place.

The problem was solved last millennium

I thought the ideal programming partner had been identified years ago.

Tried this by accident

I have a subordinate who buffed his CV a little and arrived with essentially zero knowledge aged 35 or so. I ended up sitting next to him at his desk typing in code for maybe 8 hours a week, and we developed a routine where he would correct spelling mistakes and remind me what file where things are defined in.

I'd credit him with supplying a 5% boost to my productivity, which is better than being of zero use (its not politically possible to sack him) as would otherwise be the case.

Obvious question on pair programming

What would Verity Stob do?

Humans are animals

The thought of being stuck next with a nose-picking degenerate developer with bad breath and BO appalls me TBPHWY.

People have different ways of approaching a problem, some will sit and think it out, others will start to write it out and change it as they go along. Some build often, others will build once they think. I can only picture myself ending a pair programming exercise in a fight.

startups

Are the statistics only gathered in young, dynamic startups with freshly selected people ?

I got talked into pair programming twice, in two different jobs. The first time they paired me to a programmer who couldn't reuse any preexisting module or even 3 lines of code without redesigned the whole global IT ecosystem.

The second time they paired me to an older person who had done no real programming in the last 10 years (but "architect" and "customer communication", and none too practical.)

Suck it and see

As the article says, it seems like an odd principle. But as someone who has paired for the last 8-9 years after 10 years without it, it's amazing the difference it makes to the quality of the work that's produced and the enjoyment of coding. Here are some examples of the kinds of things that regularly go wrong which can regularly be fixed

Just spent 20 minutes debugging something because a parenthesis is in the wrong place? Chances are your pair would have spotted it as soon as you'd typed it

Just implemented a requirement as written, then realised it was written ambiguously and you'd interpreted it incorrectly? Your pair might have caught it straight up

Just written a bit of code from scratch? Your pair may know of somewhere else in the system it's already been done

Hate looking at "Keith's" code because he codes like a nutter? Pairing will help beat the bad practices out

Someone leaves and takes a bunch of knowledge with them? Pairing spreads the love

Someone new joins? Pairing helps them get their feet under the table

Oddly, we've now started "loose pairing", where we pair where we think we need to. Guess what? Pairing has practically stopped, our bug rate has increased and our productivity has slowed

Try it, at least, before dismissing it. It works...

Why not try it?

It's funny how the disparaging comments on here right now are along the lines of "I have a hard time imagining ", "I can't see me", "While I can see", which *suggests* that most of the people who are negative about it haven't actually tried it.

As someone who has worked with a team that pairs, and has done for about 14 years, I'm not surprised.

Yes, we've had some developers join who didn't get on with it, but I've yet to find a developer that I fully trusted who didn't enjoy it. Over the years we've paired to increasing and lesser levels and we've found consistently that our velocity didn't change, though the programmers engagement always dropped in prolonged periods of reduced pairing.

I would suggest that, if you're working in an environment where you expect your developers to be able to talk to your BAs or your customers and collaborate with them to produce quality software then you need people who would, by their nature, be compatible with pairing - Why? Because sociable and respectful people get on with it, and find they actually enjoy working together.

I'd worry about the output of any developer who lived up to the stereotype and just wanted to sit in the corner and get the job done. But maybe that's just me.

So, to those who "can't imagine" - why not stop trying to imagine and actually try it for a few weeks. Then you won't have to imagine anymore - you'd actually know.

i dont like people

having them sit opposite me is annoying enough. having them sit next to me, talking to me, is a kind of existential hell for me.

Moderation.

Ive done 'some' pair programming, it has been useful for knowledge sharing, but i can only do it for short'ish periods of time. it actually turned out more like 'live peer reviewing' < [Copyright me, here + now..!.]

when im looking over someones shoulder your instinct to just take over is very high, (but that can irritate, but not doing it can be like torcher), esp when the person is doing something very different to what you would do.

I agree with the end quality agrument, but actual time saved im not to sure about as you have 2 people and more discussion time (much more usually), and i have had some VERY heated discussions where different approaches collide.

and yup when your being the dev, its odd, you feel like you need to share (so much), and the tangents you can go of on are mad. (but thats knowledge sharing for you i guess)

So in summary (from experience) combinations of minimal live peer and post peer reviewing on code is best for quality and mental state of mind. But you need to have your happy personal place to retreat to when the other person has made you start loosing it.

More difficult to scratch my balls with someone sitting next to me. I dont think it would help me unless they offered to do it for me whilst i was typing.

Why don't you

Suggest it to Linus Torvalds, see how well that goes?

... long time ago ...

We did pair programming in a class I took a decade (or two...) ago. Simple reason: computers were expensive beasts then. We did not rotate around, but thankfully the guy I got matched up with was intelligent - and we thought in similar ways, which became apparent when we could more or less swap places (only one keyboard) in the middle of a line. This was in the time before syntax highlighting and spell checking etc., and we were able to catch many small things. We also caught each other being too lazy to think about input sanitising, missing possible cases or being ambiguous. I actually miss that. It also helped both of us to be less of a lazy sod (until we finished the tasks, then we goofed off). I *especially* miss this aspect.

Blind spots

I believe it's possible to develop blind spots so even when re-reading you own code, you overlook a typo or logic error. So a code review by a peer, especially if a bug is suspected, can be priceless. Not the same as pairing but a useful compromise sometimes.

I see it like a Blaster-Master scheme...

One is typing, opening the trail with a blowtorch, laying down the thick code from a previous brainstorming session. The other is fixing the mistakes, checking for finer pieces of logic that get lost from the main idea.

Both are having ideas, and kicking them back and forth. And mutual cheering up to avoid boredom and distractions is deeply involved in the situation.

As I wrote school work in a team back in the day, we would often do that, with one of us typing the gist of the work furiously, while the others were thinking about the details, like fonts, paragraphs, and sequencing the whole thing in a logical fashion, like a backseat driver that has time to look down to a GPS while not caring if he is running a red light.

It was exhausting, but perfect for pushing those tight schedules. I think that coding could work like it.

Give it a shot

Personally I've found pair programming to be quite useful in certain situations. Adding a new member to an existing team has almost always been a smoother experience for everybody when pair programming has been used. The same goes for things like a major refactoring efforts or simply trying to solve a particularly hard problem.

The thing to realize is that it's not something you do constantly. You can start and stop several times per day if necessary. Do it when it feels right.

I would also like to add that if anybody thinks the physical typing in of code is a major part of coding you are very mistaken. Figuring out what to do and how to do it is always the bigger part of the whole and this is the exact part where two programmers can be more than the sum of their parts. Additionally, I personally am of the opinion that pair programming ends up boosting output simply through people becoming less fatigued compared to solo efforts. So the time used is used more efficiently and there tend to be less facebook/coffee/ball scratching breaks.

I also find the idea of the "best programmers" being "introverted beasts" laughable. There surely are cases where the actual work being done is very difficult, but it is almost never the case that an "introverted beast" would be considered superior over an above-average programmer with decent social skills.

Here's a simpler, less onerous approach

I had someone describe a different technique to me a few decades ago that, I think, captures some of the benefits of pair programming without, you know, actual pair programming:

At the end of the day, grab a fellow programmer and go over with her/him all of the code changes you've made that day.

In that case, the pairing is maybe 15-30 minutes (if that), and you will, in fact, code more intelligently and cautiously if you're going to have to describe what you did (and why) to one of your fellow programmers at the end of each day.

Good luck

Good luck finding a company that will let you buy new cubicle furniture designed to support pair programming.

It doesn't work with 'regular' cube furniture.

Finding the right pair is key

And there's the rub. It is a difficult management problem. I approach it as a mentoring/tutoring situation. Pair an old coot with a young coot but do it sparingly. Far better are simple informal side-by-side reviews (as one person wrote).

Too much cynicism.

I have done the pair programming thing a few times and sometimes it works and sometimes it doesn't.

Probably the most successful case was on a change in a highly complex system with an incredibly tight deadline. Two pairs of eyes and two different view points genuinely helped. The fact that we both had indepth knowledge of different parts of the system that were affected save our behinds.

It also depends a lot on team dynamic. When both developers have mutual respect, bring value to the table and can defer to the other without worrying about ego it can be incredibly productive.

What's next?

Clearly, what's next after pair programming is ménage-à-trois programming....

There are times it works and times it doesn't

Working through a difficult problem with someone who has a different mind set from you is a great way to get the guts of a problem hashed out - doing it 100% of the time would just be painful!

I probably spend about 10-20% of my time pairing with people when we have a hard problem to get done, once the direction is clear and the hard problems are overcome then the coder can get on with the implementation - this seems sensible!

If this technique stops programmers obfuscating C++ too much then I'm all for it.

- it's not about the journey guys, it's about actually finishing the product.

Reality check someone please?

Oh boy, where do I start ... I apologise in advance if this sounds like a rant (because it is ;-) ).

Coming from the other side of the table, operations, and having worked very closely with developers for some 20+ years, most comments posted here just confirms my long established view that (most) programmers are just average talents with very inflated egos.

As the recipient of, and responsible for, actually hosting and running all the crap that leaves the development department I can safely say that a vast majority of you (yes that includes you!) are just average programmers and produce somewhere between mediocre and fairly decent code. Seldom do I encounter truly brilliant code, and I say that despite having had the pleasure of working with some very gifted and talented people through the years.

To all the statements along the lines of "doesn't work for me" and "I do it better myself" (yes, especially that one) I say, total and utter BS!

Being in your own "little bubble" or "in the zone" is exactly when YOU make all the same mistakes that you accuse your potential co-programmer of doing and that you find so annoying. You are no better, period. That is what my experience, from the real world, tells me.

Heck, talent is normally distributed according to the classic bell curve and still, by the sound of the comments here, it sounds like you all belong to the upper 10% of the talent curve.

I believe that not for a second. To every commenter here that silently thinks "But I'm smarter than those around me and I wouldn't make those mistakes", I have news for you, you're not and yes you do!

I had the pleasure of working in a shop that used XP and DevOps long before the terms were even minted and popularised (as so many other things IT these are old concepts) and from real concrete examples I can say that pair programming does indeed work. It has the potential to produce great quality, scalability and robustness. Especially the last two properties are highly desirable when you actually go to production.

A vast majority of programmers are (almost) clueless as to how their code will behave in production and how it will integrate and cooperate with other parts when you assemble everything into a complete system. Having the combined knowledge and expertise of two people analysing the same problem is very valuable for producing a solution that actually works.

By my own estimate, maybe 10-20% of programmers "get it" and can see and think in terms of the whole picture and design and code accordingly. The rest of you just type away at your own little local problem and don't care about or ignore what the universe around you looks like and how it works, thus producing code that just barely fit together and requires duct tape to do so.

When it comes to building systems and not just snippets of code, most programmers are in reality quite bad at it.

Pair programming has the potential to catch and remove bad or outright incorrect logic, algorithms and behaviour early and save a ton of headache later on. People in general are lazy (at least I am) and programmers are no exception. You cut corners and skip steps that really would have helped the overall quality of your code. Having someone constantly scrutinising your work makes it harder to get away with that unnoticed.

Other obvious benefits have already been pointed out elegantly by previous posters.

Having said all that, I do of course recognise that it is not a silver bullet and you have to be conscious of when it is appropriate to use and how you pair people to make it work to your benefit. But many of the objections raised here I put down to people actually not having tried it and, perhaps, to some degree fear that your own comfortable and lazy way of doing things might actually reflect badly on you if someone was watching how effective you *really* are and what you are *actually* doing all day long (like checking FB and other non-related stuff). It is indeed comfy inside your own little bubble.

If it turns out that two people in a pair is just as efficient as you and your colleague are on your own, what does that say about your own programming skills?!

More people would be challenged, and become better (or even great) programmers by stepping outside that bubble and interact more.

Some of the best quality code I've seen was produced using XP and DevOps in concert.

To balance the sheet I have also seen some really horrible code make it into production, especially stuff coded by (young more often than not) programmers who thought they knew best, when in reality they didn't have a clue (and yes, that is just as likely to include you dear reader).

In short, more programmers would be better off taking a step back and taking a humble look at how good your skills and methods *really* are in comparison to others. Chances are you are just average Joe and not John Carmack.

Pair programming is one tool, among many, that can produce solid, measurable results when applied correctly. It is there, try it, use it, or reject it as you may, but don't dismiss it right away or for the wrong reasons.

I only tried it at Uni, but the thigh rubbing young ladies were just too distracting. Painfully so.

Nothing new under the sun

Anyone remember Brookes and "The Mythical Man month". He wrote about ego-less programming of which pair programming is just one variant. This was back in the sixties. Even then it was shown to produce better code.

Works for Debugging

Tightly integrated group looking at the same data across timezones works for difficult problems. Makes no sense for simple stuff.

For classical mosh group programming:

There is no reason to share physical space, all one needs for cheek by jowl programming is audio, a lot of monitors, suitable networked comms, suitable personality traits (giant egos need not apply), and NO INTERRUPTIONS. That last is a killer, smartphones, bosses, people walking in, instant messaging, email, and POTS conspire to wipe any synergistic gains out. If you can't focus on the job at hand, don't bother.