12 ms·

On Pair Programming

156 points by joeyespo 7y ago

forgotmypw38 7y ago
I fake it by doing a screen capture of myself working and then playing it back.
- coralreef 7y ago
  Who are you fooling with this screen capture? Your programming partner?
  - drdeca 7y ago
    Perhaps by “fake it” they meant “emulate it” rather than “deceptively produce the appearance of it”. This would allow one to double check ones actions in order to notice and correct mistakes one made the first time?
simonw 7y ago
I'm always slightly surprised when I see an article on martinfowler.com that isn't by Martin Fowler. I can't think of many other personally-branded domains like this that feature guest author content so often. ... which is really me distracting myself, because the guest content is usually of a very high quality. Maybe the personal branding is justified here because Martin Fowler curates and edits the pieces?
- simonw 7y ago
  https://martinfowler.com/aboutMe.html https://martinfowler.com/aboutMe.html helps explain what's going on here: > As the site got more popular, I felt I could use it to help other people get more visibility for their writing, so I've steadily increased publications from others here. I vet each article before accepting it - and often do a considerable amount of developmental editing too - so there isn't a high rate of publication. I do believe, however, that the quality of the articles matters much more than the quantity.
geophile 7y ago
If forced to choose between pair programming and not programming at all, I think I would choose the latter.
- oarabbus_ 7y ago
  Why?
  - artsyca 7y ago
    I'd venture 99% of pair coding is done by people who don't know why they're even doing it and set themselves up for failure at the outset ultimately crying sour grapes
  - downerending 7y ago
    Not OP, but for me, it's like having someone stand over my head with a pot, banging it with a spoon incessantly. It utterly destroys my ability to concentrate. Had a chance to closely observe a session once. Looked through the code later--total garbage. Apparently it works for some, but you couldn't pay me to do it. (Also, seems unfair to programmers that can't hear well or need other accommodations.)
    - oarabbus_ 7y ago
      Were you coding with someone either much more, or much less experienced than you? Without knowing the case, this could affect how successful the pair coding is.
      - downerending 7y ago
        Two people somewhat less experienced. I don't believe that was the issue.
        byeager 7y ago
        Out of curiosity do you think they benefited from the experience?
proc0 7y ago
I had someone in an interview once "confess" that they did so much pair programming they had forgotten how to quickly do things on their own. It was said as if it was one of the pro's of pair prog., but I saw it as a huge downside that this person was so dependent on others to complete their day to day tasks.
- taeric 7y ago
  I'm torn. I don't feel comfortable pair programming, but I think looking at an individual's speed is too narrow. Consider, you probably don't criticize this person's use of an IDE. Why is that different? Effectively, in places we are comfortable adding AI style assistance, odd that we shun just the I. To that end, we agree teams are typically needed. Shame we don't focus our measurements on the team. Feels a great way to kill a team is to measure it's individuals. :(
  - wccrawford 7y ago
    If someone can't program without an IDE, there are plenty of free ones that they can download, and they're unlikely to ever be in a situation where they can't find an IDE but they can run and test their code. Being unable to program without a partner is a serious handicap and will happen many times in a year, especially if people are sick or on vacation.
    - taeric 7y ago
      This still feels over simplistic. If there isn't someone else in the office to pair with, the code isn't getting pushed anyway, as it will lack a review. I get that it is a flag. But a lot depends on degree. Sport metaphors are often a stretch, but if they are saying they need their team to play, that isn't super scary on its own. If they need their full team to practice, that changes. And if they need a specific team member or they refuse to play, that is terrible. And you simplify the IDE point heavily. Just picking up one is not going to get you productive right away. Might as well have that sick partner. :)
mr_custard 7y ago
I read through this quickly, but I couldn't find any mention of pair programming not being suitable for sensitive and introverted people - especially those that suffer from anxiety and other mental illnesses that can be made worse by the stress of pair programming. Whilst the article mentions that it "can be hard and stressful" there is still the assumption that most people are more or less the same in terms of mental resilience, that most people would be okay and that everybody should "give it a go". I don't feel that's true at all, and certainly I'm one of those people that would be made ill by an environment of constant forced pair programming _even though_ I manage to hold down a job, appear "fairly normal" from the outside and do pretty well as a mostly solo programmer.
- mcnichol 7y ago
  It sounds like you and I are very similar. I was part of a company that went down the road of XP...it was very difficult for the first 6 months but it changed my life. I am much different now than when I started (I am actually in a role where communication is a big part of my role)...I forced myself to stick it out. Not going to lie there were a lot of tough moments on long train-rides home but I not only learned a ton from those around me, but it changed how I connect and interacted with folks. Granted it is not for everyone, I would especially say those who want to punch-in, browse reddit, and punch-out...but it is the one thing that I've found which brought up the water-line of a team I was working on.
  - mr_custard 7y ago
    I appreciate your positive encouragement and that you took the time to write. I'm glad that you jumped in at the deep end and that it worked out so well for you :-) I'm still not convinced that it would be good for my wellbeing and happiness, given that I've experienced PP for a couple of weeks on and off (not anywhere near 6 months like you!). I do like to collaborate with co-workers to solve problems, for sure, and we will often share screens and benefit from putting our minds together. But PP for 6 ... 8 hours a day, without periods of quiet contemplation, spent with my own thoughts? When I think about it like that, my heart sinks.
nixpulvis 7y ago
Anyone know of a good, open source, cross-platform video conferencing application?
- 22c 7y ago
  Not exactly what you asked for, but I have had success with pair programming using VS Code Live Share[1] and Mumble for VoIP[2]. I don't think video is particularly important when you're both seeing the same screen and able to talk about it. [1] https://docs.microsoft.com/en-us/visualstudio/liveshare/use/vscode https://docs.microsoft.com/en-us/visualstudio/liveshare/use/... [2] https://www.mumble.info https://www.mumble.info
  - iudqnolq 7y ago
    I've been trying this recently, but find it hard to debug issues because I can't see the output of the program being run or use a debugger on it. We got to the point of sending Dropbox links to screenshots of chrome with the devtools console open, which seems absurd. Maybe chrome remote debugging could help? Maybe I'm just not good at writing code correctly the first time, but when I program I usually fix at least one error per compile/run. So I have trouble pair programming when eg the other person likes to write larger chunks of code before running/testing.
    - iudqnolq 7y ago
      Edit: Completely missed that VS Live Share has a solution for this. Amending my complaint to be about the discoverability of the UX
- cobbzilla 7y ago
  Jitsi looks interesting: https://jitsi.org https://jitsi.org I've never tried it out, but I am very tempted. Looks pretty clean and modern, with a pure JavaScript WebRTC client, in addition to the usual native apps.
loopz 7y ago
Nothing wrong with "pair programming". It's only natural when people are friendly, engaged and cooperating, in that order. It's the environment that actively sabotage such way of working, or attempts to mandate it as a ritualistic practice, that is unnatural. A natural extension of two people in front of a whiteboard, nothing more.
- yepthatsreality 7y ago
  Agreed. The stigma around it seems to be that either side can treat pair-programming as a pop quiz when really it’s just another set of eyes and a discussion.
siquick 7y ago
My experience of PP has been that it's often a way for one of the devs to prove that they are the smartest person at the desk, and its far from a collaborative effort. A lot of dev teams suffer from the iamverysmart problem already, and PP just seems like a way to exacerbate it.
FpUser 7y ago
Personally when approach a task I like to be alone and do design. At this point I do not need anyone messing with my thoughts. If I need advice sometime during the process due to let's say lack of experience in particular area I'll call someone who does and ask for advice. Does not take long. Few minutes usually. When the design is ready I want to present it to people and they have to prove to me that I produced crap. If they do I am back to a drawing board . If not (and that became the most often outcome after few years in the industry) then f.. off leave me alone and I'will put my design into a code. The last thing I need at this point is someone breathing down my neck. After the code is finished and I am reasonably happy with it I would like me some code review if condition allow. Not very often as I mostly work either on my own products and do not have people around for code review and/or making some extra dosh doing the same thing as consultant and consultants do not often get this luxury. All in all I can see no benefits at all in doing pair programming for myself. If someone is happy with it and their boss lets them do it then sure, go full monty. Just please do not force this style on people. Not everyone can tolerate close contact for extended time.
xupybd 7y ago
I would take less money to get to work like this. The isolation is what I find hardest about being a developer. I work far better in a team with people relying on me. Direct interaction like that makes the days so much more enjoyable. I really hope to one day find an employer willing to adopt this practice. If anyone is hiring I'll apply.
- cgarvis 7y ago
  You don’t need an employer to by into pairing. Get them to buy into managing work at the team level instead of the individual level. Then you can safely pair with your team mates.
- jordanlev 7y ago
  I work for a company that takes agile development practices seriously, and I pair program all day, every day. I absolutely love it -- primarily for the reason you cite (I previously worked mostly solo as a freelancer or remote teammate)... having the direct accountability all the time makes me much more focused and productive. (fwiw, I am definitely an introvert, but a one-on-one situation is much easier for me than a group). My company (World Wide Technology - Application Services) is hiring -- we have some physical offices across the U.S. and a few in other countries, as well as a growing "virtual office" team (which, while remote, is still in frequent communication and pairs remotely). Email me if you want to talk more or be put in touch with someone about applying (my email address is in my profile).
lifeisstillgood 7y ago
As a "senior" the thing I find about pair programming is that it forces code review - it's waaay too easy to blip over code in a review. It really is higher quality code review but boy it smashes productivity with a frying pan and keeps hitting it. Pair programming - bad for startups that want to hammer out quick code, bad for enterprises that want to hit deadlines on stretched resources. It's a tough one to argue for. Edit: Things I want to try - Tennis Programming - sit next to each other, one writes the tests, one writes the code, swap round often, run on shared disk space or something. Spending ages watching someone else code is just being a human syntax checker. Swapping and diving in to code after ten minutes might be more interesting. It's like writing a joke or a scene in a movie then handing the paper to your writing partner. You need fast feedback.
- Consultant32452 7y ago
  I work for an enterprise and use pair programming sparingly. It's particularly useful with juniors who are eager to work hard but don't know how to think about writing software. It allows a fair amount of narration. I've mentored a few people this way and it resulted in their productivity and skill level skyrocketing. It's worth noting this never came from a top down mandate or anything. It's just one more tool in the tool belt. I think that's key to success, adapt to what works best on an individual level.
  - lifeisstillgood 7y ago
    I see that as mentoring - really valuable for the team and the mentee, and more of a job for the mentor. I am reaching for something that actually rocket boosts both people in the pair (and implies some degree of equality of skill). I have had that experience a couple of times - basically lock good people in a room with a clear tight mission and keep distractions away. Building that in a cube farm with project reporting requirements is almost impossible...
- Ididntdothis 7y ago
  The tennis thing may actually work. You get quick review and if something is difficult you can do some pair programming.
0x445442 7y ago
So while pair programming what happens with the never ending string of distracting Slack messages and diversions? It just seems completely impractical for the environments I’ve had experienced.
- leafmeal 7y ago
  Having another person around helps me stay on task. I have to put off engaging with those distractions until a scheduled break. For that reason alone, pair programming can be more productive.
- jacques_chester 7y ago
  I've seen a few patterns at Pivotal. In Pivotal Labs and some R&D projects the team is fully colocated, so Slack isn't necessary for the day-to-day. To maintain accessibility by remote teams and individuals, most teams will assign an "interrupt pair", who are designated to deal with Slack, walk-by questions and the like. I have mixed feelings about Slack. It's too addictive. I've enjoyed jousting and joking and forth, but I don't always come out the other side with concrete outcomes.
- robotron 7y ago
  You DnD. If you don't feel like you can do that, then I would suggest you're not in an ideal working environment for fostering productivity.
pnathan 7y ago
I have never once been able to look at this and think it was a good idea outside of specific training sessions with specific coworkers for specific purposes. I think programmers should be considered professionals who can do their own work quite well on their own, and held to that standard.
- jacques_chester 7y ago
  What about pairing strikes you as not considering programmers to be professionals? I've done a lot of pairing and never felt that I was somehow being slighted or considered incapable. I've felt slighted in cases when I wasn't pairing, though.
itqwertz 7y ago
Pair programming is fantastic. There is no better way to educate a newer team member to code standards and procedures as well as business domain. It also helps to reign in over-engineering and bad approaches. For more senior developers, it can expose them to newer approaches and technologies that they might not be aware of. I had a great experience pairing on a complex feature request (convert desktop version of an app to a mobile version) that was planned for 3 months. We finished it in a month with full test coverage and every little change to PM, PO, and UX designer could throw at us. Because we both had knowledge of the systems, we could later work independently on simpler tasks and regroup later to combine our efforts.
city41 7y ago
I wrote this after almost exclusively pairing for 3 years: https://www.mattgreer.org/articles/pair-programming-is-not-a-panacea/ https://www.mattgreer.org/articles/pair-programming-is-not-a... In general I think this article is pretty good. It seems to bias towards "pair programming is better" where as I biased towards "pair programming can be really bad". In the end, it's a tool like anything else. Sometimes pairing is the perfect way to tackle something, and other times it's the last thing you should be doing.
uncle_j 7y ago
I been working full time now about 15 years and I think Martin Fowler's blog and especially articles like this do more harm than good. Typically I find Pair Programming pretty pointless for most tasks. Where it works is when one developer knows the code base and another knows about the new piece they are trying to implement e.g. something external they are interfacing with. Much like other subjects on Martin Fowlers blog, it will get picked up by some which will religiously adhere to it and not consider where it will be best suited.
nikofeyn 7y ago
the thought of pair programming nearly gives me an anxiety attack. the second it’s mentioned in the interview process, it’s an automatic no from me. what other industry or domain does this? none that i know of. first of all, working in pairs creates a problem when there’s disagreement. you need a group of three to five to find agreement in those cases. working in pairs also requires a very tight alignment of style in programming, thinking, speed, brainstorming, etc. it simply does not allow for moments of thoughtful rumination or experimentation. it’s just like having pairs in school. it never works unless the two people are copies of each other or both people have spent time doing and thinking about the task themselves independently beforehand. i think working in pairs or small groups for design, review (or a post-review discussion), and especially debugging works quite well. it also works well when there’s a new person being ramped up or someone in the pair who is particularly knowledgeable about a portion of the interfacing code or sticky points. but two people sitting at a computer implementing? that only works for a very, very short amount of time, if at all. i refuse to work for any place that forces this upon workers. it creates just another selection bias in interviews. engineers already look for people just like them, and this just adds to that bias. and the articles for the benefits does nothing to say what pair programming does to actually enable the benefits listed. all of the benefits can be accomplished by shared design plus individual design, shared review, shared debugging, and individual implementation.
- jacques_chester 7y ago
  > what other industry or domain does this? none that i know of. Aviation, some surgeries. You know, low-stakes stuff.
  - cgrealy 7y ago
    Fundamentally different to software development on both counts. Aviation and surgery are basically real-time activities. If you make a mistake in either, the consequences are dire. Also, in aviation, it's about redundancy... if there's an issue, it's not like you can wait while someone else steps in. Software is not like that. Your code almost never goes straight into prod (unless you have really aggressive CI/CD!). There is always time to correct your mistakes.
Grimm1 7y ago
At my first job I mandatorily pair programmed with someone every day for months and we had very different personalities. Neither he nor I wanted to and the result was we wore on each other, decorum broke down and the code itself was weaker because we would take turns ignoring the situation to get what few moments of peace we could in the day. We both left that company around our 1-year mark even though otherwise it wasn't bad got out at 5pm every day, catered lunch sometimes etc. I understand it is useful in certain situations but that largely turned me off from it as a concept and I still doubt the benefits when used "properly". Pair programming is a very intense experience and had it stopped a few weeks in that situation then maybe my thoughts on it would be different.
confidantlake 7y ago
I have somewhere between moderate and severe social anxiety. Was on a team earlier this year that did 100% pair programming. Was the worst 6 months of my career. I had weekly breakdowns, my mental health got much worse ect. Once I was moved to a different team, my mental health quickly recovered.
overgard 7y ago
Pair programming is a nightmare for introverted people. Part of the appeal of coding is the relative solitude of the work. I think any company that mandates it is just a place I won't work.
jacques_chester 7y ago
My experience of pair programming, which spanned about 4.5-5 years of working for Pivotal Labs and in Pivotal R&D, was pretty much universally positive. But it's a complex skillset in its own right, hard to learn from a book. And in turn it requires a degree of corporate sanity and cultural safety that is quite rare. It's also a very humbling experience. Lots of people have had bad experiences, or believe that they would have a bad experience. I just like to place on the record that my experience of pair programming has been amazing and I look forward to the day when I can return to it.
cgrealy 7y ago
I find PP useful for complex tasks where two devs can bounce ideas off each other (preferably in a breakout room with a whiteboard). For the majority of time, it's just not necessary. If the domain is well understood, the code base is familiar and the requirements are well defined, most units of work (stories, PRs, whatever) shouldn't need two people.
epicgiga 7y ago
The problem is treating this stuff in an "inheritance" rather than "composition" manner. Which is precisely how most managers think, AKA management fads. Instead of absorbing the concepts behind PP into the mamagement, they'll declare "our team does PP". We're a PP team now. Or Agile. Or Lean. Or whatever. And they'll fit the team to the book, rather than the other way around. It's rife and terrible. Sure, I "do" PP... maybe a total of an hour a week, to mentor a junior. Which I do without knowing it's "PP", or calling it that, or caring about that as a practice. When a managerial practice gets a name, it causes more harm than benefit, because every drone manager out there will get all procrustean and damage existing workflows with it.
jordanlev 7y ago
As a counterpoint to most of the comments here: I work at a company where almost every developer pairs all the time. I absolutely love it. I thought I would hate it. I'm an introvert. I previously worked as a solo freelancer and then as a remote teammate. So I was very nervous about this aspect of the job, but figured I'd give it a shot (other things about the job were appealing enough that I was willing to try it out). Some thoughts based on my own personal experience: * The biggest win for me is I am much more focused and productive throughout the day. Having an actual person to be accountable to on a continual basis keeps me from meandering down unimportant rabbit holes, unnecessary/premature refactoring or re-organizing, and general procrastinating (reddit, HN, etc) * Development is definitely at a slower pace on a daily basis than what I'm used to working on my own, but over time I think it evens out in terms of quality of code and maintainability. * Knowledge sharing is huge -- when I was solo, I could never truly take a vacation because I was the only one responsible for my piece of work. Now I'm on a team where we all pair with each other and switch around every day... if someone is out, it's no big deal. Also makes it much easier to onboard new people (the company I work at is a consultancy so projects are always ending and new ones beginning). * Despite being an introvert, I feel no more "drained" of energy at the end of the day than I ever did at any other job. One-on-one interactions with people I know and build trust with just doesn't affect me the way other social interactions do. * Pairing is not a panacea. Some of the comments I've seen here are about how horrible it would be to pair and feel judged all the time or one personality overriding the other... I suppose that's possible but it doesn't happen at my job because my company values and encourages trust. My team is comprised of mature people who all value team cohesion and working together towards a goal over having to be right all the time or proving to someone that we're better or whatever. * I am never "stuck" pairing with just 1 person for a long time... we switch around every day. I probably pair with any given person only once per week (on a team with 6 developers). But each team has autonomy to structure the pair switching however they want. Those are just some thoughts off the top of my head. Happy to answer any questions anyone may have (and if it sounds interesting to you, my company is always hiring... we have physical offices around the world, as well as a "virtual office" for remote employees).
- Mike12398 7y ago
  You're not an introvert.
kstenerud 7y ago
I'm sure pair programming is great for certain personality types, but please do not treat it as a panacea. I've done pair programming enough now in my career to be able to say that it stifles me, interrupts my flow, kills my creativity, decreases my productivity, and leaves me exhausted at the end of the day. I don't necessarily think it's a bad idea for certain people, but I resent it when it becomes a blanket policy. In fact, I've left jobs that started requiring pair programming. There's a reason why it's only received tepid acceptance in industry. If it works for you, great. But don't force it on me.
gatestone 7y ago
Here is a beautiful example. Using "screen" to switch every 5 minutes or so... https://www.youtube.com/watch?v=yG-UaBJXZ80 https://www.youtube.com/watch?v=yG-UaBJXZ80
jtaft 7y ago
All around pretty good article. Never thought about using the pomodor technique while pair programming. The part about "informal hierarchies" threw me off, and comes off a bit sexist and racist to me. I read this as "hierarchies that are generally recognized/accepted by the public". I don't believe Fowler intended it to read this way. I think it's okay however to recognize people may have interpersonal issues, for a wide range of reasons.
- GhostVII 7y ago
  I think that section makes good points about hierarchies between more and less senior people, and between people with a CS degree and people without, but yea I think it is unnecessary to single out white men and imply that they are more likely to try and hog the keyboard or always be in teaching mode.
aspaviento 7y ago
I had a coworker with whom I did some pair programming and it was painful. He was very talkative, to the point of forcing me to interrupt him every time to come back to what we were doing. Also most of the time he made really hard to follow the code because he took every opportunity to show off his keyboard-shortcut-skills, jumping from file to file, jumping between lines of code, commenting and uncommenting code... all that very fast.
- mlthoughts2018 7y ago
  This describes every pair programming session I’ve ever had in 15 years and 5 companies. And I’m sure I’m guilty too. Pair programming occasionally helps, but as a frequent practice it causes systemic harm, especially to morale.
- dustingetz 7y ago
  1) You can make pairing part of the interview 2) You'll pick up his shortcut fluency in about two days of pairing ... I taught my co-founder Emacs and Clojure at the same time in about two days of pairing
codingdave 7y ago
We pair when we get stuck. It isn't our standard way to work, and it is difficult, in particular for remote teams. But still, spend 15-20 minutes screen-sharing with a coworker, and you find one of two things happen: 1) They see something you did not, you get past your block, and start being productive again. 2) They see nothing else, so you know that you actually have a thorny problem to solve, so you get to it. In those small doses, I like pair programming. But I would not care to do it more.
lunias 7y ago
I've worked at places in the past that forced pairing. One monitor and two keyboards style. It was painful; impossible to get into flow state. All of your mental maps need to be communicated repeatedly to the other person - and it's slow. It's like the difference between L1 cache lookup and sending an email and waiting for a response.
Tainnor 7y ago
Pair programming is by no means "crucial". It is an approach that probably works quite well in some contexts and some teams. In other team, different approaches work. In the end what matters is that the team is highly motivated, has a strong sense of ownership and takes appropriate measures to reduce defects. How it achieves that doesn't really matter from a business POV and is more a subjective preference. In my team, we mostly achieve this through extremely thorough code reviews that dig into a lot of details and that works well for us. edit: another thing that we do is careful discussion and planning of features (where we will sit together in a small group and discuss approaches) and, for more complex things, architecture decision records (similar to RFCs) that get reviewed before they are implemented.

