I'd like to thank everyone for reading the blog post. It got far more attention than I was anticipating, and while I'm still processing everything, I'm touched by how much people "got" what I was saying and responded positively to it. There are a number of people out there that have had the same experience (or close to it) that I had, and while it's not exactly fun to admit vulnerability, I'm happy I did it just to hear from you guys.
So, on with the show. There were a number of responses either in blog comments, or on Twitter (holy god Twitter exploded, thanks @buzz and @tenderlove), or on Hacker News and Reddit. I thought about responding to comments individually, but it makes more sense to write it up on the blog itself. In no particular order:
“You weren’t really doing pair programming”
This is an easy statement to make, and a lazy one. There were a number of engineers there, all of them very competent. Pivotal Labs had gone through the space on at least two occasions. They had several Pivotal Labs alums on staff, and the bulk of the programming library was Agile and XP books. They all believed this was pair programming. If that wasn’t pair programming, I don’t know what is.
I anticipate the response to be "well, it wasn't done the way they say to do it in the books." Yes. That's because nothing is done the way it's done in the books. Ever.
EDIT: And as far as I can tell, they were working directly from the book in that "all significant development is done in pairs" and "If you prefer to work alone, that's fine. You just can't work with us." People who are saying pairing is a part time or optional activity -- are they also doing it wrong, or just tailoring it to their team? Different practices are agreed on for different teams, and this was the practice they chose.
“You walked into a situation where you didn’t know any of the tools. What were you thinking?”
I was thinking that pair programming would be an excellent way to be mentored on the appropriate use of those tools. I was upfront about my lack of experience with those tools and front end programming in general, and was looking forward to learning about it. Bear in mind I wasn’t going in cold: I know Ruby very well and knew at least the principles of jQuery, while knowing enough CSS and Javascript to get by. But you’re correct: it was a large part of the problem initially.
Something I touched on briefly in “No high notes”: the best way for me to get the feel of a framework is to sit down and work with it. I’ll read through the manual, build a couple of example applications and push the limits of what it can do. I’ll read through the source code, sign up to the mailing lists, find a couple of embarrassing bugs, and I’ll know the shape of it in my head. And that knowledge is solid: I can tell you some fine details of a framework even if I haven’t touched it in five years.
I couldn’t do that when pair programming. Lectures and presentations tell me nothing about what the first hand experience is: it’s like thinking you know how to ride a bicycle because you saw it done on Youtube. Time after time, my partner would happily dash out a complex jQuery statement pulling out an element by its div and class attributes, and I’d then struggle to do something similar while I was still figuring out the syntax. Every day, I’d get more and more of an overall larger picture of the system, but it was through the corner of my eye as we were whizzing past to our destination.
“You should have spoken up more.”
That's a fair question. Why didn’t I speak up more? I asked co-workers about my general experience and raised some concerns, but I didn’t push nearly as hard as I could have.
The best answer I could give is that I expected it to be hard at first, and then to get progressively easier. At the point where it wasn’t getting easier I was concerned, but I wasn’t going to tell them they were Doing It Wrong. Remember that I was coming into pair programming with a very different background, and was there to learn. I did speak up when it came to the design and refactoring issues I saw, but when it came to XP I had no basis for comparison.
I did tell some of my partners to please stop grabbing the keyboard and suggested that I could tackle problems that didn’t require a pair, but XP is fairly clear that pair programming is the rule, not the exception. XP is also clear that this way of working makes programmers happier and more productive. Ultimately, I wanted to believe it. I told myself my own experience was wrong and that the hundreds of books, blogs and comments were right. I kept quiet.
“You knew pair programming was what they did and you had an interview where you pair programmed: how did you not expect this?”
Also a fair question. The truth is that I didn’t know what to expect, and nothing that I read in the literature lead me to expect that I would dislike it as much as I did. The initial interview was, by necessity, done in a couple of hours with a single person in another room. The following day of pair programming had to be cut short due to a misunderstanding with the recruiter: we’d only scheduled an hour. The problem that was supposed to have taken a day was mostly fixed inside of that hour, and we all enjoyed the experience.
“Have you considered autism / you must suffer from social anxiety.”
No, I suffer from introversion. (Although, some might say I suffer from extroverts.) Put simply, interaction with people tires me and drains me of energy. Being in a quiet room with one person is fine. Keeping an active conversation with background noise or a television is a noticeable drain. Keeping a conversation up with several people at a party where loud background conversations are happening is a larger drain. And about thirty minutes in IKEA is enough to turn me into a zombie.
I can certainly behave in autistic fashion when I’m low energy, but it’s not my default state. And social anxiety is something that everyone is prone to, especially when things don’t seem to “work” but it’s unclear exactly what to fix.
“Pride in ownership is a bad thing”
It wasn’t the best phrase I could have used. Pride in good craftsmanship would have been better. I have absolutely no problem with people refactoring code -- just because I wrote something and it worked for a particular problem at a particular place and time doesn’t mean it can’t be made better. Seeing how people looked at my code and did one better is actually one of the perks of the job -- the day I stop learning is the day I hang my hat up as a programmer.
“It was a dysfunctional / deathmarch environment.”
Actually, no. While it was a dysfunctional environment for me personally, most of the people there certainly seemed to be very happy. It was about as far away from a death march as you can imagine. Bear in mind that there were 10 programmers on the team, and we switched daily. It’s not like I had one bad partner: it didn’t gel with any of them.
They were doing a UI redesign of the entire front end, and had a hard deadline based on the engineers they had at the time. They had evidently spent much time determining the tools and wireframes involved in the redesign. For many of the engineers there, this was a long overdue opportunity to sit down and really crank. Some of them were amazingly intelligent and ambitious people, as good as any I’ve worked with. Pairing with me must have been a frustrating experience, especially for the younger developers who were not used to being mentors.
For my part, I was frustrated by my own lack of skill working on the front end, and was keenly aware that I was slowing people down every time I asked a question. Rightly or wrongly, we had a job to do. No matter how patient and giving they were, ultimately we were being tracked on our points delivered.
And furthermore, I think this is a lazy response. It’s the moral equivalent of having a user file a bug, assuming user error, and then closing the bug as WORKSFORME without actually looking at the code.
Bear in mind I am not saying that their approach to development was flawed in principle or even in practice -- I was but one engineer out of many and they had to consider the entire team. Bear in mind that this company followed XP down to a very fine detail and prided itself on its software process. Bear in mind I joined this company specifically because I wanted to work in a company that did Agile. I would have left immediately if it had been obviously dysfunctional or a deathmarch.
“Why were they pairing if they had a fixed deadline and needed to crank out work?”
Good question. Given the context and the relatively straightforward work that they were doing, I believe that the project would have been completed faster if they had not been pairing for the duration. It may have been slightly lower quality, but it could have worked. It may have been that they judged the benefit of always pairing to be more valuable that any short term gain.
But honestly, my guess is that the question never occurred to them. Pair programming is a core practice of XP. If you’re an XP shop, that’s what you do.
“Pair programming can produce amazing work”
This is something I don’t dispute. Almost everyone I know, myself included, has done pair programming at some point and had positive results. Even Dijkstra pair programmed and found some use in it.
However, that’s very different from saying that long term pair programming is flat out better, which is what XP says. Most studies find little appreciable difference between the work that a pair does, and the same work done individually. Anecdotal evidence is not reliable in this field because humans are subject to all manner of cognitive bias; Hacknot (an under-appreciated website that is now an ebook) does a wonderful dissection in Anecdotal Evidence And Fairy Taies. I’m not saying it’s a worse practice in general. But a meta analysis shows that there is no statistical evidence that this is a better practice overall.
Leaving that aside, there’s the small problem that programmers are not fungible. The best programmers are up to 28 times better than the worst programmers. Even if pair programming were proven to help the average programmer, it won't work for some edge cases.
Tying a good programmer to Guy Steele or Richard Stallman will make the good programmer slightly better, but will drastically impede Steele or Stallman. Even tying Steele and Stallman together (or even better, Stallman and Gosling -- they're both Emacs fans, right?) wouldn't produce the output of a Voltron-like superprogrammer (EDIT: I am wrong. They did, and it did.). And while I know some people who would love to be paired with Zed Shaw, Jamie Zawinski or Hani Suleiman, I’m fairly certain there are others who wouldn’t survive the experience.
The Point
This is my point: One size does not fit all. Individuals and Interactions over processes and tools. And if you’re considering implementing a process, think about your team and consider what works for them. As Elisabeth says, introverts need attention too.
Comments