This guy describes a really common antipattern I've seen with pair-programmers, call it "Workstation Chain Gang". This is where all work is done sitting side-by-side at a computer, and the only times you get up are for the bathroom or eating.
The best pair programmers I've worked with will often do things like: say "let's take a walk" and then talk through design problems, get up and use a whiteboard, say "I want to read about this. Let's get back together in half an hour." Or even say, "I need some alone time" They attend to their own needs along with the needs of their pair. This can take a lot of personal courage and honesty sometimes, and requires an environment that encourages attending to yourself.
This guy sounds like he felt like he needed to put on a continuous show for his partner, and that was really hard for him. Which it is!
I bet he was right that he had to be constantly chained to the workstation. The "eight-week sprint" sounds like a pretty awful slog, especially with the set-in-stone up-front design. Overall, it sounded like a lousy, poorly managed setup.
Its too bad that he associated it with pair programming particularly, but oh well. There's many ways of working in the world, and it sounds like he's happier now.
Yours is the first description of pair programming that I have read that makes it sound reasonable. Your description is perhaps just common sense but it really needs to be said.
I've pair programmed quite sucessfuly for several years. However, it is a very hard practice. It requires trust between people, first and foremost. Besides that, it requires knowledge that you can't do it all day. It is too intense and tiresome, and this lack of slack is bad for creative thinking. About the pride: it is like co-foundind a startup, where you build something toguether with other people (it is all yours).
Whether what he did was or was not Official Pair Programming (tm) is beside the point. Obviously, some people will thrive having to interact with a partner all day, every day, while others will wither. Requiring all your developers to work in this style is just nuts. It's like requiring all your developers to wear size 31 jeans.
I don't think it is nuts if it is clear in your hiring process. Grockit has you pair for a day for your interview (or they did a few years ago) so you can experience what it is like, and see if you are a good fit. I agree that surprising people with pairing or trying to mandate it on an existing team is unwise, but building a company upon an ethos (to the exclusion of certain personality types) is a reasonable decision.
"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."
(emphasis mine). What an incredibly familiar description. Does anyone else ever feel this way? This is why in situations where I'm trying to describe a solution I end up just grabbing the keyboard, doing it myself, and letting the code talk for itself.
For me, pair programming comes easily when describing a solution that can be simply defined and understood. Doesn't matter how difficult the problem itself is. Pair programming becomes more difficult once you have to interrupt your coding to facilitate the process. As an introvert, this comes incredibly unnaturally to me.
Yes, that does sound familiar. I've never done pair programming, but I have the feeling I'd have a lot of the same problems as the OP. I'm very much an introvert, and even just our open-plan office sometimes has me wanting to shut myself away by the end of the day. And the more code I write, the less English I seem to speak, especially to describe code. I wind up either flailing my arms and speaking gibberish (only a mild exaggeration) or just giving up and writing pseudo-code because I just can't express the concept any other way. English just isn't precise enough.
Great article. I like to see people giving a detailed critical response about a practice which has increasingly become a kind of "Politically Correct" element in software development. Must always write units tests, for everything, and first -- hallelujah! Must pair program -- praise be thy name, thou art in heaven!
My own take: if it works well, do it. If it doesn't, do something else. Repeat. But your bottlenecks in the larger world tend to be talent, time and cash (though the latter is becoming less so in software development). If you have (enough of) those, use them and ship, get profitable, and anything procedural or paradigmatic should be far down your list of priorities.
Like most things advocated by XP people, pair programming is simply soul crushing and meant to replace skill and experience ("I know it's not the simplest thing that could possibly work but my experience tells me we'll be needing this later") with mindless repetition.
I hate pair programming. I find a lot of the times my partners are distracting me with a forgotten semicolon while I have already added that to my queue while my fingers are racing along.
On the other hand having to justify an idea to someone else (provided they are non-contentious, but really trying to analyze things) is worth its weight in gold.
In short. pair programming only works for me if I am surrounded by "yes men".
I got to the point where the other person started typing when it wasn't their turn.
First, pair programming has to be between near-equals, or it just doesn't work. If one person knows a lot more than the other, most of the time is spent in training.
Second, if the other person just starts typing, it isn't really pair programming. It's what we call 'peer programming' where you peer over someone's shoulder and they do all the work.
'Peer programming' happens a lot with mis-matched skill levels.
I didn't read the rest, but I assume it's all as much a bastardization of Pair Programming as the first bit.
PP didn't fail you. Your coworkers weren't using it.
> First, pair programming has to be between near-equals, or it just doesn't work.
That depends on what you think the goal of pair programming is.
> If one person knows a lot more than the other, most of the time is spent in training.
Which is part of the intended effect of pair programming. It forces everyone to share their knowledge with everyone else both about programming, and about the code base. This brings new people up to speed quicker, allows the more experience to better share their knowledge, and protects the company from having too much knowledge locked up in one individual.
To the GP's point though, they still weren't doing effective pairing for the 'training' or 'coaching' scenario. The pairing was contentious and out of balance. The coach didn't do any coaching.
> ...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.
In this case, a coach should engage the driver. Ask about what he's thinking and nudge him in the correct direction if needed. Coaching is a lot like driving school. The coach uses his brakes (keyboard) very seldom. If the coach is using his brakes very often, it is as likely as not that the coach is the problem (too scared, poor instruction, etc) and not the driver.
There are simple tricks. I usually put my keyboard behind the monitor. I've also turned my keyboard around so that I'm looking at the keys upside down. Those both take physical effort to get the keyboard in position to type. Another strategy that I've heard is oven mitts (I really want to try this one!) :)
Edit: Also, another strike against his coach (though this is more programming related..)
> 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.”
I'd agree with the OP here. Simplest thing is how you get tests to pass. DRYness is a property of code quality. They are orthogonal. Refactor mercilessly when you have green tests in order to keep quality high. Do the simplest thing when you have a red test in order to deliver features.
> Simplest thing is how you get tests to pass. DRYness is a property of code quality. They are orthogonal. Refactor mercilessly when you have green tests in order to keep quality high.
And once tests are passing, you should be able to convince your partner the code isn't dry simply by pointing out duplication, preferably 3 or 4 instances of it so you have enough examples to generalize a solution. You don't need tests to convince him something needs done.
As it should be; a weaker member is like a failed raid drive rebuilding until it's up to speed with the team. You expect things to go slower until he's up to speed. If speed is necessary, the senior programmer can always drive and let the other guy watch and ask questions, or explain as he goes along.
This seems like a common excuse I see to criticisms of pair programming. If this technique is so fragile, perhaps its just better to admit up front that it is delicate and easy to get wrong, and only works in particular situations with particular people.
My view is that pair-programming is a tool which only really works for stuff dealing with tactical decision making, logic/fact checking, teaching or debugging.
Higher level abstract stuff which involves creativity (design) or strategic decisions won't work because there is no process for these activities. You can't synchronize (communicate) where you are on your way to the "eureka" moment. Discussing with others certainly helps but there nothing pair-programming specific about it.
Also, don't forget that most, if not all, of the assumed benefits of pair-programming can be gained using a more flexible common sense approach:
Reducing defects?
Code-reviews.
Over engineering?
Design documents.
New hires? People switching projects?
Assign a mentor for a week or so and have them pair-program.
Faster debugging?
Understand that it is OK to ask a colleague for help.
I don't have any experience with Pair Programming as it is typically prescribed by "agile" project managers, but from my understanding of Pair Programming, I believe that there are more cases like this where Pair Programming doesn't work than there are cases where it does work.
I've also run into a fundamentally flawed hiring scheme at every company that uses Ruby on Rails in which I am flat out not considered if I do not have experience working on an "agile" team doing every day pair programming. There are a lot of job descriptions that back this issue up.
I learned Ruby on Rails on my own and have successfully developed and deployed two significant applications during my spare time using Ruby on Rails in the last 3 years. The applications I've written are not open source and they are not public access sites, and until I do get something written within the public facing / open source realm, I am convinced that I probably won't ever get considered for a full time rails job.
I've mostly just about given up on ever expecting to get hired by a company that uses Ruby on Rails. It is all total bullshit in my opinion. I will continue to use Ruby on Rails on my own and ignore Pair Programming because I see Pair Programming as a form of micromanagement and not an opportunity for programming productivity.
I have plenty of experience working with other software developers on the same piece of code, in front of the same terminal window, for two or three hours at a time - always initiated by myself or the other developer, not prescribed by management. The fact that I don't do it every day is irrelevant in my opinion.
"I've also run into a fundamentally flawed hiring scheme at every company that uses Ruby on Rails in which I am flat out not considered if I do not have experience working on an "agile" team doing every day pair programming."
This sounds like sample error. It is true that RoR culture overlaps with pair programming/XP culture and agile culture, but there are VERY MANY RoR places that do not pair every day.
His experiences with pair programming parallel my own. I had to quit an otherwise fun job, that paid really well, because I simply could not stand being that close to other people for that much of the day.
After a few months of pair programming, I can only agree. At points, when my partner saw a better way of doing things, it was insightful. In the end, however, we found that it was more efficient to split up the work, merging code when necessary.
I generally like pair programming in some cases, and dislike it in others.
You have to combine it with TDD or else each person focuses on something different, and basically reverts to being a spelling mistake checker until it is their turn.
I have only enjoyed it when doing mostly new development, in a modern language with modern tools, combined with a strict red green refactor process, where one person writes the test , and the next makes it pass and writes the next test.
For more exploratory stuff, or doing it without TDD, or using old crappy languages and tools, or doing maintenance, it just sucks and I prefer to work alone.
In my place, I sort of enforce pair-programming for about 2 weeks before a deadline. Basically at crunch time.
I basically believe that crunch time increases the probability of errors by orders of magnitude. Secondly, as the author mentions, that is the time when gaps in knowledge need to bridged over... at the expense of personal ego if need be.
> In my place, I sort of enforce pair-programming for about 2 weeks before a deadline. Basically at crunch time.
I basically believe that crunch time increases the probability of errors by orders of magnitude.
Code reviews will give you the same benefits without the soul crushing drawbacks described in the article.
I did code reviews at Google for four years and it never felt like a burden, more like a part of my job that feels gratifying and useful. I also loved knowing that every single line of code I wrote was going to be reviewed.
Pair programming is not used at all at Google, mostly for all the bad reasons cited in the article. And also because code reviews really do work (admittedly, Google has a fantastic infrastructure to support it).
I think the author is conflating Pair Programming with other concepts.
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. ...
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. ...
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. ...
What on earth does any of that have to do with Pair Programming?
> What on earth does any of that have to do with Pair Programming?
I'm the OP.
What I'm describing is my experience Pair Programming in one organization, and why it didn't work for me. To tell the story, I needed to provide the context and the background to say why it didn't work for me. They're distinct issues, but the only way we could relate to those issues and work through them was through the lens of pair programming.
Keep in mind that I'm not trying to say that Pair Programming is a flawed practice in principle, or even that their approach was flawed _in practice_ for the company -- there are other metrics besides code quality that a startup needs to consider if it's going to survive, and sometimes "good enough" code is good enough.
I'm well aware that pair programming works very well for some people, and that my experience may not be typical. However, just because my experience wasn't typical doesn't mean it didn't happen.
I've had good experiences with pair programming. This does not sound like my experiences and I feel for the writer. It sounds like a horrible situation to have lived through.
The best pair programmers I've worked with will often do things like: say "let's take a walk" and then talk through design problems, get up and use a whiteboard, say "I want to read about this. Let's get back together in half an hour." Or even say, "I need some alone time" They attend to their own needs along with the needs of their pair. This can take a lot of personal courage and honesty sometimes, and requires an environment that encourages attending to yourself.
This guy sounds like he felt like he needed to put on a continuous show for his partner, and that was really hard for him. Which it is!
I bet he was right that he had to be constantly chained to the workstation. The "eight-week sprint" sounds like a pretty awful slog, especially with the set-in-stone up-front design. Overall, it sounded like a lousy, poorly managed setup.
Its too bad that he associated it with pair programming particularly, but oh well. There's many ways of working in the world, and it sounds like he's happier now.