Where Pair Programming Fails For Me 43

Posted by wsargent Wed, 29 Dec 2010 22:27:00 GMT

The last time I wrote about Agile, I was writing about Grockit, and their daily process.  It’s been almost a year, but I think I have enough perspective now to write about my experience pair programming.  

EDIT: I've read through the responses and replied here: http://tersesystems.com/2010/12/31/responses-to-where-pair-programming-failed-for-me

The short story is that pair programming doesn’t work for me as the main way of developing software.  I can pair program for a day, or maybe a week, especially if we’re focused on a particular problem.  But after that?  I’m done.  Toast.  I don’t want to see anyone, talk to anyone, and I need at least a couple of days in a cave until I’m fit for human company again. 

It’s a sad story, but the funny thing is that I’m so much happier now with how it ended.  I’m happily employed on a contract where I work from home or from a coffee shop, and I’ve made new friends and explored more of San Francisco than I ever thought possible. I have a bicycle and a laptop, and as long as I meet my deadlines and check in code regularly, my time is my own.

I’ll list the big problems I have with pair programming up front and give you the detail and anecdotes later. 

  1. Split focus.
  2. No experimentation.
  3. No high notes.
  4. No pride in ownership.  
  5. No escape.

Background

My background is as a backend programmer.  I’ve done inventory systems, credit card processing and fulfillment, transcoding and digital asset management.  In non-agile teams, I was used to being handed the largest, hairiest problem in a project, pulling out the domain and putting something solid together inside the deadline.

I came into Grockit at the tail end of a long period of discussion where they had decided to rewrite the entire front end UI.  They were making heavy use of jQuery (a Javascript AJAX library), SASS (a CSS variant) and a library called Erector, which produced HTML markup from Ruby classes.  I knew none of these things; I knew some Javascript and CSS only from implementing them on my blog.  Because they were focusing on the UI and they were on a tight deadline, they were going to do an eight week sprint, and rewrite as much of the UI as they possibly code in that timeframe.

So, my first day.  

I was watching a man looking at a page -- what the finished product should look like.  He was telling me they’d discussed what the features should be already, and we just had to bang this out inside a day.  

He had opened up a text editor, and we were looking at Ruby code.  The ruby class was actually a page composed of Erector methods -- ruby code that evaluated to HTML -- but it had been refactored into extremely small methods which called each other, so there was no way to ‘see’ the HTML and how that corresponded to the class -- you simply had to know it.  In addition, they had tests attached to each section of UI code.  If you refactored the UI, you had to rewrite all the tests.

Sitting with another man, trying to work together to produce working code.  I was shocked at how unnatural and unintuitive it felt.  Far from being an easy practice, it felt both clumsy and shockingly intimate; both too personal and impersonal.  

If I asked a question, then work stopped.  

If I asked about the background of the code or the design, then work stopped.  

If I tried to follow along, then I found that I was trying to guess at what various methods and frameworks did.  I was being bounced between the domain classes, the Erector classes, the Javascript and the various tests, and I didn’t have a grasp on any of them.  

I understood the HTML code, but even there, I didn’t even know what to say -- did I point out the typos?  The two methods that were almost exactly the same except for the innermost loop?  Was I nitpicking by pointing these things out, or signalling my involvement?

And then, he was done.  It was time for me to write some code.  I opened up some files, looked around at the methods.  Tried to figure out what was going on, and write some exploratory code to see what was happening...  And then my pair started typing the method I was trying to write, handing it back for me to test.  I found that this would happen if I paused too long, or seemed to be typing the wrong thing -- my pair had another keyboard, and he would type over me to try to “finish the sentence” rather than talk to me. 

At the end of my first day, I had a massive headache from trying to absorb everything.  I was told I’d done very well, and that it was a lot to take in on the first day.  I didn’t feel like I’d been very productive, but I hoped that we could settle down into some kind of flow.

Split Focus

Split focus happens when I try to do two things at once.  Human beings are not good at multitasking in general, and I’m worse than most.  Pair programming is a balancing act between managing code and managing the pair that you’re working with.  Go too far in one direction or another, and you both fall off and lose effectiveness until you restore balance again.

I found that in order to pair, I had to act as if I was in a continuous meeting.  I had to not just listen to my pair, but appear to be listening; I had to nod in the right places, repeat back what my pair said in active listening fashion.  I had to pick the right moment to interject.   I tried to model my partner’s mental state in my head so I could see his viewpoint better. 

While I was doing this, I was trying to see the code that he was writing, and the design that he was trying to make the code fit.  If there was a failing test, I was trying to figure out the test and the test framework at the same time.

And if I was writing code, I found something very interesting: I don’t think in English when I write code.  I think in code first, and I can translate written code to English.  When I was trying to talk to people when I was writing code, I found that I’d have to write pseudocode and then talk to them about it -- and when my pair wanted me to talk about code, he wanted me to stop typing.  But if I stopped typing, I couldn’t describe what I was doing.  Every time I tried to write code and talk to my partner at the same time, I could feel the lurch between what I could feel -- the complex shape of it in my head -- and what I was having to say.

So pair programming split my focus not just in one way.  It split it in three or four different ways, and kept it split.  No wonder I had a headache.

No experimentation

The large part of pair programming was doing things in “The Simplest Possible Way That Could Work.”  In practice, this meant doing it the way that it had been done previously, with the least possible amount of change.

The way that the Erector toolkit was used, combined with pair programming and test driven development, ensured that two Ruby programmers were required to change any and all elements of the UI.  Tests were written to check for every single element in the UI, and with good reason; because elements of the UI had been abstracted out into subclasses and views, there was no clear way to see what code would do until it had been fully executed.  Sometimes the simplest possible thing to do had been to hack one of the classes for a special-case logic.  Then more code had been put on top, until a refactoring was just too expensive.  As long as all the tests were passing, the code was in a known, "good" state -- and we had to keep it that way.

The simplest thing that could possibly work as far as I was concerned was to put together an ERB page.  A straight HTML page with some embedded Ruby was a known, easy solution that would have enabled straight web designers to work on the UI without involving the full programming team, or at least have allowed us to quickly compare the mockup with a page.  But that ran into another problem; there is no facility in pair programming to change tracks, or try anything different.  Spikes only happen at the beginning of an iteration, and this iteration was budgeted at 8 weeks -- we were locked into our current way of doing things.

Not that it mattered; there was simply no leverage to explore the framework or try different approaches.  Any code changes that weren’t immediately applicable to changing the current page were “going off track”.  I couldn’t see the parameters of the current system, or feel for the fragile points if it didn’t match up with what my pair thought was important.  Every single moment I was typing, I was being watched.

No high notes

When I got to the point where I understood some of the framework, I saw that there were some bugs inherent in the existing design which would make the system act unpredictably in production.  In other situations, the design could improved by eliminating some classes and moving some other classes to have a single responsibility.

To me, this was “refactor mercilessly” and “once and only once.”  But to my partner, this was a violation of “do the simplest thing that could possibly work.”  It also went against the daily switching of partners.  Whatever you start when you pair has to be finished, and checked in, by the end of the day.  If you’re only looking at getting the story done by the end of the day, you’re not interested in hypothetical bugs or refactoring -- you don’t have time for them and they’re not budgeted for.  

The only way I could move discussion along was if I could write a test for it.  If I couldn’t write an effective test, or I described it in unfamiliar terms (usually from books or blogs), he wouldn’t hear “solves a problem that is difficult to test but is real.”  He would hear “introduces needless complexity and complicates design” and point to the simplest solution that makes sense to him.  If I tried writing a test and it took too long, I lost there as well. 

Eventually, I realized that many of my partners had never worked outside a test driven development process: they didn’t have the same idea of design or architecture as patterns distinct from code.  Trying to argue for encapsulation or adherence to SOLID principles is pointless if your partner has no background, let alone hands on experience, with what you’re saying.  This goes double when you’re talking about hard-won domain expertise: the more I knew about a subject, the less I could say.

I started picking my battles.  

How you pick your battles is, you plan to lose in the best way possible.  You try to leave an opening so that the bug that you know, from past experience, is going to hit, is not going to result in any lost data and can be easily fixed later.  It’s not great, but at least you can recover from it.

There are no high notes, no thought out design.  There’s only the design that could have tests written for it, in the time you had to write the tests.  The classes look reasonable at first glance, and the methods are seemingly bug free.  But the cracks are there, if you know where to look.

No pride in ownership

There is no ownership in pair programming.  You’re working on a different piece every day, with a different partner.  Everyone owns all the code equally.  No-one really has responsibility for a single piece of it.  Pair programming views this as a strength.

I had no pride in ownership.  The code that ended up on the ground every day wasn’t something I felt I had input into.  It didn’t feel right to me.  Doing a good job matters to me.  My idea of a good job: years after I’d moved on from one project, someone I’d never met wrote me a thank you note for taking the time to make my code clear and easy to work with.

The part of my brain that works though code will chew through things.  Impede the flow, and that part of my brain starts to itch.   Block it, and it starts pounding, chewing away at anything that comes close.  Without pride in ownership, there was no meaning to any of the work that I was doing.  I couldn’t even identify it as mine.

It was about this time that my physical health started to pack up.  Winter set in, and it started raining constantly.  I got a cold that got into my lungs.  I couldn’t climb the stairs without resting.  I couldn’t write code.  I couldn’t think.  The rain beat against my window.  I couldn’t sleep.

No escape

The worst part of pair programming was getting up in the morning and realizing I had to do it all over again.   No matter how drained I was, no matter how much I wanted to get away from people: I couldn’t.  As an introvert, I yearned to be left alone with a large problem and the freedom to slice it into pieces.  But there was no escape. 

Even at the best of times, there were people.  First, a fifteen minute standup meeting.  Then sitting down at a work station with engineers on either side of me, two to a table.  Talking.  An engineer sitting next to me in my personal space.  Every moment I was sitting there watching him, I was trying to think of something to say.  Whenever I was typing I was worried that I was too slow, or that I was taking too much time to think, wasn’t saying enough, wasn’t being clear.  Was I being anti-social?  Talking too much?  Too much smalltalk?  There was no way to know.

Even when pairing worked, it was the slow, clumsy communication of two people trying to move a large sofa down a staircase.  There was no flow.  There were no spots where there was no conscious movement between thinking something and having it appear on the screen.  I missed it horribly.  Even the small discussions: was having “as_currency” method on an ActiveRecord Model the correct thing to do?  Or was it something that should belong to the UI, as a helper method?  Just how much did I really care?

And then a group lunch, where there was food, small talk and team bonding experiences.  I started stealing moments of solitude whenever I could.  

I asked my co-workers if they saw what I saw, if I was missing something, anything -- I didn’t see how this could work, how people could keep doing this.  They said I was doing fine, that it just took time to settle in and adjust.  That it was hard for everyone at first.

Eventually, I retreated into myself.  Between the blinding headaches, the insomnia, and the pounding, unmet need to write code, I stopped responding to input.  I could stare at a screen and not see anything.  Someone could talk to me unexpectedly and I wouldn’t hear them.  I was fulfilling the rote requirements of my job, but I wasn’t there.  I’d used up everything I had just showing up for the day.  I started checking my iPhone when my other partner was typing.

Finally -- just shy of three months later, and for the first time ever -- I was fired for not being a team fit when pair programming.

Not Alone

I wrote this not just to understand it, but also to be able to talk about it.  There’s been a presumption that pair programming works for most people and is much easier and faster than programming solo would be.  This may or may not be the case, but as a long term practice, pair programming doesn’t work for me.  There are many other people that pair programming doesn’t work for either.  We matter too.

Mark Wilden had a similar experience at Pivotal Labs. His discussion of design rings very true.
Nick Carroll says that pair programming is not for him. He thinks peer review is more useful.
William Pietri has a list of anti-social practices, many of which I saw and/or practiced.
Software Reality has more to say about the XP approach to pair programming and design.
A CodeRanch discussion also discusses issues with pair programming, including Damon Black’s experience.
More generally, Daniel Markham talks about some gaps in agile as it is practiced and has made an interesting list of the responses.

Also, it’s important to note that I still believe that Agile development can lead to better business solutions with less wasted effort.  Pair programming is part of a single agile process called XP, and there are many other Agile processes such as Crystal Clear which do not mandate pair programming as a daily practice.

EDIT: I've read through the responses and replied here: http://tersesystems.com/2010/12/31/responses-to-where-pair-programming-failed-for-me

Comments

Leave a comment

  1. Avatar
    Brandon Ferguson about 2 hours later:

    Great read. My experiences were both much like yours and the opposite. Really it just depends who the pair is for me. Some guys are really great at managing the process others it’s just awkward. The headaches and fatigue you talk about it is so specific though. A pair programming headache is a singular thing to me. A good pair (for me) feels great and you have this nice collective ownership, you feel like you have a lot of velocity, it’s like a nice conversation. A bad one is a blinding headache and feeling absolutely spent by the end of the day.

    For me the lack of experimentation is a tough one. It can be good from time to time (as we all have our moments of going down some rabbit trail) but if I don’t really understand what I need to do pair programming can feel like a poor fit. I feel like you really need to have a vision for what you’re about to do or the pair can get mired down quickly.

  2. Avatar
    ty about 3 hours later:

    I could never pair program exclusively for many of the same reasons you cite. I like doing it for a half a day on tricky problems now and then, but that’s about it.

  3. Avatar
    Raymond Tay about 3 hours later:

    I share similar sentiments w.r.t pairing. In my experiences, i’ve found pair programming to be hindering, the least and disruptive as you’ve described.

    Also, it really depends on the person whom you pair with. If you get someone whose trying to convince you to do it his/her way, then it can get too much because there were times when i felt that i wanted to experiment. I often get inspiration to try solving the same problem in another way, just to see whether it works. On the other hand, if you get a YES-man to pair with - what’s the point?

    As a individual contributor, i’m used to working on solutions alone and even in a team we often are handed tasks that’s meant for individuals…pairing’s an alien concept.

    overall, your article echos those thoughts i’ve experienced.

  4. Avatar
    Artie Gold about 3 hours later:

    Ownership? Dude, you own it all!! And that’s the point. Code lives, coders move on. It’s a different deal than a solo project,

  5. Avatar
    Bob Remeika about 4 hours later:

    I can’t help but think I’m probably one of “the man” or one of “the men” that you are talking about :) I’m pretty over pair programming as a dogmatic discipline but I still think it’s very useful in some cases. That being said, you can still be Agile without being XP which is where I think the sweet spot is… and as a rule, Agile or XP should not be a rule :)

    WRT Grockit… ya, I think there were a few mistakes made in handling people, but from what I hear a lot/some of that may be fixed.

    Anyway, glad to hear that you are happy with what you are doing now. On a side note I tried to private message you on Twitter but you aren’t following me. What are you too cool? :) jk

  6. Avatar
    Rotsotnir about 4 hours later:

    @Artie: Ownership is different to possession.

  7. Avatar
    Jose Tavares about 4 hours later:

    Coding on your own or with someone else all the time can be detrimental. Programmers like to be able to think out the box when needed without someone there to possibly shoot down a master plan. Having someone close by or a phone call away to ask for insight is best for me.

  8. Avatar
    Kombinat about 5 hours later:

    Hey, great read. I think I would feel the same as you if thrown into that situation.

    However, I do think pair programming can work, when the time is right. I’ve worked at the agency I’m at now for three years and get on really well with our other developer, we are like Billy and Jimmy from Double Dragon, beating up on nasty bugs and coding problems. We can quite happily get through most of our coding on our own but sometimes the deadline is tight, the problem is particularly taxing and you just can’t do it on your own. This is where I’ve found pair programming the most helpful. Sitting down with someone, discussing the problem, working out the best approach and stepping through it together can get you great results very quickly!

    I think that when working in an agile fashion, it’s best to pick and choose the correct tools from the agile toolkit to get the job done best, pair programming is not always the best tool. It’s called ‘agile’ right? Why be so strict on the ways in which you could work?

  9. Avatar
    nc4494 about 7 hours later:

    i agree with brendan. a good partner who understands that programming is as much about remembering apis and understanding control flow through the system is always willing to pause to at least get an understanding for what is going on into a partner’s head.

    i have always thought that the master/apprentice relationship is particularly applicable (and never practiced, in my very, limited experience) to programming, and especially for introduction to a new software system.

    it’s not even about skill levels. i could mentor the shit out of a guy who was a way better coder than me (theoretically, as ive never managed anyone and dont think i am likely to soon - i am quitting corp and going solo - click me).

    basically you look at the problem ticket or feature spec. watch the guy with the experience on the system introduce the software and the motivation (this is talking, not code). say how he’d think about solving it. sketch it out. offer the new guy a chance to understand what’s going on and ask all kinds of questions. even the obvious, if proprietary or novel is extremely nonobvious on your first day.

    let the guy get a grasp on it and give him tiny problems to solve. as the days go on the balance shifts, his problems get harder. eventually since he is a better programmer than me it is he who is doing most of the talking and me asking the questions, going to him for guidance.

    i dunno.

    i have always been extremely disappointed with how i’ve been mentored (or not at all, specifically) at software companies. i’ve been programming for 15 years and i’ve cobbled together pretty close to a mastery. but how much easier and more fun it could have been…

  10. Avatar
    Joseph about 7 hours later:

    It sounds like you had some bad pairs. Some of it was just bad pairing, not allowing you to go at your own speed, and get your ideas out.

    Some of it was bad process:

    -Refactoring is a necessary step in TDD, simplest is not always the best. It’s the best first pass to get the tests under you, but after that you should always look to refactor.

    -Forcing everything to be done and committed within a day? That’s not going to lead to good coding practices. I’ve had multi-day refactorings that were needed to make features realistic.

    That said, you very well might not enjoy pair programing. Not everybody does. But it does sound like the environment where you were first exposed to it was somewhat toxic.

  11. Avatar
    JohnSyd about 8 hours later:

    Completely agree. Pair programming is like finding two good runners, tying two of their legs together and entering them in a three-legged race. There have been famous examples of pairs who performed better together than on their own (Crick & Watson) but these people chose each other, they weren’t assigned by a manager.

    I prefer peer review - I can use non-verbal thinking to get the design & coding done. Once the task has been done, I can translate the concepts into words.

    There’s also a flow to coding on your own that is disrupted by having to explain everything you do as you do it.

  12. Avatar
    Leo III the Isaurian about 9 hours later:

    Pair programming in a non-dogmatic fashion can be fantastic! However, pair programming as you’re describing it here, sounds like a desperate attempt to try and disperse “knowledge” about a code base amongst a group of programmers, so as to minimize the loss when one of those programmers moves on to somewhere slightly less ridiculous.

    Agile has pretty thoroughly jumped the shark at this point. It is turning into a silly dogmatic school of gibberish that has nothing to do with producing reliable, adaptable code, and everything to do with providing “coach” gigs, and a false promise to business folks that they will be less reliant on any particular programmer. Object Orientation used to fill this role, but the thing with marketing ploys is that you have to keep making up new ones to draw attention away from the fact that the last one you sold didn’t deliver, and in fact introduced a big pile of problems of its own that have nothing to do with either the inherent technical constraints of the computing platform, or the business problems you are trying to solve.

    Building software is hard, good programmers are hard to find, and maintaining healthy dispersion of knowledge in an organization requires intelligent people acting in good faith. Object orientation doesn’t change this, outsourcing doesn’t provide it, and agile isn’t really going to deliver a cookie cutter solution either.

    Business people!

    (who almost certainly won’t be reading this blog post in great numbers)

    – you need to realize that if you are actually going to produce anything resembling cutting edge technology which will actually give you an advantage in the marketplace, and not provide maintenance nightmares after you have already signed contracts with customers, you will need to find smart, ethical programmers, pay them well, and provide them with a nice working environment.

    Joel Splosky is right on the money on this one.

  13. Avatar
    sax about 9 hours later:

    Wow. Seems like a lot of small mistakes that negate the reasons for pairing.

    • the faster person has to slow down to the speed of the slower person. If that means you don’t finish things quickly, that’s fine. Part of the point is that the slower person learns the codebase faster by having someone there to answer questions and give you solutions that otherwise would take hours of research. If one pair does all the work, something is wrong.
    • done in a day? That’s retarded. So long as one of you stays on the feature it’s fine. In fact, it winds up better that way as more people have knowledge about new features.
    • there’s always going to be experimentation. One of the benefits of pairing, though, is that you have someone there making sure you don’t go into a rabbit hole for hours or days. But you can’t stop taking risks just because somebody else made a decision a year ago. I tend to experiment a lot, and it’s nice to have another person there suggesting simple solutions when my experiments fail. It helps me to put time limits on my work and cut it short if it doesn’t wind up working.
    • refactoring is necessary at all times. If your tests make it impossible to refactor, you’re writing your tests wrong. Tests should make it faster and easier to refactor… if you have integration level tests written for the current code, you can delete whole blocks of implementation-level tests and replace them with new tests and new code.
    • everyone should be able to solve any problem with the code base. Some people (and some pairs) will be faster than others. But everywhere I’ve worked where there is no pairing, every bit of code winds up owned by one person, and any problem that comes up has to either be fixed by that one person or has to meet with their approval. When you pair and you write tests for everything, the tests define the behavior and everyone winds up responsible for the whole code base. You own the quality of the code, not individual implementations in it.
    • one of the business benefits for pairing is that developers have to talk through solutions more. Complicated problems don’t always benefit from diving straight into code, and having two people agree on a strategy before starting often saves hours of failed work.
    • simple solution == no design strategy? I think the people you were working with had problems. The idea is that you don’t build a freight train when what you need is a wagon. You’re not going to get very far if the only tools you’re allowed to use are a brick and some chewing gum, though. If they didn’t understand the design, your job should have been to help them through it. If you had trouble testing it, their job should have been to help you find a way, or adapt your pattern so that it could be tested.
    • it’s a lot easier to forget discipline and take low quality short cuts when you don’t have someone there watching you.

    I do know people that don’t like pairing. I have to say that their output is higher quality and gets delivered faster when they do pair, though. And it’s all worth it for the days that I get to pair with the people who I have to fight to keep up with, or who immediately rewrite my implementations with a better pattern that I’ve never seen before. It’s so much more fun.

  14. Avatar
    John Wilger about 9 hours later:

    Sounds to me like the place you’re talking about had a lot of issues that would make even the strongest pair-programming advocates throw their hands up. It seems like they bought the bible but don’t really get the philosophy. Granted, you may not like pairing at all no matter what—it happens; but when it’s done correctly with a group of capable developers who pay attention to the other important aspects of craftsmanship, I think you would have a different experience. It’s easy to get pair-programming wrong, especially when the people involved are doing it just for the sake of saying they are pair-programming.

  15. Avatar
    Andrea about 10 hours later:

    Pair programming in university is probably much more fun. XD

  16. Avatar
    Simon Brunning about 13 hours later:

    I’d echo a lot of what sax says above, and add that pair programming itself is a skill. You can learn it, and you get better with practice. It sounds to me like neither of you were experienced with pairing, so naturally it’s difficult.

    Ideally, at least one of a pair is experienced with pairing, with the rhythm and flow, and with balancing the various desired outcomes. Of course, in the real world, you can’t always get that, but if neither of you are familiar with pairing, you have to expect to give it time.

  17. Avatar
    Dave about 15 hours later:

    I hear ya. Fortunately for me I’ve worked with not just smart but reasonable people. Smart people know how to do things, reasonable people know why to do things. I’ve also been fortunate to be stock resource developer (a.k.a. cog in the machine) and also held team lead and architecture roles. My experience of pair programming is that you gotta find the right fit & don’t swap folks around simply because “that’s how it’s done”. I used to pair guys up in experimental/throw-away code exercises & see which guys worked well together, where it flowed like conversation as you put it. I’d keep those folks together to solve a problem or re-write a subsystem. At the end of the day, my philosophy is that methodology should fit people and not the other way around. Find someting that works for your team and do it that way. As long as the results are good for the business and I’ve got a happy, motivated team - does it really matter?

  18. Avatar
    mehgerbil about 15 hours later:

    If I had to program that way I’d get a different job. Hopefully, it will be recognized for the ignorant fad that it is and slowly fad away. What other job mandates this sort of idiocy?

  19. Avatar
    Trish about 16 hours later:

    It sounds like you had a lot of negative experiences with pairing. I’ve only done it a couple hours at a time which was ok. I agree that if done constantly, I would go crazy with needing alone time.

    I don’t mean to sound offensive, but I’ve been studying Autism a lot lately for myself, and the issues you describe sound very familiar; needing alone time to recharge, having difficulty reading people, needing to put in extra energy for interpersonal interactions, trouble understanding what social “rules” you are meant to follow. I know this could describe almost any computer geek out there, but there is a defining difference and it’s helped me understand myself better.

  20. Avatar
    Sebastiano Pilla about 17 hours later:

    Hi Will,

    Thanks for the great writeup. When I saw your original post about pairing at Grockit I realized once more that I couldn’t stand it for more than one day. It is, as you say, as being forced into a day-long meeting each day of each week.

    My thoughts form and go away orders of magnitude faster than I can express them, verbally or in writing: the code I write is the result of this thinking, it is what makes this profession a satisfying intellectual experience for me. If I cannot think, I write bad code. If I cannot think, I’m not much more than an overpaid typist.

  21. Avatar
    Jim about 17 hours later:

    I’ve had some good experiences with pair programming, one in particular - I worked with another engineer first on designing a feature (pair design). Then we implemented the feature using pair programming in about an afternoon. I felt that we probably implemented the feature in about 1/3 of the time than either of us would have if we did the work alone. I think that because we did pair design first, we were on the same page with the requirement and what needed to be done. We also talked through different scenarios that definitely improved and made the work more solid. We were able to catch a few bugs that would have been checked in and not found with the unit tests thanks to a second pair of eyes looking at the code. The other positive outcome was that we both knew and understood the code, so either one of us could maintain it.

    But, I would never want to work like this as a rule. I think you have to pick your spots to use pair programming where it makes sense. I’ve worked on projects where we had mandatory peer review before committing any code to the source repo, and have some mixed feelings about it but overall felt that it was a positive because it had the benefit of catching bugs that the unit tests couldn’t catch.

    I think that any methodology, procedure, technique, process that is applied and used without flexibility and common sense will hinder a project. Pick your spots to use pair programming. One of the beauties of a team that self organizes is that they will know when to use it and when not to.

  22. Avatar
    triptyx about 17 hours later:

    “And if I was writing code, I found something very interesting: I don’t think in English when I write code. I think in code first, and I can translate written code to English.”
    – You’ve gained language fluency when coding. This is an excellent description of many more experienced programmers in my opinion. I’ve noticed that when someone is pointing something out to me, I couldn’t find the broad side of a barn. Looking at it and reading it myself, I immediately get a good sense of what is going on on the screen in front of me.

    “The part of my brain that works though code will work and chew through things. Impede the flow, and that part of my brain starts to itch. Block it, and it starts pounding, chewing away at anything that comes close. Without pride in ownership, there was no meaning to any of the work that I was doing. I couldn’t even identify it as mine.”
    –This really describes myself as well. I enjoy this job because I get to sit down and solve puzzles all day long. In order to solve those puzzles, I have to be free to let my mind range out across the code and data to get that final picture of what is really occurring (versus what is supposed to occur) so that I can solve the issue. Having to explain the picture I’m trying to form, while I’m trying to form it, smashes the nascent image and forces me to start over. This is not to say I don’t work well in a team, I just feel that there are times to sit down with other developers and work something out, and there are times where you just need to focus on the code yourself and come up with a solution. That solution is still open to peer review, but getting there doesn’t always have to be a team effort.

    Well written. I think that XP is like anything else - a tool to be used when appropriate. It is not for everyone, or for every situation. You can be an amazing developer and yet be completely worthless at XP. Ultimately, we all think and operate differently, what is great for some is detrimental to others. Doesn’t make it right or wrong. :)

  23. Avatar
    Marc Hedlund about 18 hours later:

    This is a great post, both well-written, honest, and considered. Thanks so much for taking the time to write it.

    For whatever it’s worth, speaking as someone who has hired hundreds of engineers over the years, what you write above makes me want to hire you. You talk about a lot of the things that matter to you and many of those things match perfectly with people who make great products, in my experience. I think you should view being fired from a company repressing those things that you describe wanting from your work as a compliment and a validation.

    Thanks again.

  24. Avatar
    Jerome about 19 hours later:

    You’re kidding, right? Please tell me that you people are making this up. “Pair programming”? What’s next, No Programmer Left Behind? It Takes A Village to Code A Do Loop? From each according to his stupidity, to each according to his typing speed? Unbelievable!

  25. Avatar
    Elliotte Rusty Harold about 19 hours later:

    Some of what you report is very common in pair situations. Yes, pair programming is more exhausting than regular programming, especially for the more introverted programmers, but not just them. Pairs do more work, and get more things done. That isn’t free. You are working harder when you’re pairing. Some of what you’re attributing to pairing though is not related to pairing at all, and some is simply a case of doing it wrong.

    As to do doing it wrong, the major flaw was that you did not speak up enough.

    “If I asked a question, then work stopped.” No, asking and answering the question is part of the work. “If I asked about the background of the code or the design, then work stopped.” Again. That’s part of the work.
    “If I tried to follow along, then I found that I was trying to guess at what various methods and frameworks did. I was being bounced between the domain classes, the Erector classes, the Javascript and the various tests, and I didn’t have a grasp on any of them.” That’s when you should stop the other programmer and ask. You have to do it as a pair, not as one typist and one crash test dummy. “I understood the HTML code, but even there, I didn’t even know what to say – did I point out the typos? The two methods that were almost exactly the same except for the innermost loop? Was I nitpicking by pointing these things out, or signalling my involvement?” Yes, you should have pointed out all errors you saw; and trivial errors shoudl have been fixed trivially.

    However, some of the problems you report were not pair issues. For instance, the poor design and the refusal to refactor have nothing to do with pair programming. Those are pathologies of their own. If the design was bad you should have worked it out at a white board with the team or your partner. Pairing, at least at the keyboard, is about coding, not designing. Refactoring the pair should have simply done. If your partner refused, then ask the team. Maybe the team didn’t want to do this either, and maybe the team didn’t want to implement a better design. However these problems are, if anything, more common on teams that don’t pair. They are issues, but don’t attribute them to pair programming, any more than you would attribute a malfunctioning air conditioning system or the noise of an office undergoing construction to pair programming.

    The biggest problem seems to be that you and your pair didn’t communicate. That “there was simply no leverage to explore the framework or try different approaches. Any code changes that weren’t immediately applicable to changing the current page were ‘going off track’.” is something that you should have resolved with your pair away from the keyboard; and once that was resolved proceeded to coding. Decisions were made about how the project would be architected and designed. Maybe they were right and maybe they were wrong–I don’t know–but those decisions are separate from the details of whether you code them with or without pairs. One of the things that pairing avoids is having a programmer go off on their own and produce something that does not fit into the team’s plans. If the plans need to change, then change them, but doing it in isolation without telling anyone what you’re up to is a passive aggressive recipe for failure.

  26. Avatar
    Joe Mama about 20 hours later:

    You’re kidding, right, Jerome? 2010 and you’ve yet to hear of pairing?

    What’s next, you haven’t heard of design patterns? TDD? Where does the ignorance end?

  27. Avatar
    Joe Mama about 20 hours later:

    mehgerbil said:

    If I had to program that way I’d get a different job. Hopefully, it will be recognized for the ignorant fad that it is and slowly fad away. What other job mandates this sort of idiocy?

    Are you talking about the idiocy of pair programming or the idiocy of working alone in cubes?

  28. Avatar
    Eric Sipple about 20 hours later:

    I’m frustrated that the standard response to every criticism of Agile is that the person just wasn’t doing Agile correctly. Elliotte’s response, for instance, basically an iteration of “If you did it right, you’d have liked it more.” I don’t think this is fair at all, and it denigrates the people who have had valid frustrations with various Agile practices.

    It speaks to an level of rigid process adherence in the Agile community that isn’t very healthy. Over and over, defenses of Agile and XP center around a need for all developers, everywhere to follow every precept to the letter, in every case. There’s no room for developers who find parts of the ideology tiring or frustrating; they’re just not working hard enough, or they’re doing it wrong, or they’re not doing everything enough of the time.

    Like the author of this post, there’s a lot I like about the core ideas of Agile, but I’m falling further out of love with a community that treats it as a set of rules rather than best practices. The idea that a good developer is just less productive following one of the rules than they would be without it has no place in the community; the rule is never wrong, only the developer.

    Anyway, this was a great article, and it’s good not to feel alone with some of these frustrations.

  29. Avatar
    Raphael Boa Nova about 21 hours later:

    Seems like you lived a hell of bad process and incompatibility there.

    Although I see myself as a lone wolf while programming, I’ve already experienced the good parts about pair programming and I say it has its advantages. The way I see it, it’s more like a dating but without the physical intimacy part (well, there’s nothing preventing this if the pair so chose of course), it’s like a business partnership: this only works if you work with someone who helps you finding a solution faster, and not just typing together. It won’t work with every programmer. And it works best with a good friend.

    This place where you worked, they’re doing it just for the sake of doing it. Nothing in this world works this way.

  30. Avatar
    Mark Wilden about 23 hours later:

    I share most of Will’s impressions of pair programming (which is why he cited my own article on the subject). I didn’t respond quite as negatively as Will, but then I only did it for a month - not three. If I’d tried to stick it out at Pivotal for three months, I probably would’ve gotten fired too.

    I can also relate to the glorious pleasure of NOT pairing, and I described that in a follow-up article: http://mwilden.blogspot.com/2010/12/why-i-love-solo-programming-and-why-i.html.

    However, I do think it’s important to realize that many smart people do love pair programming. Done right, with the right people, I think it’s more productive, too. But for people like Will and me, at least, it’s just not fun.

    Thanks, Will, for articulately some of the feelings about pairing I didn’t even clearly recognize I had. :)

  31. Avatar
    Al Biglan about 24 hours later:

    I like the write up form the first person perspective. I agree with some of the other comments that the failings here are more “meta” than pair.
    (caveat/bias warning - I’m a manager would likes Agile, prefers XP, and encourages (but doesn’t force pair programming))

    Why were you two pairing at all? If the one guy was the “guru” and the code needed to be “cranked out at any cost by the end of the day” what did pairing buy you two (or the company)??

    I like pair programming precisely because it “distributes the knowledge” You had a chance to work with someone very familiar with the code but there was no learning, no information sharing. The one programmer now remains the only one (or one of a few) who understand the code. When it fails/needs to be updated, he has to come off of his uber cool R&D project to fix it. The whole team isn’t up to speed with the design or the implementation. Pairing helps distribute this. You slow the one person down for longer term benefits (more people aware of the code, more people wanting to improve the code base)

    I appreciate not all personalities work well in pair programming, and it can be a disaster if “forced” on people. It sounds like pair programming was chosen as the way to do things and then allowed to go feral. I’d suggest trying it again in a more constructive environment.

    my two cents

  32. Avatar
    Alan Franzoni 1 day later:

    It seems that your employer’s vision of pairing was… impaired?

    I assume that full-time pair programming might be hard, even though I never did that; also, pairing never meant to me “forget about quality”, mostly “think twice about quality” - a cheap workaround to mask a design flaw would never be accepted while pairing. Also, design and experimentation can be done in pair, and it’s usually a good thing indeed! Your partner might help you stretch your experiments to an extent you’d never image.

    I am under the impression that your employer just embraced pair programming but sacrificed other important aspects - code quality, individual satisfaction, etc. - but don’t blame pair programming for that.

  33. Avatar
    Ron 1 day later:

    I’ve experienced all of these frustrations. To me a lot of the promise of pair programming is built upon a foundation of lore that is often incorrect. Here are some of the most offensive myths about it:

    1) Doing the simplest thing that could possibly work will result in great code. This notion aggravates me to no end, because the simplest thing I could do to solve most problems is copy/paste something that someone has already done. This hardly ever is a good solution, but simple means fast in the minds of most developers and their managers.

    2) You’re more productive when you pair. Oh really? Is this because (if I’m driving) I’m in a continuous dialog about what I’m thinking/what my goal is and therefore not able to get into a flow? Perhaps its because my pair suddenly thinks of some interesting anecdote that totally disengages us from the problem at hand for X minutes? Whatever the reason for this massive boost to productivity, I don’t usually come away from the exercise feeling like I couldn’t have done the same thing faster had I ditched the side car at the start of the journey.

    3) If Uncle Bob said it, it has to be right. I once listened to a podcast where Robert Martin was asked the ideal amount of time two people should pair together. Without missing a beat he threw out 15 minutes. Okay, if I’m supposed to work on a programming problem, I’m just starting to get my mind wrapped around the context of the thing in 15 minutes. Snake oil anyone?

    4) Collective code ownership means we all understand the system! Actually, if you combine point #1 with point #3, it means that it is impossible for anyone on the team to be able to reason about all the sub-systems in a decently complex project. Just because I can read 1 paragraph out of every 50 in a book doesn’t mean I have a good appreciation for its content, and the same is true of coding.

    5) Two people can naturally collaborate because its just somehow human nature. The fact of the matter is that there is nothing that prevents people from bringing their own brands of crazy to a pairing situation, whether its the guy that wants to convince you of Intelligent Design because he has a Christian agenda, the woman that wants to convince you that condoms are completely ineffective against AIDS because she has some wacky Faux News-ism of the week stuck in her head, or the reserved guy that constantly gets abducted by UFOs (except when pairing, of course).

    6) Pairing will make a better programmer out of you. In my experience this is true when paired with the right people. I think that a lot of the time that I’ve paired I’ve been either clueless and riding someone else’s coat tails because they were a domain expert and couldn’t be bothered to slow down and edjumicate me, or I was that domain expert trying to deal with wandering attention spans (cell phones, conversations between other pairs, etc) and people who were not really interested in the problem in the first place.

    There are other great myths out there that elude me for the moment, but while I appreciate the spirit of what pair programming is trying to achieve, I see it as having too many holes to be practical on a continuous basis.

    On a large project my team was working on, the customer asked to see a piece of our code that was representative of the quality of our work. Out of hundreds of thousands of lines of Java code, it was very hard for the team lead to find anything that he’d be proud to hang our collective hats on, including some of the code he’d come up with himself! This is mostly attributable to myth #1, but it definitely resonates with what the blogger has said about pride in ownership and doing a quality job.

  34. Avatar
    Mark Wilden 1 day later:

    TSTTCPW was never intended to be applied in isolation. In particular, it doesn’t count if you violate DRY (or Once And Only Once, as it was first described). More generally, agile techniques only work if you follow good principles of object-oriented code. Kent Beck elaborated all this over 10 years ago. He held that, having reached a certain level of development skill, we can then defer costs with the knowledge that we won’t paint ourselves into corners.

  35. Avatar
    Brennan 1 day later:

    Every moment I was sitting there watching him, I was trying to think of something to say. Whenever I was typing I was worried that I was too slow, or that I was taking too much time to think, wasn’t saying enough, wasn’t being clear. Was I being anti-social? Talking too much? Too much smalltalk? There was no way to know.

    Sounds like you have a lot of social anxiety.

  36. Avatar
    Wael Al-Sallami 1 day later:

    I’ve interned at Square, and when I first started there, I was pretty much in the same situation as you are, I knew PHP very well, but had no idea about Ruby on Rails, so I was basically squeezing my brain just to understand the simplest things and not look stupid by asking my pair about them.

    But there is a major difference between you and me here, let me explain:

    I was very familiar with HTML, CSS, and jQuery, so when I paired with the UI designer in the company, I felt right at home, I was writing code in the first five minutes, I was giving suggestions, sharing ideas, and correcting mistakes for my pair …. I actually enjoyed it, a lot!

    So what I’m saying is, for pair programming to work, every aspect of the workflow should be very familiar to the pair of programmers, I mean think about it this way, you had no idea about Ruby, SASS, jQuery, and Erector …. did you even expect your staying there to be pleasant? even as a lone programmer? you didn’t know not even one thing about the entire workflow of the company, what did you expect?!

  37. Avatar
    Wael Al-Sallami 1 day later:

    I’ve interned at Square, and when I first started there, I was pretty much in the same situation as you are, I knew PHP very well, but had no idea about Ruby on Rails, so I was basically squeezing my brain just to understand the simplest things and not look stupid by asking my pair about them.

    But there is a major difference between you and me here, let me explain:

    I was very familiar with HTML, CSS, and jQuery, so when I paired with the UI designer in the company, I felt right at home, I was writing code in the first five minutes, I was giving suggestions, sharing ideas, and correcting mistakes for my pair …. I actually enjoyed it, a lot!

    So what I’m saying is, for pair programming to work, every aspect of the workflow should be very familiar to the pair of programmers, I mean think about it this way, you had no idea about Ruby, SASS, jQuery, and Erector …. did you even expect your staying there to be pleasant? even as a lone programmer? you didn’t know not even one thing about the entire workflow of the company, what did you expect?!

  38. Avatar
    Scott 1 day later:

    Fantastic article. I love the points about how it is like having to be an active listener in a meeting, and the point that we think in code not in english and there has to be a translation step.

    Everything you say is true.

    I would go further, to say pair programming is a cult religious practice with no benefit whatsoever except to exhaust and wear down new cult members to accept further indoctrination and cult programming, and that the practice is dangerous as are those who promote it.

    I agree with Mr. Carroll that code reviews are a good practice which actually deliver what pair programming promises.

  39. Avatar
    Mark 1 day later:

    I can totally relate to Dave’s experience “Smart people know how to do things, reasonable people know why to do things. My experience of pair programming is that you gotta find the right fit & don’t swap folks around simply because “that’s how it’s done”.

    As of today, I don’t like pair programming, probably just because I seldomly had the right pair partner, but often ended up with one of the following types.

    The Generalizer: “Hey, let’s make this piece of code a litte bit more generic.” The Generlizer likes to create YAGNI designs that tend to be hard to read because of the chosen generic identifier names. When you offer them more readable, concrete solutions (which would suffice, in fact) over their generic solution you get a disapproving glance “Yes, but your solution is inferior. Didn’t you learn that in unversity?”

    The Explorer: “Let’s try out this new framework I read about yesterday, it should make our code much simpler. Or let’s use this new library CanDoAnything 0.0.2” We might as well write these two methods on our own and would have (1) tested code (2) sooner.

    The Performace Unaware: At the bottom line this type doesn’t get that both database queries and network access are both so much more expensive than method calls. Paired with a “produce the simplest thing that might work” attitude this type is able to create wonderfully bad performing architectures. (I am not talking about premature optimization here, but the ever occuring mistakes of N+1 database queries and GET requests.)

    The Philosopher: “Wouldn’t it be nice if we …” Yes, some day it probably would. But would it be reasonable to do that now? Or smart?

    All types have tended to slow me down and lead me to produce solutions which I am often not very proud of.

    On the other hand, I had the privilege of working with some very experienced pair partners. In these cases most conversations consisted mostly of nodding to each other or sometimes a “Oh, you forgot to check for X over there.” - “Thank you. Wanna fix it yourself or rather lead me how to fix it best?” In these situations I really felt how the two of us were able to produce better code then one of us alone would have.

    sax says ‘it’s a lot easier to forget discipline and take low quality short cuts when you don’t have someone there watching you.’. Unfortunately, I often found the contrary to be true. Some people are slowed and bogged down by their pair partners to the degree that they create worse solutions.

    If all that sounds too arrogant than this might stress the whole point: Watch out which pairs work well together and produce better solutions than any one of them alone would - and which pairs don’t.

    All in all I think many of Pair Programming’s promises may better be delivered by different tools, e.g. higher quality by pair reviews and collective code ownership, better “truck factor” by better documentation.

    Happy new year! Mark

  40. Avatar
    Bubba 1 day later:

    1 + 1 = 0

  41. Avatar
    Steve Conover 2 days later:

    Sax and others who come at this from the “you’re doing it wrong” POV ought to be dismissed out of hand. Pairing turned out badly for the writer, but he obviously gave it a go, and has much more insightful things to say about the experience than most of the committed pairing advocates in the comments.

    Put another way, claiming someone like this is doing it wrong is evidence that the practice has become dogma for you. You’re unwilling to reconsider your premises or admit that some evolution of the practice - or at least reflection on it - might be in order.

  42. Avatar
    Steve Conover 2 days later:

    I think that any methodology, procedure, technique, process that is applied and used without flexibility and common sense will hinder a project. Pick your spots to use pair programming. One of the beauties of a team that self organizes is that they will know when to use it and when not to.

  43. Avatar
    Steve Conover 2 days later:

    I think my comment got eaten.

    Jim: “I think that any methodology, procedure, technique, process that is applied and used without flexibility and common sense will hinder a project. Pick your spots to use pair programming. One of the beauties of a team that self organizes is that they will know when to use it and when not to.”

    Well said.

    I often wonder to what degree these 100% pairing advocates are motivated by some kind of invisible agile cop in their heads. It’s much more interesting to me to act in a frame of mind that’s something like “ok, here are all these process tools. Can any of them be brought to bear to help solve the problem in front of me?” vs “I need to make an effort every day to minimize my deviations from The Rules”. Sometimes the right answer is to go hide in a hole for a day and try stuff out. Sometimes it’s an intense pairing session.

    I wonder what makes teams afraid to use experience + a fundamentally collaborative setting and make good case by case judgements? Does the policy part come about simply because we think other people won’t make the right judgements?

Comments