On Pair Programming

156 points by joeyespo 7y ago

forgotmypw38 7y ago

I fake it by doing a screen capture of myself working and then playing it back.

coralreef 7y ago
Who are you fooling with this screen capture? Your programming partner?
- drdeca 7y ago
  Perhaps by “fake it” they meant “emulate it” rather than “deceptively produce the appearance of it”. This would allow one to double check ones actions in order to notice and correct mistakes one made the first time?

simonw 7y ago

I'm always slightly surprised when I see an article on martinfowler.com that isn't by Martin Fowler. I can't think of many other personally-branded domains like this that feature guest author content so often. ... which is really me distracting myself, because the guest content is usually of a very high quality. Maybe the personal branding is justified here because Martin Fowler curates and edits the pieces?

simonw 7y ago
https://martinfowler.com/aboutMe.html https://martinfowler.com/aboutMe.html helps explain what's going on here: > As the site got more popular, I felt I could use it to help other people get more visibility for their writing, so I've steadily increased publications from others here. I vet each article before accepting it - and often do a considerable amount of developmental editing too - so there isn't a high rate of publication. I do believe, however, that the quality of the articles matters much more than the quantity.

geophile 7y ago

If forced to choose between pair programming and not programming at all, I think I would choose the latter.

oarabbus_ 7y ago
Why?
- artsyca 7y ago
  I'd venture 99% of pair coding is done by people who don't know why they're even doing it and set themselves up for failure at the outset ultimately crying sour grapes
- downerending 7y ago
  Not OP, but for me, it's like having someone stand over my head with a pot, banging it with a spoon incessantly. It utterly destroys my ability to concentrate. Had a chance to closely observe a session once. Looked through the code later--total garbage. Apparently it works for some, but you couldn't pay me to do it. (Also, seems unfair to programmers that can't hear well or need other accommodations.)
  - oarabbus_ 7y ago
    Were you coding with someone either much more, or much less experienced than you? Without knowing the case, this could affect how successful the pair coding is.
    - downerending 7y ago
      Two people somewhat less experienced. I don't believe that was the issue.
      - byeager 7y ago
        Out of curiosity do you think they benefited from the experience?

proc0 7y ago

I had someone in an interview once "confess" that they did so much pair programming they had forgotten how to quickly do things on their own. It was said as if it was one of the pro's of pair prog., but I saw it as a huge downside that this person was so dependent on others to complete their day to day tasks.

taeric 7y ago
I'm torn. I don't feel comfortable pair programming, but I think looking at an individual's speed is too narrow. Consider, you probably don't criticize this person's use of an IDE. Why is that different? Effectively, in places we are comfortable adding AI style assistance, odd that we shun just the I. To that end, we agree teams are typically needed. Shame we don't focus our measurements on the team. Feels a great way to kill a team is to measure it's individuals. :(
- wccrawford 7y ago
  If someone can't program without an IDE, there are plenty of free ones that they can download, and they're unlikely to ever be in a situation where they can't find an IDE but they can run and test their code. Being unable to program without a partner is a serious handicap and will happen many times in a year, especially if people are sick or on vacation.
  - taeric 7y ago
    This still feels over simplistic. If there isn't someone else in the office to pair with, the code isn't getting pushed anyway, as it will lack a review. I get that it is a flag. But a lot depends on degree. Sport metaphors are often a stretch, but if they are saying they need their team to play, that isn't super scary on its own. If they need their full team to practice, that changes. And if they need a specific team member or they refuse to play, that is terrible. And you simplify the IDE point heavily. Just picking up one is not going to get you productive right away. Might as well have that sick partner. :)

mr_custard 7y ago

I read through this quickly, but I couldn't find any mention of pair programming not being suitable for sensitive and introverted people - especially those that suffer from anxiety and other mental illnesses that can be made worse by the stress of pair programming. Whilst the article mentions that it "can be hard and stressful" there is still the assumption that most people are more or less the same in terms of mental resilience, that most people would be okay and that everybody should "give it a go". I don't feel that's true at all, and certainly I'm one of those people that would be made ill by an environment of constant forced pair programming _even though_ I manage to hold down a job, appear "fairly normal" from the outside and do pretty well as a mostly solo programmer.

mcnichol 7y ago
It sounds like you and I are very similar. I was part of a company that went down the road of XP...it was very difficult for the first 6 months but it changed my life. I am much different now than when I started (I am actually in a role where communication is a big part of my role)...I forced myself to stick it out. Not going to lie there were a lot of tough moments on long train-rides home but I not only learned a ton from those around me, but it changed how I connect and interacted with folks. Granted it is not for everyone, I would especially say those who want to punch-in, browse reddit, and punch-out...but it is the one thing that I've found which brought up the water-line of a team I was working on.
- mr_custard 7y ago
  I appreciate your positive encouragement and that you took the time to write. I'm glad that you jumped in at the deep end and that it worked out so well for you :-) I'm still not convinced that it would be good for my wellbeing and happiness, given that I've experienced PP for a couple of weeks on and off (not anywhere near 6 months like you!). I do like to collaborate with co-workers to solve problems, for sure, and we will often share screens and benefit from putting our minds together. But PP for 6 ... 8 hours a day, without periods of quiet contemplation, spent with my own thoughts? When I think about it like that, my heart sinks.

nixpulvis 7y ago

Anyone know of a good, open source, cross-platform video conferencing application?

22c 7y ago
Not exactly what you asked for, but I have had success with pair programming using VS Code Live Share[1] and Mumble for VoIP[2]. I don't think video is particularly important when you're both seeing the same screen and able to talk about it. [1] https://docs.microsoft.com/en-us/visualstudio/liveshare/use/vscode https://docs.microsoft.com/en-us/visualstudio/liveshare/use/... [2] https://www.mumble.info https://www.mumble.info
- iudqnolq 7y ago
  I've been trying this recently, but find it hard to debug issues because I can't see the output of the program being run or use a debugger on it. We got to the point of sending Dropbox links to screenshots of chrome with the devtools console open, which seems absurd. Maybe chrome remote debugging could help? Maybe I'm just not good at writing code correctly the first time, but when I program I usually fix at least one error per compile/run. So I have trouble pair programming when eg the other person likes to write larger chunks of code before running/testing.
  - iudqnolq 7y ago
    Edit: Completely missed that VS Live Share has a solution for this. Amending my complaint to be about the discoverability of the UX
cobbzilla 7y ago
Jitsi looks interesting: https://jitsi.org https://jitsi.org I've never tried it out, but I am very tempted. Looks pretty clean and modern, with a pure JavaScript WebRTC client, in addition to the usual native apps.

loopz 7y ago

Nothing wrong with "pair programming". It's only natural when people are friendly, engaged and cooperating, in that order. It's the environment that actively sabotage such way of working, or attempts to mandate it as a ritualistic practice, that is unnatural. A natural extension of two people in front of a whiteboard, nothing more.

yepthatsreality 7y ago
Agreed. The stigma around it seems to be that either side can treat pair-programming as a pop quiz when really it’s just another set of eyes and a discussion.

siquick 7y ago

My experience of PP has been that it's often a way for one of the devs to prove that they are the smartest person at the desk, and its far from a collaborative effort. A lot of dev teams suffer from the iamverysmart problem already, and PP just seems like a way to exacerbate it.

FpUser 7y ago

Personally when approach a task I like to be alone and do design. At this point I do not need anyone messing with my thoughts. If I need advice sometime during the process due to let's say lack of experience in particular area I'll call someone who does and ask for advice. Does not take long. Few minutes usually. When the design is ready I want to present it to people and they have to prove to me that I produced crap. If they do I am back to a drawing board . If not (and that became the most often outcome after few years in the industry) then f.. off leave me alone and I'will put my design into a code. The last thing I need at this point is someone breathing down my neck. After the code is finished and I am reasonably happy with it I would like me some code review if condition allow. Not very often as I mostly work either on my own products and do not have people around for code review and/or making some extra dosh doing the same thing as consultant and consultants do not often get this luxury. All in all I can see no benefits at all in doing pair programming for myself. If someone is happy with it and their boss lets them do it then sure, go full monty. Just please do not force this style on people. Not everyone can tolerate close contact for extended time.

xupybd 7y ago

I would take less money to get to work like this. The isolation is what I find hardest about being a developer. I work far better in a team with people relying on me. Direct interaction like that makes the days so much more enjoyable. I really hope to one day find an employer willing to adopt this practice. If anyone is hiring I'll apply.

cgarvis 7y ago
You don’t need an employer to by into pairing. Get them to buy into managing work at the team level instead of the individual level. Then you can safely pair with your team mates.
jordanlev 7y ago
I work for a company that takes agile development practices seriously, and I pair program all day, every day. I absolutely love it -- primarily for the reason you cite (I previously worked mostly solo as a freelancer or remote teammate)... having the direct accountability all the time makes me much more focused and productive. (fwiw, I am definitely an introvert, but a one-on-one situation is much easier for me than a group). My company (World Wide Technology - Application Services) is hiring -- we have some physical offices across the U.S. and a few in other countries, as well as a growing "virtual office" team (which, while remote, is still in frequent communication and pairs remotely). Email me if you want to talk more or be put in touch with someone about applying (my email address is in my profile).

lifeisstillgood 7y ago

As a "senior" the thing I find about pair programming is that it forces code review - it's waaay too easy to blip over code in a review. It really is higher quality code review but boy it smashes productivity with a frying pan and keeps hitting it. Pair programming - bad for startups that want to hammer out quick code, bad for enterprises that want to hit deadlines on stretched resources. It's a tough one to argue for. Edit: Things I want to try - Tennis Programming - sit next to each other, one writes the tests, one writes the code, swap round often, run on shared disk space or something. Spending ages watching someone else code is just being a human syntax checker. Swapping and diving in to code after ten minutes might be more interesting. It's like writing a joke or a scene in a movie then handing the paper to your writing partner. You need fast feedback.

Consultant32452 7y ago
I work for an enterprise and use pair programming sparingly. It's particularly useful with juniors who are eager to work hard but don't know how to think about writing software. It allows a fair amount of narration. I've mentored a few people this way and it resulted in their productivity and skill level skyrocketing. It's worth noting this never came from a top down mandate or anything. It's just one more tool in the tool belt. I think that's key to success, adapt to what works best on an individual level.
- lifeisstillgood 7y ago
  I see that as mentoring - really valuable for the team and the mentee, and more of a job for the mentor. I am reaching for something that actually rocket boosts both people in the pair (and implies some degree of equality of skill). I have had that experience a couple of times - basically lock good people in a room with a clear tight mission and keep distractions away. Building that in a cube farm with project reporting requirements is almost impossible...
Ididntdothis 7y ago
The tennis thing may actually work. You get quick review and if something is difficult you can do some pair programming.

0x445442 7y ago

So while pair programming what happens with the never ending string of distracting Slack messages and diversions? It just seems completely impractical for the environments I’ve had experienced.

leafmeal 7y ago
Having another person around helps me stay on task. I have to put off engaging with those distractions until a scheduled break. For that reason alone, pair programming can be more productive.
jacques_chester 7y ago
I've seen a few patterns at Pivotal. In Pivotal Labs and some R&D projects the team is fully colocated, so Slack isn't necessary for the day-to-day. To maintain accessibility by remote teams and individuals, most teams will assign an "interrupt pair", who are designated to deal with Slack, walk-by questions and the like. I have mixed feelings about Slack. It's too addictive. I've enjoyed jousting and joking and forth, but I don't always come out the other side with concrete outcomes.
robotron 7y ago
You DnD. If you don't feel like you can do that, then I would suggest you're not in an ideal working environment for fostering productivity.

pnathan 7y ago

I have never once been able to look at this and think it was a good idea outside of specific training sessions with specific coworkers for specific purposes. I think programmers should be considered professionals who can do their own work quite well on their own, and held to that standard.

jacques_chester 7y ago
What about pairing strikes you as not considering programmers to be professionals? I've done a lot of pairing and never felt that I was somehow being slighted or considered incapable. I've felt slighted in cases when I wasn't pairing, though.

itqwertz 7y ago

Pair programming is fantastic. There is no better way to educate a newer team member to code standards and procedures as well as business domain. It also helps to reign in over-engineering and bad approaches. For more senior developers, it can expose them to newer approaches and technologies that they might not be aware of. I had a great experience pairing on a complex feature request (convert desktop version of an app to a mobile version) that was planned for 3 months. We finished it in a month with full test coverage and every little change to PM, PO, and UX designer could throw at us. Because we both had knowledge of the systems, we could later work independently on simpler tasks and regroup later to combine our efforts.

city41 7y ago

I wrote this after almost exclusively pairing for 3 years: https://www.mattgreer.org/articles/pair-programming-is-not-a-panacea/ https://www.mattgreer.org/articles/pair-programming-is-not-a... In general I think this article is pretty good. It seems to bias towards "pair programming is better" where as I biased towards "pair programming can be really bad". In the end, it's a tool like anything else. Sometimes pairing is the perfect way to tackle something, and other times it's the last thing you should be doing.

uncle_j 7y ago

I been working full time now about 15 years and I think Martin Fowler's blog and especially articles like this do more harm than good. Typically I find Pair Programming pretty pointless for most tasks. Where it works is when one developer knows the code base and another knows about the new piece they are trying to implement e.g. something external they are interfacing with. Much like other subjects on Martin Fowlers blog, it will get picked up by some which will religiously adhere to it and not consider where it will be best suited.

nikofeyn 7y ago

the thought of pair programming nearly gives me an anxiety attack. the second it’s mentioned in the interview process, it’s an automatic no from me. what other industry or domain does this? none that i know of. first of all, working in pairs creates a problem when there’s disagreement. you need a group of three to five to find agreement in those cases. working in pairs also requires a very tight alignment of style in programming, thinking, speed, brainstorming, etc. it simply does not allow for moments of thoughtful rumination or experimentation. it’s just like having pairs in school. it never works unless the two people are copies of each other or both people have spent time doing and thinking about the task themselves independently beforehand. i think working in pairs or small groups for design, review (or a post-review discussion), and especially debugging works quite well. it also works well when there’s a new person being ramped up or someone in the pair who is particularly knowledgeable about a portion of the interfacing code or sticky points. but two people sitting at a computer implementing? that only works for a very, very short amount of time, if at all. i refuse to work for any place that forces this upon workers. it creates just another selection bias in interviews. engineers already look for people just like them, and this just adds to that bias. and the articles for the benefits does nothing to say what pair programming does to actually enable the benefits listed. all of the benefits can be accomplished by shared design plus individual design, shared review, shared debugging, and individual implementation.

jacques_chester 7y ago
> what other industry or domain does this? none that i know of. Aviation, some surgeries. You know, low-stakes stuff.
- cgrealy 7y ago
  Fundamentally different to software development on both counts. Aviation and surgery are basically real-time activities. If you make a mistake in either, the consequences are dire. Also, in aviation, it's about redundancy... if there's an issue, it's not like you can wait while someone else steps in. Software is not like that. Your code almost never goes straight into prod (unless you have really aggressive CI/CD!). There is always time to correct your mistakes.

Grimm1 7y ago

At my first job I mandatorily pair programmed with someone every day for months and we had very different personalities. Neither he nor I wanted to and the result was we wore on each other, decorum broke down and the code itself was weaker because we would take turns ignoring the situation to get what few moments of peace we could in the day. We both left that company around our 1-year mark even though otherwise it wasn't bad got out at 5pm every day, catered lunch sometimes etc. I understand it is useful in certain situations but that largely turned me off from it as a concept and I still doubt the benefits when used "properly". Pair programming is a very intense experience and had it stopped a few weeks in that situation then maybe my thoughts on it would be different.

confidantlake 7y ago

I have somewhere between moderate and severe social anxiety. Was on a team earlier this year that did 100% pair programming. Was the worst 6 months of my career. I had weekly breakdowns, my mental health got much worse ect. Once I was moved to a different team, my mental health quickly recovered.

overgard 7y ago

Pair programming is a nightmare for introverted people. Part of the appeal of coding is the relative solitude of the work. I think any company that mandates it is just a place I won't work.

jacques_chester 7y ago

My experience of pair programming, which spanned about 4.5-5 years of working for Pivotal Labs and in Pivotal R&D, was pretty much universally positive. But it's a complex skillset in its own right, hard to learn from a book. And in turn it requires a degree of corporate sanity and cultural safety that is quite rare. It's also a very humbling experience. Lots of people have had bad experiences, or believe that they would have a bad experience. I just like to place on the record that my experience of pair programming has been amazing and I look forward to the day when I can return to it.

cgrealy 7y ago

I find PP useful for complex tasks where two devs can bounce ideas off each other (preferably in a breakout room with a whiteboard). For the majority of time, it's just not necessary. If the domain is well understood, the code base is familiar and the requirements are well defined, most units of work (stories, PRs, whatever) shouldn't need two people.

epicgiga 7y ago

The problem is treating this stuff in an "inheritance" rather than "composition" manner. Which is precisely how most managers think, AKA management fads. Instead of absorbing the concepts behind PP into the mamagement, they'll declare "our team does PP". We're a PP team now. Or Agile. Or Lean. Or whatever. And they'll fit the team to the book, rather than the other way around. It's rife and terrible. Sure, I "do" PP... maybe a total of an hour a week, to mentor a junior. Which I do without knowing it's "PP", or calling it that, or caring about that as a practice. When a managerial practice gets a name, it causes more harm than benefit, because every drone manager out there will get all procrustean and damage existing workflows with it.

jordanlev 7y ago

As a counterpoint to most of the comments here: I work at a company where almost every developer pairs all the time. I absolutely love it. I thought I would hate it. I'm an introvert. I previously worked as a solo freelancer and then as a remote teammate. So I was very nervous about this aspect of the job, but figured I'd give it a shot (other things about the job were appealing enough that I was willing to try it out). Some thoughts based on my own personal experience: * The biggest win for me is I am much more focused and productive throughout the day. Having an actual person to be accountable to on a continual basis keeps me from meandering down unimportant rabbit holes, unnecessary/premature refactoring or re-organizing, and general procrastinating (reddit, HN, etc) * Development is definitely at a slower pace on a daily basis than what I'm used to working on my own, but over time I think it evens out in terms of quality of code and maintainability. * Knowledge sharing is huge -- when I was solo, I could never truly take a vacation because I was the only one responsible for my piece of work. Now I'm on a team where we all pair with each other and switch around every day... if someone is out, it's no big deal. Also makes it much easier to onboard new people (the company I work at is a consultancy so projects are always ending and new ones beginning). * Despite being an introvert, I feel no more "drained" of energy at the end of the day than I ever did at any other job. One-on-one interactions with people I know and build trust with just doesn't affect me the way other social interactions do. * Pairing is not a panacea. Some of the comments I've seen here are about how horrible it would be to pair and feel judged all the time or one personality overriding the other... I suppose that's possible but it doesn't happen at my job because my company values and encourages trust. My team is comprised of mature people who all value team cohesion and working together towards a goal over having to be right all the time or proving to someone that we're better or whatever. * I am never "stuck" pairing with just 1 person for a long time... we switch around every day. I probably pair with any given person only once per week (on a team with 6 developers). But each team has autonomy to structure the pair switching however they want. Those are just some thoughts off the top of my head. Happy to answer any questions anyone may have (and if it sounds interesting to you, my company is always hiring... we have physical offices around the world, as well as a "virtual office" for remote employees).

Mike12398 7y ago
You're not an introvert.

kstenerud 7y ago

I'm sure pair programming is great for certain personality types, but please do not treat it as a panacea. I've done pair programming enough now in my career to be able to say that it stifles me, interrupts my flow, kills my creativity, decreases my productivity, and leaves me exhausted at the end of the day. I don't necessarily think it's a bad idea for certain people, but I resent it when it becomes a blanket policy. In fact, I've left jobs that started requiring pair programming. There's a reason why it's only received tepid acceptance in industry. If it works for you, great. But don't force it on me.

gatestone 7y ago

Here is a beautiful example. Using "screen" to switch every 5 minutes or so... https://www.youtube.com/watch?v=yG-UaBJXZ80 https://www.youtube.com/watch?v=yG-UaBJXZ80

jtaft 7y ago

All around pretty good article. Never thought about using the pomodor technique while pair programming. The part about "informal hierarchies" threw me off, and comes off a bit sexist and racist to me. I read this as "hierarchies that are generally recognized/accepted by the public". I don't believe Fowler intended it to read this way. I think it's okay however to recognize people may have interpersonal issues, for a wide range of reasons.

GhostVII 7y ago
I think that section makes good points about hierarchies between more and less senior people, and between people with a CS degree and people without, but yea I think it is unnecessary to single out white men and imply that they are more likely to try and hog the keyboard or always be in teaching mode.

aspaviento 7y ago

I had a coworker with whom I did some pair programming and it was painful. He was very talkative, to the point of forcing me to interrupt him every time to come back to what we were doing. Also most of the time he made really hard to follow the code because he took every opportunity to show off his keyboard-shortcut-skills, jumping from file to file, jumping between lines of code, commenting and uncommenting code... all that very fast.

mlthoughts2018 7y ago
This describes every pair programming session I’ve ever had in 15 years and 5 companies. And I’m sure I’m guilty too. Pair programming occasionally helps, but as a frequent practice it causes systemic harm, especially to morale.
dustingetz 7y ago
1) You can make pairing part of the interview 2) You'll pick up his shortcut fluency in about two days of pairing ... I taught my co-founder Emacs and Clojure at the same time in about two days of pairing

codingdave 7y ago

We pair when we get stuck. It isn't our standard way to work, and it is difficult, in particular for remote teams. But still, spend 15-20 minutes screen-sharing with a coworker, and you find one of two things happen: 1) They see something you did not, you get past your block, and start being productive again. 2) They see nothing else, so you know that you actually have a thorny problem to solve, so you get to it. In those small doses, I like pair programming. But I would not care to do it more.

lunias 7y ago

I've worked at places in the past that forced pairing. One monitor and two keyboards style. It was painful; impossible to get into flow state. All of your mental maps need to be communicated repeatedly to the other person - and it's slow. It's like the difference between L1 cache lookup and sending an email and waiting for a response.

Tainnor 7y ago

Pair programming is by no means "crucial". It is an approach that probably works quite well in some contexts and some teams. In other team, different approaches work. In the end what matters is that the team is highly motivated, has a strong sense of ownership and takes appropriate measures to reduce defects. How it achieves that doesn't really matter from a business POV and is more a subjective preference. In my team, we mostly achieve this through extremely thorough code reviews that dig into a lot of details and that works well for us. edit: another thing that we do is careful discussion and planning of features (where we will sit together in a small group and discuss approaches) and, for more complex things, architecture decision records (similar to RFCs) that get reviewed before they are implemented.