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

Of all the agile practices out there, “pair programming” is the one that elicits the most heckles, confusion, and head-scratching. The idea is that rather than having one person sitting at a screen, coding, you have two who program together. Those who practice it speak of it like most people do of their first time at Burning Man …

  1. Khaptain Silver badge

    The Perfect Pair

    Well, as much as I can understand the theory, I have a hard time imagining working as a pair.

    Why, because I am not compatible ( notice how I didn't say that they weren't, I assume my statement).

    As much as I don't want to work with someone I else I do appreciate being able to discuss/talk with someone else when the occasion arises.. which I find very useful.

    As programmers we are often in "our own little world" and to be perfectly honest, that's where I like to be, in my own personal bubble, as it helps me concentrate and improves my conception of the problem at hand..

    On top of the that, I talk too much.. which would simply disturb the "other" one...

    Horses for courses, if some people produce better code that way, then why not, but I do not believe that is the best solution for all.

    1. Adrian 4

      Re: The Perfect Pair

      Got to agree with that. I can't see me cooperating over a single screen. Trying to be open minded though - it might work with a pirate pad (a shared document). Two people working on the same document simultaneously - probably not fighting over every input but modifying chunks of code nearby to each other.

      I've also found pair-debugging fairly effective. Because both are thinking rather than typing, you're working in parallel rather than taking turns.

      1. wowfood

        Re: The Perfect Pair

        I would agree on the pair debugging being effective. We do it quite often where I am, althoughnot with the intention of pair programming.

        Nobody here really does pair programming though, only debugging. We tried pair programming or a while but people here just don't work well that close to each other.

    2. Anonymous Coward
      Anonymous Coward

      Re: The Perfect Pair

      I work ok in a team, but like to be left alone to get on with things. Constant interruptions from "the other half" would leave me wanting to punch their lights out by the end of the day.

    3. Rich 11

      Re: The Perfect Pair

      Fortunately for all concerned, there's no-one in my department to pair me with. The last person who came close to having both the time and the skills emigrated in 2008. Not my problem if they decided not to replace him (luckily for them I haven't fallen underneath a bus yet).

  2. DrXym

    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.

  3. Alan Bourke

    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.

    1. Rob Baillie

      Re: Dumb idea.

      I would class myself as a good developer, and I work with some very talented people. I have also mixed with some truly inspirational developers over the years, none of whom were "introverted beasts". That's just a lazy stereotype.

      Good developers respect other good developers and can see the value in their ideas and designs.

      Developers who can't see and listen to alternatives aren't good, they're dogmatic.

      1. lythamlatic

        Re: Dumb idea.

        The lazy stereotyping here is your own. Introverts can be inspirational, exciting, and can provide leadership - to assume that people who can do that sort of thing have to be extroverts is misunderstanding the distinction.

    2. TaabuTheCat

      Re; Dumb idea - Nope. Stereotypes.

      Credit where it's due - I saw this on a Reddit thread and I'm glad I did. This is the closest I've ever seen someone get to describing us.

      1. dbayly

        Re: Re; Dumb idea - Nope. Stereotypes.

        Upvoted as thanks for that link. It is pretty well spot-on in my experience (40+ years).

  4. Just Enough

    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.

    1. VinceH

      Re: 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."

      "And conversely, sitting at someone's shoulder without access to the keyboard [...] would also be incredibly frustrating."

      Both of these are problems that have already been solved.

    2. Mark 65

      Re: the coding equivalent of design by committee

      I can see the benefit of one person writing the tests and the other the code, maybe.

  5. Johnny Canuck

    You mean...

    ... like this?

    1. Joseph Haig

      Re: You mean...

      Or maybe like this:

  6. JosephEngels

    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.

    1. DanDanDan

      > boiling with so many "why the hell did you do that?" questions ... its simply unworkable for experienced programmers.

      If your code is not understandable (or not commented), then it's not maintainable. I can see how pair programming would lead to more maintainable and hence bug-free code.

      1. sabroni Silver badge

        As someone wisely quoted on here recently, we need to stop thinking about coding as being a way to tell computers what to do and start thinking about it as a way to explain to other humans what we want computers to do.

        In some performance critical situations it may make sense to write dense, obscure code, but most of the code being written today is business related and an emphasis on it being understandable is much more valuable than shaving a couple of percent off run time.

        1. coderguy

          I forget where I first read it, probably D. Knuth.

          "Code should be written so that it obviously contains no bugs, instead of the norm. My code contains no obvious bugs."

  7. kmac499

    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.

  8. Flocke Kroes Silver badge

    The problem was solved last millennium

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

  9. tojb

    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.

  10. Anonymous IV

    Obvious question on pair programming

    What would Verity Stob do?

  11. James 47

    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.

  12. Marco van de Voort


    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.)

    1. Just Enough

      Re: startups

      The studies are based on research projects using students. So pairs of relatively novice programmers, of similar age and experience, working on 100% fresh code, short term, and are students.

      So not really anything like real development.

  13. scottwilson

    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...

  14. Rob Baillie

    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.

  15. Anonymous Coward
    Anonymous Coward

    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.

    1. Anonymous Coward
      Anonymous Coward


      Because we fucking love you!

    2. Anonymous Coward
      Anonymous Coward

      Re: 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.

      Indeed! What is the world coming to?

      First people try to talk to me on the Tube, now at work?

  16. Kirstian K


    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.

    1. steogede

      Re: Moderation.

      > 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)

      I can fully appreciate how it must be torture, not being able grab the keyboard and fix all those mistakes :)

      1. This post has been deleted by its author

  17. ritey

    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.

    1. Measurer


      You can keep both hands on the keyboard

    2. sabroni Silver badge

      More difficult to scratch my balls with someone sitting next to me.

      Your testicles are so big that people sitting next to you get in the way of you scratching them? I think you may need to see a doctor...

  18. Kevin McMurtrie Silver badge

    Need to pair up on pair research

    There's a reason why pair programming studies are rare - it generally doesn't work. It has to be a specific type of task with the right people doing it. Good programmers will grab somebody for opinions as needed. Mandate full-time pairing and most of your staff will leave. The remaining two people will be the data for yet another report about how awesome pairing is.

  19. Measurer

    Why don't you

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

    1. The First Dave

      Re: Why don't you

      I'm not quite sure what you are getting at there - no Linus won't like it, but will it improve his output? Probably.

      1. Khaptain Silver badge

        Re: Why don't you

        Now you know where the notion of a "fork" came from :-)

  20. Joe Werner Silver badge

    ... 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.

  21. Nifty Silver badge

    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.

  22. Anonymous Coward
    Anonymous Coward

    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.

  23. fizz

    The right pair

    My personal experience, having tested on my own skin both successful pair programming experience and unsuccessful ones, is to find the right programming pair.

    I tried first with a good programming partner, and the level of success we had was astounding: our productivity was unbelievable, as working in pair made the experience funnier, kept us focused, reduced enormously the chance of bugs.

    Often we managed to achieve the results right at the first try, without any debugging being necessary.

    Even problem solutions were smarter, as my nitpicking was compensated and compensated his pragmatic approaches.

    Then I tried with others, even friends, and the experience were jarring: endless wars and discussions about every single line of code, lost time, messy code, or no contributions, passive acceptance and almost no utility.

    So my conclusion is, pair programming is wonderful, but with the right person, or at least one of the two must be very good at interpersonal skills.

    1. Tim Seventh

      Re: The right pair

      I agree. I mean I could just simplify this into like preparing for BBQ night or baking a birthday cake.

      Let's say if there's going to be a BBQ night and I've ask my best pairing friend, we would be on-paired for the whole process. In preparation like setting up the tank and carrying coal to seasoning steaks for cooking, we would be increasing our productivity during the process and might even be enjoying ourselves.

      However, if it's a BBQ night and I am being paired with some (long lost?) family member who claimed to be the best chief, then it became a struggle for war. I would be bring coal and he will be asking for wood. He would be cooking at median when I said to leave them median rare. In that case screw the productivity, it will be funny to even get to the start of the night. It'll be a mess.

      It's sort of like true team player vs solo player. Some are better paired together than others.

  24. Call me Trav

    But that's not what happens...

    The article states:

    >> So, while it feels like there’s a “halving” of developers by pairing them up, as one of the original pair programming studies put it: “The defect removal savings should more than offset the development cost increase.”

    Development cost increase? No, that's not what happens...

    If a department has, say 20 programmers and Management decides to implement Pair Programming, they don't go out and hire 20 more programmers... They pair the existing ones up into 10 pairs. Then they hold meeting as to why it isn't working.

    As I grow older and (hopefully) wiser, it is getting harder and harder to just accept the implementation of every new idea that Management reads in "Management Boy" magazine weekly. I already work well with others, shower daily and I am almost always minty fresh. Just let me do my work.

    Can I get an "Amen!"

  25. stourwalk

    It can work...

    When I was a young(er) person I regular practiced 'Extreme Programming' as it was called back then and even today actually enjoy pair programming far more than solo programming. I have a very analytical brain and can solve the problems and know what I need the code to do, but don't always know the right way to write it these days in the new fangled languages... Pairing me up with a younger whippersnapper who can work with me produces much better code than either of us would do independently..

    Icon because I'm obviously the oddity round here (aren't we all though?)

  26. giin

    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.

  27. bfwebster

    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.

  28. Anonymous Coward
    Anonymous Coward

    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.

  29. Anonymous Coward
    Anonymous Coward

    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).

  30. oldtaku Silver badge

    In moderation it's great

    Sometimes pair programming is way better. We do a thing in the office where you just call anyone over for a bit of shoulder surfing when you know you're in something finicky and you need a second set of eyes. Everyone's motivated, the backup guy gets to learn a little more about another part of the codebase, they often will catch something, productivity is had.

    But like so much else in Exxxtr33333m3!1! Programming they turned it into this stupid religious thing where if it's good in small doses then it must be even better 24/7 and we'll make it a Commandment.

    We tried full days for a bit (why not?) and found productivity and motivation were lowered overall. There's nothing like sitting there watching someone else do tedious boilerplate shit and telling him when he typoes (because you're so bored), and there's really nothing like having some a@#hole telling you every time you typo before you can correct it. Or well, it's 5 PM, I was going to stay a little longer and try to get this feature done, but OH WELL I GUESS NOT. You're taking two productive guys and getting maybe 1.2 guys out of it.

    Also, it should be perfectly legal to strangle someone to death who doesn't know the keyboard shortcuts for a program they use every single day.

    Anyhow, do it when you think it'll help and it'll be an amazing experience - or you can turn it into a tedious counterproductive chore by making it mandatory.

  31. BrendHart

    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.

  32. Sam Adams the Dog

    What's next?

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

  33. Daniel Voyce

    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!

  34. Anonymous Coward
    Thumb Down

    If I tried to enforce pair programming in my team

    There would be more pints of blood spilled than lines coded.

    Programming should be considered like masturbation: a solitary persuit that can lead to a beautiful feeling, a real sense of release, and the chance of a god awful mess at the end.

  35. Zot

    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.

  36. Mortimer

    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.

    1. This post has been deleted by its author

  37. Anonymous Coward
    Anonymous Coward

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

  38. foo_bar_baz
    Thumb Up

    Pair programming? So last decade

    Mob programming Moar is betta!

    And for the "geeks are introverted" crowd: Mob programming for the introverted

  39. Nigel Titley

    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.

  40. Speltier

    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.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon