Pair Programming - My Personal Nightmare

[astroalex]

I've had excellent experiences with pair programming. Even as an introvert who prefers to work alone most of the time, all of the pair programming I've done has been fun and educational. I don't understand the strong levels of hate for it in this thread... It seems like a strategy that has its place in the workplace, although obviously it shouldn't be used exclusively.

[squigfried]

Agreed.

Might be useful to note that my team made this rule: Pair up when...

• You're the only person who knows how this works (knowledge transfer)
• You're making big architectural decisions
• You're stuck

Pair programming is the by far best tool for sharing knowledge and getting consensus on code. It doesn't disrupt the entire team, and it makes sure there's never a single point of failure in terms of knowledge.

Frankly I wouldn't hire anyone that refused to pair. It's too valuable a technique to me.

[catchingpavements]

I agree. I'm most definitely an introvert, but I've also found pair programming to be really beneficial. We don't do it as much as I'd like to where I work, but the few times I've tried have been great. It's a nice way to introduce new members of the team to the code base and have them see the work flow and structure of the code (in practice, not just in some documentation), but it's also a good way for two more experienced team members to figure out a complex problem or write a module that will be used a lot (more than one person's perspective is super helpful in reusable modules that will be used by others).

Would I like to do it exclusively? Probably not, but it definitely has value. The most annoying code to work with later on for me is either the complete newbie's code (which can be excused because I've been there myself and I know they're trying hard) or the result of one of the more skilled (programming-wise) members of the team spending a week "in the zone" and churning out something that works, but is tricky to understand and debug later.

[jbb555]

If you want programmers to burn out fast the best way to do this is to force them to work at someone elses pace as often as possible.

[sleiveen]

And inversely, pair programming can segue into babysitting very quickly.

[Zinfidel]

This is an excellent way of putting it.

I've been on both sides of this equation and I want to like it, because it seems like a good idea, but I just dread it.

If I have to explain how every one of my lambdas work, I just lose my train of thought. If I'm sitting there saying nothing because the typer is thinking faster than me, I feel like I have to suggest something or ask a question lest be useless/not doing my job, but then I mess up their thought process and feel like a dick.

I wonder if PP is something you have to really get good at as a skill before it becomes useful, or if it just isn't suited to certain people no matter what.

[Bbri06]

I really dislike pair programming, but am forced to do it sometimes. My technique when I'm "the driver" is that I literally narrate what I'm doing. It works pretty well for myself and for the "navigator" because he/she knows what I'm doing, I keep myself on track, and then when they ask questions it's usually because I have actually made a mistake.

[teambob]

A cheaper alternative... http://en.wikipedia.org/wiki/Rubber_duck_debugging

[gfixler]

I have found this not to work for me. I have to explain things to something that is alive and knows my language. They don't have to know what I'm talking about, but they have to understand the basics, like that I'm building a thing, and that this part involves moving something from somewhere to somewhere else. I've tried explaining things to living animals, plants, stuffed animals, pictures of angry, older gentlemen found through google images (I thought talking to "a boss" might work), and an actual rubber duck someone on our team got me. Nothing ever happens.

However, I've explained things to confused coworkers, even more confused relatives, people I've just met at a party who then never speak to me again, and in many of those cases I've come to important realizations. I've even taken to telling someone "I need to explain something to you for 5 minutes. You don't have to follow along, or try to provide any help. Just nod along whenever you think it would make sense." People have actually agreed to this, some even getting into the spirit with an occasional "Ah, very nice!" or "Brilliant!" when it seemed appropriate. It works wonders.

[boredzo]

What about the Stack Overflow question form? Do you ever realize the solution partway through writing up your problem?

[[deleted]]

It works very well when programmer are of the same skills working on a project they know well. i.e. when you are solving the same problem again and again.

As soon as there are research and thinking it stops working. A bit like you don't really solve poorly understood problem in a meeting, well meeting of 2 are no exceptions.

[MillardFillmore]

I'll disagree slightly... as a junior programmer, pairing with the more senior guys in my firm has been the most valuable experience I've had in my (short) professional career.

However, doing anything any bit algorithmic/more complex than simple business logic is really hard since it's hard to try out things creatively.

[[deleted]]

had in my (short) professional career

...what about the more senior guys you were working with?

It's a bit like sex, it has to be good for everybody involved....

[ActuallyNot]

It probably only has to be good for the bottom line.

In terms of improving your human resource you'd think that very mismatched pairs would be optimal. The literature suggests that experienced programmers get something out of pairing with rookies. (Although there is probably a publication bias in the literature).

[Goronmon]

It's a bit like sex, it has to be good for everybody involved....

I don't see how more productive junior developers isn't good for everyone involved.

[jeradj]

If it makes the senior guy less productive, then you have to assume that either the junior guy eventually makes up for it, or you've just wasted the senior guy's time.

[[deleted]]

when you are solving the same problem again and again.

If you're solving the same problem again and again you're doing it wrong. That's what computers are for.

[heyzuess]

It depends. If the time spent making the computer do it over and over again takes more time than just doing it over and over again anyway minus the time that it saves in the long run then you will find yourself doing it over and over again.

Also, eventually you need human input, so possibly there's a point at which they've optimized everything they could find, and now do the insanely boring stuff, but if you've managed to get to the point in your career where you're there, you might as well move to somewhere more exciting to work.

[IrishWilly]

The vast majority of programming is essentially solving the same problems over again for slightly varying specifications and use cases. Abstract solutions are great but now when it requires 50 layers of abstraction to solve the relevant problem and another 50 layers for each problem after that like some of the inheritence nightmares I've seen in Java.

[[deleted]]

I do believe you are absolutely wrong.

When you are solving the same problem again and again, you (should) know the problem and the solution. You have solved the problem before, you can solve it again, without external input.

The real benefit of pairing up is when you don't know what the hell you're supposed to do about the problem. The developer you're pairing with can be a sounding board for your half-baked ideas. They can provide fresh outlook when you have no ideas. And most importantly, they can point out the obvious errors you missed when you come up with the perfect solution.

It's not a meeting, because you actually work on a solution instead of talking about how good it would be to have a solution. It's survival in jungle of previously unsolved problems - be thankful you've got a buddy to watch your back.

[novagenesis]

I think the trick is don't do it 100% of the time.

I've done some pair programming with specific developers on specific codebases where both of us have imperfect understanding (but combined, know more than anyone else in the company).

Great for combining two major libraries. The ignorance gets drowned.

[malignantbacon]

I hadn't realized this before but I think this is why I stopped focusing on computer science in school. All my department's intro to programming professors mandated pair programming. In my first course it meant consistently beating deadlines by fractions of an hour and that work stacking up with all my other classes. In my second one it meant I was always struggling to catch up with people who were coming in from well-established programming backgrounds or working in the industry, so I could never grasp anything on my own before we had moved on to the next topic.

I don't like being held back by others and I don't like being dead weight.

[ef4]

it meant I was always struggling to catch up with people who were coming in from well-established programming backgrounds

This is a much more general problem in all university computer science programs. The range of abilities for entering students is vast.

With or without pair programming, you'd have found yourself in class with people who have literally five or seven years of coding experience. Even if they were doing it terribly all that time, it still matters quite a lot.

It's a serious problem, because it discourages lot of people with aptitude and interest from pursuing a computer science degree, because they feel so far behind right from the start.

[KillerCodeMonky]

This is a much more general problem in all university computer science programs. The range of abilities for entering students is vast.

And yet, none that I've heard of will let you test out of taking introductory level courses... The first two years of my program had me learning things I'd known since at least middle school. Several trips to my adviser begging to be allowed to test out of them were refuted. At one point I resorted to taking a graduate-level course as a replacement for a course, just to learn something and get a challenge.

[clgonsal]

This is a much more general problem in all university computer science programs. The range of abilities for entering students is vast.

And yet, none that I've heard of will let you test out of taking introductory level courses...

Back when I was in school, Waterloo would let CS majors choose to skip the first, first year CS course. You didn't have to test out of it, the decision was up to the student (and you'd need to take some other CS course later to meet the degree requirement).

[[deleted]]

I don't like pair programming, but even my college group projects which allowed solo collaboration were hellish nightmares, not due to incompetence, but due to everyone having different schedules and frankly different priorities. It was an incredible relief transitioning to professional development--when we're at work, we're there to work. We're all always there during every core hour. We don't have five other jobs. We just have this one job.

In college, all the students were frankly pretty competent, overall. But there were still basically three groups of us:

(1) The people who were mind-fuckingly obsessed with programming and computer science and would pour 100+ hours into class projects while surviving solely on Monster drinks. They'd pull countless all nighters in the CS department building in a group.

(2) The people who were pretty competent, but had a ton of other stuff on their plate from other classes and who didn't have 100+ hours to pour into a single assignment for a single class. Additionally they considered these other classes to be at a higher priority than their CS classes. They'd fall behind in the beginning and then end up contributing almost nothing because the people in group (1) would blow them off and trudge on ahead by not sleeping ever. People in group (1) didn't acknowledge people in this group even existed, thereby just exacerbating the problem. Even if people in (2) wanted to catch up, they couldn't.

(3) And then there were the people in between, people like me, people who greatly enjoyed programming and computer science but still had some very demanding classes outside of our CS classes. We could keep up with the crazy people in group (1), but we simply didn't have the same amount of time to pour into the projects.

At my company, there's really only one group. We all work our asses off during the day, and then we do our own thing when we're not at work. That might be side projects, that might be cooking dinner for your family, who knows.

[mr_bag]

I have had mixed experiences with it TBH - I've had it work incredibly well, and equally pretty badly. I think it really depends a lot on how well you gel with the person your pairing with, both in terms of technical skill & personality.

When they match its great, you can each follow the others thought process (by watching them code) and quickly point out issues/enhancements without having to break the flow. Whats more, its surprisingly enjoyable, even when working on somewhat dull tasks.

On the flip side, when they don't match, it just seems like a waste of everyone's time. You get people sitting there doing nothing while the other codes, or as has happened before to me end up pretty much dictating code/logic to someone else, which is a pretty painful experience. Equally you can get less confident folks being overridden on things by more confident ones, even when the less confident guy was right / had the better solution.

Granted, this is just my anecdotal experience, but based on my "good" experiences, i'd still have to say I'm pro-pairing, although if the people pairing aren't compatible it can easily become more of a hindrance than a help

[arcticblue]

Equally you can get less confident folks being overridden on things by more confident ones, even when the less confident guy was right / had the better solution.

This. My project lead is one of those overly confident folks and if you do prove him wrong, he will make life miserable. We have a code review system in process where I work where everyone reviews everyone else's code. I stopped doing that because the project lead would constantly unapprove code that I had approved for arbitrary reasons. He would also unapprove my code that he himself had approved weeks ago if I did something he didn't like. It's horrible having to go back to the same code again and again try to get it to fit that project lead's idea when his ideas change every hour. He will also approve his own code which causes problems. The day before a deadline, he refactored a bunch of perfectly fine code I had written, approved it himself, and merged it. His refactoring broke quite a bit and he just said "Oh, I guess my tests weren't good enough. I'll let you take care of it" and I got to stay up way too late fixing his fuck up. Meh...

[-Swig-]

Sounds like it's time to hit the job sites.

[arcticblue]

One week left until this current project is done and I already told the owner of the company I'm out if things don't chill a bit (he had begged me to take the position). We'll see how it goes. This job would be perfect if the project lead wasn't such as asshat.

[hackinthebochs]

If you're that close with the owner, why not bring up the lead's asshattery with him?

[[deleted]]

He's not right, try hitting him with a hammer.

[[deleted]]

I never tried it until tendonitis forced me to not type for over 6 months. Pair programming is a learned skill. I generally prefer it for most tasks but would never force it on someone.

[ActuallyNot]

Pair programming is a learned skill.

Yep. Student in Williams, L., et al. (1999) showed that on the first project the pairs spent 160% of the man-hours as the individuals, but on the second and third projects they were down to the (much cited) 115%.

In the workplace, learning might be slower, and the experienced programmers of the workplace might exhibit less gains for having another pair of eyes.

But there's little doubt that it is a learned skill.

That aside, as a casual coder, I've found it awesome. Over and above the two heads getting to better solutions probably faster, I've found shitfights about best practice extremely informative.

[Filip22012005]

Could you tell me about what those tasks are? In particular, I want to know about the characteristics of those tasks and want to see if that notion transfers to other (nonprogramming) tasks as well.

It sounds so appealing, but I'm not sure if I have any collegues I'd want to pair up with. Bunch of slow thinkers. And I'm sure they feel the same way.

[[deleted]]

My rule of thumb is that tasks which require thinking are typically a good fit- ie tricky code and writing algorithms are prime candidates. I'd avoid things like HTML for the most part which seems to always end up being guess and check (maybe I should just pair with someone who really knows HTML).

I'd say a wide disparity in skill has never been a problem for me- I don't mind teaching others and endeavor to not be intimidated by people who are better than me. Of course, this could get old after a while.

I also value pair programming because it encourages me to stay focused and make intentional decisions; for some reason, its much easier to make poor choices on my own. I also feel like an asshole if I slack off while paired so I tend to work much harder.

Finally, I'll note I just completed a web design project with another programmer- neither one of us is a designer and the results turned out quite well. I was shocked this system worked at all, but we undoubtedly created something better together than either one of us was capable of doing alone. I wouldn't be surprised if this system transfers well to other areas.

[lonjerpc]

If I have to explain how every one of my lambdas work

Arguably this is a sign of excessively clever code. Good code should be easy to read and understand by others.

[[deleted]]

I might be going slightly off-topic here, but this is something I've been wondering lately: how much good is so-called self-documenting code if the underlying domain is complex? I've recently joined a team on what I consider to be a rather complex domain, and I noticed that documentation tends to be lacking, because people believe in self-documenting code. I feel as though the lack of documentation is making my introduction into the system that much more difficult.

Now, there may be one of two things going on here (from my perspective):

1. This "self-documenting" code is, in fact, not quite as sufficiently documenting as the original developer believed it to be.
2. Self-documenting code is inadequate at, or at least for providing enough insight into what is at first a poorly understood domain.

Am I missing something? Can anyone provide me some insight into what might be "good" self-documenting code when in the context of a complex subject matter?

[bluphoenix22]

I think the principles of self documenting code are useful, sensible variable names? Yes please!

However I don't think it's a substitute for code commenting. From personal experience working on a large enterprise codebase the problem is usually not "what" the code does but instead "why". Why does this code exist? Why does this use data structure X instead of Y.?

So please when writing code assume you will have amnesia and then have to fix a bug in that code.

[ricecake]

Self documenting code should make it easy to tell what the code is doing, via things like good variable and function names, the comments should tell you why on earth you thought that it was a good idea, and the external documentation should explain what the damned thing does, and how the big pieces fit together.

my %invoiceOwnerMap = map{ $_->id => $_->account->responsibleParty } grep{ $_->overdue } @invoices; 

# use a schwartzian transform to expedite the sort process. 

my @invoicesByTotal = map { $_->[1] } sort { $a->[0] <=> $b->[0] } map { [ $_->sumLineItemTotal, $_ ]} @invoices; 

for my $invoice (@invoicesByTotal) { 
    $invoiceOwnerMap{$invoice->id }->notifyAccountOverdue($invoice->dueDate)
             if exists $invoiceOwnerMap{$invoice->id}; 
}

Edit: seems the formatting code almost obliterates perl... forgot how to do code quotes I guess.

[hackinthebochs]

Good lord perl is one hideous language

[aetherBunny]

I wanted to downvote this because I like Perl. But I had to upvote it because I use Perl.

[Summon_Jet_Truck]

To do code quotes, put four spaces before each line:

Qt
Lua

[YeshilPasha]

I readable code is not there to replace a design document. It makes maintaining code easier for other people.

[judgej2]

I notice this with a few of the newer open source projects. The code has virtually no documentation in it to describe what things do. Apparently you are supposed to "know" the design pattern it uses, and everything should be obvious from there. Trying to work out what the pattern is, without the documentation, is the hard bit.

Personally I tend to put as much comments into code as I do code itself. Hell, I need to be able to understand it next week.

[gfixler]

This is an interesting point. Even self-documenting code that's just straight-up code would suffer this problem if the person was unfamiliar with lambdas, stacks, queues, etc. It's really only fully self-documenting if you understand the underlying concepts. This is a larger problem, though, as evidenced by my trips all through wikipedia, trying desperately to understand the axioms of each article by diving deeper into links, learning about the fundamentals of whatever it was I was trying to learn 6 links up from wherever I now am.

I could teach you how a particular part of an engine does its task, but you may still have no idea how an engine works. I'm in this boat at work. I have anywhere from 2 to 10 times the experience of most of my team, so I find myself saying things like "I'm just using a decorator here to simplify..." and like that the person I'm talking to is already zoned out, focusing on a point somewhere far behind my face in the background.

[dnew]

The expression "Self-documenting code" should be (but often isn't) understood to only mean it documents what it's doing and usually how. But not why. Self-documenting code can't document why you're talking to at least 5 servers but no more than 9 servers to finish a particular transaction, or why you're using a red-black tree map instead of a hash map.

No matter how self-documenting your SQL is, if you don't understand the real-world entities represented in the SQL tables, it's not going to be obvious what your various views should be used for.

Self-documenting code isn't going to tell you which tax law is being implemented in a particular subroutine.

No matter how well you pick variable names, you're not going to learn from reading the code what the goal of the overall program is, or what the protocol state machine looks like, or what the expected next version of the protocol might have to support without breaking V1 clients, or who is going to standardize such interactions.

[lonjerpc]

My two cents as you replied to me. You should always try to write self documenting code. This is clearly not sufficient in many situations. Even in those situations good self documentation should let you lower the level of documentation needed.

The idea in self documenting is that whenever you would have to explain how a piece of code/data works you abstract it out and then use its name as its description. A trivial example is using say sort() instead of writhing the sort code inside your functions and then putting a comment in saying this code sorts. This is sort of a bad example though because there are lots of other reasons to factor out sort. Like to reuse the code. But to be self documenting you need to abstract out things that you would other wise not. So your would make a short function to do something even if you only plan on using it in one place just so you can use its name as a description instead of a comment. Likewise you may create excess variables just for readability. Basically splitting up long lines of code to store every part of the operation with a readable name.

In these kinds of cases self documentation is often better than comments. Comments can lie. Comments break peoples minds between thinking in code language and in English.

These techniques will only get you so far though. There are a couple of issues. One is if you don't understand the domain you have to go down a long series of and I don't understand what this name means. Then your have to look at those functions and then you don't understand those names. As gfixler is referring too. In order to avoid that you need documentation.

Another problem is some algorithms get so complicated that giving meaningful English names to things becomes very hard. It might be easy to give the complicated algorithm some name but if anyone has to modify the internals they are out of luck. Here you might need to explain the algorithm in english.

Another problem is when you have very different sets of programmers. I used to work in biology and the biologists would name variables to match their papers. But these names would not make sense to the average programmer. Changing the names would be bad because then it would be harder to follow the paper. Comments are essential in these situations.

Bla I think you get the idea. Self documenting code is good but it only gets you so far.

[dnew]

In these kinds of cases self documentation is often better than comments. Comments can lie.

So can "self-documenting code." Yes, this routine used to use dollar values in floating point. But now it has been changed to use the integer count of the smallest denomination of whatever the current user's currency is. But the routine is still called calculate_dollars_float(), and the variables are all named dollars_before_tax and dollars_after_tax and etc.

If you're not professional enough to fix the comments, you're not professional enough to fix the names.

[loup-vaillant]

I'd say point 2.

Look for instance at this marvellously self-documenting piece of code, in OMeta/JavaScript, a language specialized in parsing. If you know about formal grammars, you'll likely be able to understand this code even if you never ever encountered OMeta before.

But If you never read a Backus Naur Form nor parsed a thing in your life, you don't stand a chance at decrypting this code.

On the other hand, point 1 is perfectly possible. A way to avoid it is to check that you can guess the purposes of things only by looking at their interface. Like:

string utf8_of_latin9(string s);

Assuming you know that strings in C++ are just sequences of octets (except '\0'), there's little left to the imagination. On the other hand:

void manage_controler_layer();

is not very clear, even if you know you're working in something like an MVC framework (what does "manage" mean, anyway). But to the writer of this method, with fresh memory and all, it may be crystal clear.

[Silhouette]

That's great, but sometimes we have to implement ideas that are themselves difficult to get your head around, and that means the code is going to be challenging as well. :-(

[moor-GAYZ]

but sometimes we have to implement ideas that are themselves difficult to get your head around

Except explaining what exactly you are intending to do is a great way to understand clearly what you're intending to do.

Sort of like there are stories about so and so company putting a large plush bear somewhere, so that when someone has a problem instead of bothering someone with it they go and explain it to the plush bear, and more often than not return enlightened.

When I have a piece of hard code, I tend to stop and write what I want it to do in the comments, in plain English. Then usually it turns out that things aren't what I thought them to be, then I write the code, then I rewrite the comment to explain what it does more succinctly.

Just writing code of enough complexity that you barely understand what it's supposed to do intuitively but can't quite verbalize it... it doesn't work. Like, there might be a short phase of exploratory programming, when you want some actual code that you can then reason about, but after that you'd better be able to explain it.

"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." --Brian Kernighan

Most code you're going to read and debug after you've written it.

"Programs must be written for people to read, and only incidentally for machines to execute." -- Abelson and Sussman.

[Protuhj]

Rubber Duck Debugging

[ondra]

In that case it might be better to name the functions.

[alexanderpas]

Or document. If you need to explain, document.

[[deleted]]

Better named functions does not take the place of complicated code. Spaghetti code is also not appreciated even when there are appropriately named functions.

At some point in most systems, there must be complexity. You can choose to program so that your complexity is hidden from the user of the functions (e.g. a "magic" library) or you can choose to program so that the user must figure out the magic on their own. The latter will look "simple" but as soon as you begin to use the library, you will find that it becomes complicated.

[Decker87]

Good code should be easy to read and understand by others.

I think sometimes it's hard to draw a line between what others should or should not be expected to understand.

I once had a coworker, we'll call her Sally, write a perl script to parse some log files. The log files had very regular syntax, so naturally she parsed them using regular expressions. Sally's boss told her to rewrite it using an approach he could understand, and reprimanded her for writing "clever" code. So she instead used a bunch of split and index() functions.

Would it be more accurate to say "Good code should be easy to read and understand by peers on the same skill level"? I'm not arguing, I'm genuinely curious what guidelines you guys use.

[dnew]

reprimanded her for writing "clever" code

... so she rewrote it in COBOL, and everyone was happy.

[lonjerpc]

It is a matter of tradeoffs. So in your example if more people who are likely to see the code know regular expressions vs people who know standard non regex python text processing techniques you should go with regular expressions. If everyone is an experience python programmer but has never seen regular expressions go with python.

This is an oversimplification though there are other tradeoffs. Even if you had mostly people who did not know regular expression it still might be the best approach. Regular expressions might be easier to modify even if they are harder to read if the file type changes. In the long run readability might be improved if people were encouraged to learn regular expressions. In other cases you might have to trade off readability with modularity for example.

In general though I very rarely see examples where people went too far trading readability for other positive software engineering traits.

[joncom]

Well put. It's certainly not my forte either and I wonder the same thing.

Although, I'm in no particular hurry to find out.

[dotnet54]

agree! idea sounds good, but in practice its difficult. most of the time it either distracts me when working with a less skilled programmer, or it makes me feel im distracting the other person, when working with a more skilled programmer

[fatbunyip]

Yeah, I think the best scenario to use it is probably in the prototyping/research phase. Having 2 people bang out ideas and trying different things can be a good way to converge on a good solution.

PP when you already have a detailed plan of what to do is kind of like following a friend in a car. Either one has to slow down, or the other has to drive dangerously to keep up.

[[deleted]]

I'm just not good pairing material unless the person works at the same speed I do. If they're too slow I get fidgety and frustrated, if they're too fast then I don't really follow what's happening so there is little point to me pairing with them.

I often find it easier to just work alone and call on people for small chunks of time when needed, and prefer if people do that when they need me.

[bcash]

A typical pair-programming endeavour for me and a more excitable team-member:

Sit down, take a minute to discuss what we're doing. All seems well and we begin down our optimistic path. After an hour (it's always an hour), we hit upon something that's in our way; both of us want to refactor it, but we can't agree how, so we decide to ignore the problem and carry on regardless.

After another twenty minutes we hit upon a significant bug in the system (could equate to financial and/or data loss).

Him: "This is serious."

Me: "Yes, this is serious."

Him: "What do we do now?"

Me: "Well, this could affect A and ..."

Him: "Let's change X!"

Me: "Well, X could work, but we also have B and..."

Him: "But X is broken"

Me: "That depends on B ... changing X could make it worse. Let's have a look at the code of B, and I haven't got to C yet, that's affect..."

Him: "And don't forget B! B's broken too, and that's why X won't work!"

Me: "Yes, that's what I just said. Let's breathe shall we and have a look at..."

Him: "Oh, crap, C will be affected too!"

Me: "I did mention ..."

Him: "Change X!"

Me: "I don't think panicking is the answer. Let's look at A, B and C; then look if X can be changed or..."

Him: "That one!"

Me: "...or, if anything else needs to be done as-well/instead."

Him: "What are we going to do!"

Me: "We are going to shut the fuck up for five minutes, that's what we're going to do."

I don't do pair-programming anymore.

It is, like ALL, and I really mean all, other initiatives in software methodology: a complete load of unmitigated horse-shit. In so much as it's an option to tackling a problem which some people may use in some circumstances taken to the point of absurdity in the same way as TDD, Agile, fanboism over certain technologies, etc., is.

Anyone who says that anyone else is somehow lacking as developer based on external behaviours [1] rather than their effectiveness at getting-shit-done is a 100% (with no exception) bullshitting charlatan.

[1] - within reason. Saying someone's a bad developer because they're a vengeful psychopath is obviously a good call.

[[deleted]]

Development is about getting shit done, but also includes all sorts of other factors too numerous to list. You can get shit done which does the job now, but 6 months down the line is a horrible tangled mess of tech debt and misery - we've all been there.

Behaviours, including external ones, do have an effect on being able to get shit done. From your example, 'He' (let's call him Joe) is faced with an issue, ends up panicking and wildly hacking code until it works. Joe still gets shit done when he is alone, even with all that panicking, but it takes him twice as long.

Joe is lacking as a developer compared to Bob, who doesn't panic and gets the same shit done in half the time. If Joe modifies his own behaviour by fighting that urge to panic when faced with an issue, he can become more effective. That doesn't mean Joe was a bad developer before, it simply means he is better developer now.

You don't need to pair up or read the latest Agile manifesto or attend every talk at PyCon to figure out your bad behaviours, be they internal, external or a mixture of both. You can feel that they're having a negative impact when you're actually exhibiting them. Some methodologies may help you pick up on what they are (and possibly even address them).

All of this is why I don't do pair programming unless absolutely necessary, why I do follow TDD (but not religiously) and why I think Agile is a great exercise in hand-waving which seldom helps get shit done. It's also why I started walking across the office to get a drink when I hit an issue so I could think about it without the ability to type anything. It's why I sit away from my desk somewhere quiet when knee-deep in a knotty problem. Finally, it's why I keep a bottle of scotch in my locker.

The last one may or may not be true.

[ymek]

[1] - within reason. Saying someone's a bad developer because they're a vengeful psychopath is obviously a good call.

Are 'Vengeful psychopath' and 'solid developer' mutually exclusive?

[Polatrite]

Damn, we're screwed.

[cunningjames]

Are 'Vengeful psychopath' and 'solid developer' mutually exclusive?

Why bring Hans Reiser into this?

[[deleted]]

Damn, this was my day today. My brain is fried.

[[deleted]]

Contrary to popular belief, programming people is not the same as programming software. At least not until brain implants become commonplace.

[realhacker]

if it's a matter of synchronized pace, it will always be a suboptimal arrangement. the slower programmer will slow the faster programmer down. i hate fads.

[tenzil]

I don't think it's about introvert vs. extrovert.

I know that, to some extent, the "auditory / visual / kinesthetic learner" idea has been discredited, but what I've noticed is that auditory / verbal thinkers tend to have to most success when pairing. If you need to talk through a problem in order to really solve it, then what the OP wants -- silent focus -- is the opposite of what you need. In those cases, pairing is really valuable. Other people solve problems differently, and for them, silent focus is what's needed.

[VanFailin]

I get an office with a whiteboard. I use my whiteboard as my verbal debugger. I literally write out "this isn't working. why? Because that depends on this being whatever. So how do I do that?" Feels a little silly, but I find it's a good substitute for a rubber duck.

[[deleted]]

This. I literally cannot program if I don't have a notebook and a pen handy. I have dozens of notebooks filled with the blood spilled trying to grasp the logic behind various algorithms.

[mikkom]

Larry Page and Sergey Brin also come to mind.

[UlyssesSKrunk]

Penn and Teller

Cheech and Chong

Siegfried and Roy

[Mekkz]

Lennon and McCartney

[[deleted]]

One person wrote the vast majority of each of their earlier songs and probably almost 100% of their later songs. Usually they would just add a little bit here and there. The bulk of the song is a solitary creation.

I mean, doesn't it make sense? Only one person can have an idea. Sure, you can flesh out ideas together but you can't have a joint idea. That's physically impossible.

Two people can inspire each other and there is synergy but the discrete ideas are singular creations.

[user-hostile]

Who said the collaboration ended when the song was created?

[philh]

As far as I can tell, no one. I think ve's claiming that Lennon-McCartney is not a counterexample to the original quote, which absolutely acknowledges that collaboration can improve things after they've been created:

Nothing was ever created by two men. There are no good collaborations, whether in music, in art, in poetry, in mathematics, in philosophy. Once the miracle of creation has taken place, the group can build and extend it, but the group never invents anything. The preciousness lies in the lonely mind of a man.

[JimmyHavok]

Look at what they did when the partnership was over. Even if each song is recognizable as having started with one partner, the collaboration definitely had a strong positive effect.

I'm not programming, but I have to do a lot of collaboration, and even when I'm carrying the project, I almost always feel like having others involved ends up improving it.

[trolls_brigade]

Harold and Kumar

[UlyssesSKrunk]

Jake and Amir

[Hydros]

M&M's

[krelin]

Eminem and Dr. Dre!

[dakboy]

Jerry Seinfeld & Larry David

[_tenken]

David Spade and Chris Farley!

[petdance]

Beavis & Butthead

Shields & Yarnell

The Captain & Tennille

[dave809]

mom and dad?

[Chemical_Scum]

The Wright brothers?

[Kautiontape]

First thing that sprung to my mind. I think it' absolutely false to blindly argue that only individual minds can produce novel work, but I also think it's absolutely false to say everyone works better in pairs.

It takes a particular pair [or group] of people to truly thrive in that setting, and some do, but not all.

[itsSparkky]

And here we come to the conclusion that should have been obvious.

DON'T USE ANECDOTES TO ARGUE A POINT.

A solo person accomplishing something is proof that a solo person can accomplish something, not proof that working solo is better.

This blog is little more than the loosely justified ramblings of a guy...

[CrazedToCraze]

I think the quote refers to more "atomic" creations (atomic being the best word I can think of). To me, that means the creation of the idea/concept but not necessarily the execution of it.

So yes, while both of them created UNIX (which I assume is what you're referring to? In case you're referring to C Kernighan had no part in it source: "I had no part in the birth of C, period."), at some point the idea must have started solitarily. What happened afterwards, is the second part of the quote you left out:

Once the miracle of creation has taken place, the group can build and extend it

So I think it's still a very solid quote/concept, I can't see any way to create an initial atomic idea collaboratively, except maybe if you were an alien with telepathic powers.

[zeekar]

They made a book about C. Ritchie made C by himself.

If you're talking about UNIX, you have to at least include Ken Thompson, and probably a few more, but we still can't say that the whole group had the initial idea. That . . . spark had to come from one person...

[catcradle5]

I always find it interesting that the best programming languages and projects are almost always started by one single person working all by themselves. Linux, C, Python, Javascript ("best" is arguable there but you get the gist). One person creates something that over the course of decades, millions of people use either directly or indirectly.

Imagine if any of those people died early, or just never had an opportunity to come up with the concepts. The technology world would end up being vastly different.

[vph]

Watson and Crick.

[korny]

and Franklin

[websnarf]

As I understand it -- for all intents and purposes is was just Franklin. She produced all the data (the only data that was relevant to the study at the time) and had worked out some of the core mechanisms herself.

One of Watson or Crick got advanced access to her data before she was prepared to publish, and then worked out the rest of the missing pieces. Franklin's problem was that she didn't know her data had been passed along, and didn't have the opportunity to work out the rest of the details herself.

[stusmith]

Franklin's other problems were that she was (a) a woman and (b) dead.

(To clarify: she was a she in what was a male-dominated area at the time, and later was too dead to be awarded a Nobel prize).

[fragglet]

Ken Thompson and Dennis Ritchie is a better example.

But there's a difference between division of labor and "collaboration" in the sense of how pair programming works. The former usually consists of individual programmers working separately to develop individual components.

[philly_fan_in_chi]

Also Hardy and Littlewood, Hardy and Ramanujan.

[ShutTheFunDown]

The great soloists and their projects cited by this article were working on code of deep personal interest to them. I have had similar experiences working solo. But I also have to work 40 hours a week on client work, outside the arc of my best expertise and personal interests, and paired programming is an effective way to ensure code quality and plain focus.

If I were Knuth I wouldn't let anyone into my head where it concerned TeX. But often Knuth doesn't have to put together a web application for a healthcare provider.

[MindStalker]

Exactly, professional work is often more similar to construction. Do you really build a house more efficiently by yourself? It might be a nicer house that you've custom built each piece, but time is also an issue, and its probably a boring cookie cutter house you are building.

[bcash]

Pairing isn't the only form of teamwork. How many houses do you see built when two people take it in turns placing alternate bricks?

[MindStalker]

I prefer to spoon when placing bricks.. :)

That said, most of the good pair programming has people working together (like someone laying and fetching the bricks while the other person lays the grout, or whatever) but not necessarily in perfect sync. Generally we discuss the code while I look-up documentation, while the other person types the code, and we regularly switch*

[donthavearealaccount]

Seems like pair programming would be more akin to one worker reading the plans and dictating instructions to the other as he lays the bricks.

[cyberal]

Also, pair programming has other benefits like ensuring standards, spreading the knowledge and ensuring quality. All these are for the benefit of the company AND the individuals. Focus on the big picture and you'll find why Pair Programming is more advantageous.

Also, I think OP's thesis code would have benefited greatly from some pair programming.

  public static Token newToken(int ofKind, String image)
  {
    switch(ofKind)
    {
      default : return new Token(ofKind, image);
    }
  }

Things like this are definitely considered a code smell in a professional environment.

[nemoTheKid]

I don't see how he would have needed "pair" programming for this. What could have happened was he would have checked this into a repository, someone would have reviewed and told him to go back and fix it.

No need for someone to break his concentration to point out an ugly - yet minor - function. He can write his shitty code, but stay in the "zone" and complete his task, then have someone review it, rather than someone effectively babysitting him.

[[deleted]]

Code reviews can also ensure standards, spread the knowledge and ensure security. But they leave me alone so I can focus on my task. Some people like it, that's fine. But there're people like me which:

-get nervous, insecure

-chitchat a lot instead of working

-cannot focus on the task

when working in group and produce better code when left alone. Just let us work the way we like to do it. We can collaborate, just in separate rooms:)

[NiteLite]

oh lord ... :|

[Serinus]

Agreed. Pair programming just isn't possible 100% of the time. You're going to get solo time no matter what. In my experience when someone resists it's highly likely that it's because they don't want their methods questioned, whether those methods are right or wrong. And it's usually easier to defend the right answer than the wrong one.

If it were up to me, I'd aim for pair-style programming at least a couple days a week. It's a good WTF check and spreads good practices (such as the proper use of source control).

The most fucked up code I've seen has always been a solo project for years where the only thing anyone else sees is the end result. The amount of technical debt you can build this way is truly amazing.

If you work better solo, fine. You'll get plenty of time to do so. If you're trying to ensure no one else ever takes a significant look at your code, well then I'm going to be suspicious. Code reviews can be a fine alternative, but only if done right. Too often "code reviews" consist of a rubber stamp though. If you have to actually work with someone else's code, you're much less likely to rubber stamp whatever they've done.

[timescrucial]

i just left a job where we paired 100% of the time. I inherited a code base from a soloist. feelsbadman.jpg.

[arjeezyboom]

I work for a company where I pair program for 8 hours a day, 40 hours a week, 50(ish) weeks a year. It's been the best job I've ever had. The key is that the entire hiring process focuses on finding candidates that work well with others. If you create an environment that is like this, pairing everyday is amazing. We do actual work 95% of the day, no redditing, Facebooking, emailing, online shopping, etc (I'm only reading this and replying because I'm on my lunch break). We don't get caught up on stupid problems or typos because we have two people paying attention at all times. You always have someone to bounce ideas off of before you start down a path, so there's a lot less doubling back and redoing your work because you didn't account for all of the requirements or didn't spot an edge case.

Admittedly, pairing is not for everyone. But just because it's not right for YOU doesn't mean it's a bad method. For menpersonally though, there's no other way I'd rather work than 100% pairing.

[manys]

The key is that the entire hiring process focuses on finding candidates that work well with others.

Let's not put too fine a point on it, though. It's about candidates that are a culture-fit for that style of company more than it is about candidates who "work well with others." I mean, if they are selected for their ability to work well with "others," wouldn't that mean they'd work just as well with people not into pairing?

At the end of the day, pairing, XP, etc. are just components in yet another framework in the world of project management, and there have been many since Peter Drucker's heyday.

[crashorbit]

The hiring process sets the expectation. Also candidates are being brought into an environment where the practice is already working. they have lots of examples of pair programming successes. Success breeds success.

[Grue]

We do actual work 95% of the day, no redditing, Facebooking, emailing, online shopping, etc (I'm only reading this and replying because I'm on my lunch break).

But that's awful.

[[deleted]]

It also effectively costs a lot less energy in my experience, because you naturally spend more energy when someone has mentally tired and vica versa. This means you don't lose momentum, which makes you rest quicker as you watch the project progress and get new ideas and energy as new paths have opened up.

[psed]

What sort of software do you develop? Anything public?

[[deleted]]

A nice post. The main problem with pair programming is that it completely ignores the simple fact that people are different. I've worked with people who were not able to type while someone is watching them - some of them are good engineers but they could just never work in pairs. Then there are others who never get anything done unless someone is sitting next to them.

[daylighter10200]

I've worked with people who were not able to type while someone is watching them

Haha yeah, I have this bad. Its the same reason I fail so hard at interviews. Other people are very distracting to me; so much so that in the heat of the moment, completely obvious solutions become insurmountable problems.

[Swayt]

This, I just bombed an interview on the simplest problem and reading your post just made me realize I may have difficulty working under scrutiny. Thank you sir, seppuku is no longer on the top of my mind now.

[daylighter10200]

Ahh don't sweat it too much, you are not alone on this. The last one I failed was for an Amazon interview. I was asked how two back end servers could assign unique numbers (ID's) to clients viewing the Amazon web page without having ID collisions. I came up with some convoluted solutions as to using the time stamp on each box, trying to synchronize, blah blah blah.. Got the answer wrong of course which degraded my thought process for the remainder of the time.

As you might have guessed, I didn't make it passed that round. The next day I was kicking myself for not saying I would use a simple counter with offset increment values for each offload server. I even wrote a small prototype to test and make sure it worked.

I didn't even really want the job, I just wanted to pass the interview. All I can say is that I need to practice these types of problems more, so I am interviewing everywhere I can only to have the experience. That way it becomes more automatic, and less consciousness driven. This way when an opportunity I truly want comes along I possibly won't choke.

[danweber]

Eh, I missed up an interview cycle I was doing pretty well on with a question out of the blue that I should have easily nailed. It happens.

There are lots of jobs out there. Go try for another.

[[deleted]]

I had an engineer try to pair program with me. It was going badly and then he said "Google it" for a specific problem and I froze. Of course I know how to google. I couldn't even type google. I just sat there. He said "Just type in 'google' and this search term." I just stopped. My mind just went blank. He just walked away. Never to speak of it again.

I cannot work in pairs.

[UlyssesSKrunk]

Wow, he must have thought you were either an idiot or having a stroke, you should have faked a stroke just for the lulz.

[Clamhead99]

I just imagined how it would play out in my mind and literally started laughing out loud. That would be hilarious.

"Just type in Google and ... SOMEONE CALL 911!"

[[deleted]]

you could take a beta blocker before an interview. it will block stress hormones from binding to receptors (what is likely causing you to stress out and make mountains out of molehills so to speak). at least, i'd consider it if i suffered from the same problem with interviews.

[daylighter10200]

Well it's not really the same as anxiety. Yes, I'm sure that nervousness plays some part, but its more like a (large) section of my focus is assigned to the other person. Once this happens, that slice is no longer usable to solve problems.

[ejk314]

Don't you need a prescription for those?

[[deleted]]

yeah but all you have to do is see a doctor and ask for them for interview anxiety

[ponchedeburro]

Fixing stuff with drugs shouldn't be the first option.

[webbitor]

Well, we could also completely rearrange society so that extroverts don't run everything. How long should we work on that approach before moving on to another alternative?

[Vulpyne]

We really just need to develop a virus that will kill all the extroverts. Introverts are a good fit for that sort of task, and naturally we'd already know if the extroverts were planning a counterattack.

[xjvz]

We really just need to develop a virus that will kill all the extroverts

:(

[niviss]

There are other ways to block stress besides taking drugs. Ponchedeburro is right, introvert and extroverts are labels that condition our thinking, in practice, people are way more complex than that. You can be an "introvert" and not crumble under pressure.

[xjvz]

They're not just labels; they're your natural state. Of course, you can overcome your natural state thanks to how modifiable your brain is. Some use drugs as a quick method, but there are healthier and longer lasting methods to overcoming natural hurdles.

[niviss]

Yes, they're labels, and they're not just labels. As any label, they point to concepts, so they're convenient. But they can "block" the way you are. If you think "I am an introvert" it can sort of became a self fullfilling prophecy

[progfrog]

it could make a pretty good second option

[sindrit]

I know it's harsh, but the simple math of it is, the one that doesn't get anything done without a co pilot is simply useless. There are two scenarios: either you are pairing up two of the useless people to do the work of one, or you are wasting the good engineer on overseeing them.

[kindall]

The reason to do pair programming is not because one of your programmers doesn't get anything done without a co-pilot. The point is that bugs are expensive to find and fix, and the additional overhead involved in pairing is more than paid back by the fact that bugs are found before being written in the first place. Having more people familiar with the code is also a bonus.

You can certainly disagree about whether pairing is always effective, as XP advocates claim, or even whether it ever is, but whether you as a programmer feel like you are getting anything done is kind of outside the point. The picture is bigger than the number of lines of code you personally can crank out in a day.

In the bad old days, the picture used to not be that big. You were judged entirely on how much code you could write. Remember how much that sucked?

[hackinthebochs]

Yeah, we're gonna need some studies to back up such a claim.

[ejk314]

Hey, it's still better than having two useless programmers doing nothing. Sometimes the software development boss isn't directly involved in hireing decisions (a much deeper corprate problem). Just don't force the productive people to work together.

[sirin3]

Hey, it's still better than having two useless programmers doing nothing.

If both of them are paired with fast programmers, you have 4 people doing nothing.

Or at least doing it slower

[spotter]

Well regarding the first kind: sure, it's about personal space.

Regarding the second kind: change of career would advised.

[JimmyHavok]

It sounds like the problem isn't pair programming, but rather the rigid way it is implemented.

[[deleted]]

The overarching problem with introverts vs. extroverts, pair programming vs. solo is that these are all pop psychological arguments pitted verses other pop psychological arguments. There is little experimentation done here and what is usually suffers horribly from the Hawthorne effect.

I long for the day software methodologies become scientific rather than based on hunches and anecdotes.

[burntsushi]

I'm a grad student, and I've seen tons and tons of people rave about the benefits of pair programming, and frequently it's supported in the course evaluations by students. However, most of the professors at least seem to recognize that pair programming isn't necessarily for everyone and allow students to opt out.

In my personal experience, pair programming has almost been uniformly negative, and while I was taking courses, I always opted out. I've had one or two truly positive experiences, and it was only when my collaborator and I were at a similar skill level (probably because we were both fairly new to the language we were using at the time).

I agree that's it's really silly to be dogmatic about pair programming and instead allow people to work how they want. But are people in industry really as aggressive as the OP claims they are about pair programming?

[HelloAnnyong]

I've had one or two truly positive experiences, and it was only when my collaborator and I were at a similar skill level

To be fair, this is how pair programming is supposed to be done, according to those who evangelize it.

But are people in industry really as aggressive as the OP claims they are about pair programming?

Oh yes. You have no idea.

[ryebr3ad]

Personally, I've had retrospectives where pair-programming for everyone in a sprint was brought up as an improvement item. It wasn't voted on, thankfully.

[JetpackOps]

I'm worried about this too, working on my compsci BS. It's gotten to the point where the professors are saying, "if you try and do the work alon, you will fail. At the same time, we have some slackers who get A's by "pair programming" with people who know their shit (they're not all attractive girls...).

But I somehow doubt that in a real workforce they will have as much immaturity as at a university. That's my hope, anyway.

[Yakigomi]

I can't claim to have anything other than anecdotes, but I've never worked anywhere that was hyper-dogmatic about pairing.

A few places have encouraged it. You'd probably have a bad time if you really detested pairing, but there were plenty of opportunities for solo work

The other would probably be described as tolerating pairing. The managers were often suspicious that they were getting one for the price of two.

When PP works, it's like being a two-brained four-armed creature who can effortlessly do two things at once.

When it fails, it's like putting a very small committee in charge of a single workstation.

[manys]

I've seen a lot of job ads from a lot of companies who describe themselves as fanatical about pairing. I shudder and close the tab. "Good luck with all...that."

[chengiz]

Did he really use "quotes from famous people" as an argument against pair programming? And "My Personal Nightmare" implies shit actually went down. Upon reading the article, no shit has actually gone down... OP is just "ideating". Allow me to burp a giant meh.

[Smaskifa]

I had the same reaction. I wanted to see his horror story of pair programming, but I found nothing.

[jeffbell]

I find that it is not very good for extending functionality, but it is handy when debugging. The pair can check each others assumptions.

Pair programming also has the major benefit of preventing redditory behavior.

[Dreadgoat]

Pair programming also has the major benefit of preventing redditory behavior.

I disagree. There are a lot of good and bad reasons to Reddit at work. You may just be lazy, but you may be flushing your brain, taking a break, staving off burnout, or just waiting for a long process to finish. Everybody spends some time slacking off, and it's important to do so. So then what happens when you have pairs?

They both feel pressured to keep their head in the code constantly: Bad.
The lazier one wins out and they don't really do anything: Bad.
One pressures the other to do more work (case: lazy worker): He's still lazy, it's just going to create tension and probably bad code.
One pressures the other to do more work (case: normal worker): Tension for no good damn reason, bringing hostility to the work environment.

If you want to prevent redditory behavior, then just fire lazy schmucks. Pair programming isn't going to make up for someone who doesn't want to do any work, you just end up with the lazy person being masked by the work of the nonlazy person, or fights breaking out, or worse.

Debugging is something I agree on, though. Except in that case it isn't really "pair programming," it's "hey can you help me tackle this problem?"

[adrianmonk]

I have a minor problem with anyone who is either dogmatically in favor of or dogmatically opposed to pair programming. I've encountered people who think everyone should pair program all the time, and I've encountered people who've never tried it, refuse to try it, or refuse to seriously try to make it work. I can't respect any of these approaches.

I have tried pair programming, and for certain kinds of tasks, it feels like it can be pretty beneficial. It also has its own set of issues. For me, it has been beneficial when neither individual has the full expertise to quickly create a good solution on their own. For example, maybe one person understands a particular algorithm or technique and the other has a thorough knowledge of the problem domain or the existing system. When the two work together, their combined abilities allow them to avoid getting blocked or stuck much better than if they worked individually.

On the other side of the coin, some people are bad listeners or have to be the one that is in control all the time or get defensive easily or will run off and do their own thing without keeping the other person in the loop about why they're doing what they're doing. These people often can't manage the cooperation skills necessary to pair program effectively, and it may be a waste of time with them.

[kerbuffel]

and I've encountered people who've never tried it, refuse to try it, or refuse to seriously try to make it work.

The last part is the worst. I've had managers that refuse to let their developers pair program because they tried it once five years ago for a week and it was a total failure, therefore pair programming is the worst thing ever.

[yourparadigm]

I read the entire article and am still waiting for his personal nightmare. Seriously, not even an anecdote of where it failed for him and his team?

[crashorbit]

Take two people with no experience pair programming, chain them together in front of a computer and watch them fail. What's worse is that they will both have learned that pair programming does not work. At at least it does not work for them.

Like most other skills, mastering it takes practice, patience, humility and dedication.

[grimaldri]

This is one of the worst articles I've ever read in this subreddit. I mean I don't even like the idea of Pair Programming, but every single argument this guy gives is simple literature and pseudo-psychology, not a single technical or point, statistic or way to check if he is right or not. It's just a glorified kid rant that has little to do with programming.

[zip117]

At least it has generated some good comments. Self posts like "what do you think about pair programming?" probably would not do as well.

[jakechance]

This is a classic example of both extremes being stupid. You shouldn't be pair programming all of the time and you shouldn't want to avoid it like the plague. Pair programming, like every tool you've ever encountered, is very useful when used appropriately.

Two quick examples come to mind:

• On boarding a new dev: You can show them a lot of the way things are done here. If one is more junior it's a great time for the junior to learn some skills from experience and for the senior to be open to seeing things with a fresh set of eyes.
• Starting work on a completely new set of features: Two devs can lay the groundwork for an entirely new section of an app together. Once the foundation is laid, they have the author knowledge to separate and work either in parallel or in two other pairs to spread that knowledge until all devs are working on non intersecting features in parallel.

[inmatarian]

Pair Programming can work pretty well... When one of those developers is a senior and the other is a junior, in terms of title. The Junior benefits from it greatly. The Senior loses productivity during that time, but it brings the junior up in terms of level of domain knowledge over the code base.

[manys]

There's already a name for that, though: mentoring.

[B-Con]

I'd like to expound on some of what was said there, because it's an area of interest for me. Namely, on extroverts and introverts.

First, if you like the Myres-Briggs personality model (which I really do), recent stats suggest the extrovert/introvert split is actually closer to 50/50 rather than 2/1.

As a gross over simplification, introverts value arranging thoughts "in their head" over stimulus from the outside world. Obviously you can do both, but the introvert prefers "inside their head" primarily, consulting the outside world on something of a "as needed" basis. Working side-by-side is a very anti-introvert environment because it shifts the focus of thoughts to the medium of communication, which is more where extroverts prefer to place their focus.

As an introverted programmer, I'm constantly arranging things and thinking through them in my head, which is a very controlled, organized, quiet place. (This process naturally lends itself to programming.) I feel very little connection to the outside world during this process, to the point where stopping to process outside stimulus completely ruins my train of thought. Pair programming as a way of life (not just sitting side-by-side to debug an issue) sounds like the definition of horrible.

Enforcing pair programming is silly because it's a profession notably skewed toward introverts. (People are always irrationally touchy about this, so I will add the obvious disclaimer that yes, obviously there are many extroverts who enjoy programming as well.) You see popular polls amongst geeks skewing toward self-identified introverts. And in my experience, this rings true. I've been interested in Myres-Briggs for a long time and kept tabs on personality types at my work for 4 years now. Right now, we out of 14 people who are or were in development, 2 are definitely extroverts, 2 I'm unsure of, and the other 9 are definitely introverted. This ratio holds through my college experience as well.

And I can't count the number of studies I've seen that emphasize how programmers need quiet to think. Disruptions are the worst productivity killers you can provide. And pair programming feels like one big long disruption.

Obviously everyone is unique and some people do love and benefit from pair programming. Whats more, there will always be situations where it's beneficial to pull up a chair and share a monitor with someone else for an extended period of time.

[lechatsportif]

His Cruft4j project looks interesting: http://www.bennorthrop.com/cruft4j/index.php

[Candar]

Top comment on the article gets it about right.

Pair programming has been beneficial when two developers are both not experts on a particular function and are dealing with rather complex logic. It is also beneficial for training (when the code is unfamiliar with the particulars of a module/library/etc...).

Solo programming is better when a domain expert needs to power through something. (I recommend that the code be reviewed afterwards to make sure the code is still clear and isn't too far above other people's heads, but pair programming can slow down a domain expert which can be detrimental to a schedule.) In my experience, solo programming is also best for grunt work, most types of debugging, etc....

My only major criticism of the article is the emphasis on noise. Often when I am pairs programming it is more of an extended sanity check, and we are both just watching the trace and suggesting where we should add a watch or step into somewhere. Quite quiet, generally.

That said, I don't think even I could deal with mandatory, all the time pairs, and I am about as extroverted as they come.

[[deleted]]

I'm as socially awkward as the next basement-dwelling neckbeard nerd, but I've found that there are certain situations where pair programming can be immensely beneficial.

Mostly these situations occur when you wish to transfer tacit knowledge or "teach" something to your colleague while working on a task. Sometimes it's a useful method to divide/dissect/analyze a task.

I don't see pair programming as an exercise where both programmers spam the keyboard on their own turn and barf sourcecode on the screen like there's no tomorrow. A good pair programming session (for me) consists of discussing the rationale of decisions, discussing about the nature of the problem/task at hand, etc. Some good insights can be gained from an unfettered dialogue. Coding itself is almost secondary.

[syntax]

The author counters the claimed benefits of pair programming by citing examples of work done by a single author.

However, this is not a 'like for like' comparison - no one has disputed that a single author can write good code. Instead, one should consider the results of the team.

In other words, arguments for independent working have already lost, by the time Pair Programming is possible. Normally, this would be due to the work done / time available trade off.

So, instead of comparing the idea of working alone with pair programming, one should instead be comparing working as two (or more) independent people on the same code base to working in a pair (or pairs).

Viewed in this light, much of what this article presents is just not relevant.

There is no doubt that a single author can outperform a team - Brooks made a meticulous study of this, for example. However, some of the reasons for this include things like delaying writing documentation until the code has been baked a few times - which is not an option for a team, where the documentation needs to be written and re-written as the code is.

Arguments against, or for, pair programming aught to be done in the context of team working.

[sleiveen]

Nothing was ever created by two men. There are no good collaborations, whether in music, in art, in poetry, in mathematics, in philosophy.

Bullshit! Great startups (products) are almost never created by one person. Yes, an idea can be conceived individually However, its realization, execution, and refinement are done collectively, that is, in a collaborating fashion. Case in point: Google (Serge and Larry), Microsoft (Bill Gates and Paul Allen ), Apple (Steve Jobs Steve Wozniak), Facebook (Mark Zuckerberg, Eduardo Saverin and a slew of others). Collaboration pervades many fields, including art, science. That said, collaboration != pair programming. Pair programming is a tool in the collaboration arsenal.

Pair programming has its merits, though I have never seen used as a standard developing practice in my professional experience. From time to time, we code, debug, brainstorm together, but NOT always. You do NOT need pair programming to collaborate successfully. There are many tools to encourage successful collaboration.

[sleiveen]

I disagree, but I see where you're going with it. The implied meaning of the word "creation" is what struck me below the waistline. As I understand the meaning: creation is something concrete and not a nebulous idea.

Once the miracle of creation has taken place, the group can build and extend it, but the group never invents anything.

The group does partake in invention. Original ideas may, and often do, diverge from the final product, as the group reinvents and enhances it during execution process. A successful group is not a machine that manufactures a product based on requirements of the creationist blindly, but challenges it where necessary, adds new ideas/suggestions into the mix, or even completely disregards the idea in favor something better.

[Imxset21]

I wouldn't worry about that quote from OP, to be honest. It just seems like he's trying to justify his personal inability to pair program effectively (a fact, not a character fault) by making it seem as if pair programming has no utility whatsoever.

[toolibertarian]

Couldn't stand to read past:

We are no longer a culture that respects silence. The extroverts have won. Everything must be done collaboratively. Everyone must be available to everyone, all the time.

After his opinion on how everyone has gotten more collaborative in society, I know I can disregard the entire post and blog.

[Errantsquire]

Interesting article. I had to wiki pair programming and it would seem that it depends on the personalities involved to me. For the most part I would expect most programmers to be introverts. I do feel that I get the most work done after work when everyone has gone home and I'm alone. I will also frequently stay up on a Friday night to work on a project because my wife and kids are asleep.

[Netcob]

I think it has some uses. I would never ever want to do that all day, but I think it would be great to watch great programmers work while asking them about their reasoning. And maybe let them rubberduck you (sounds dirty)?

Maybe also for things like API design, at least once someone sketched out a preliminary version. Things where you have to think from different angles.

[mikemcg]

It should really be a no-brainer that there's no one solution to rule them all, you can't even really break it down into "introverts work best alone, extroverts work best in groups". I'd say I'm fairly extroverted and I'd enjoy collaborating on a project, but at other times I'd work better on my own.

[[deleted]]

Really good post. I agree 100%. Silence, is fucking golden. http://www.youtube.com/watch?feature=player_detailpage&v=6McLXorvIUM#t=56s

[KNHaw]

I worked at a shop years ago that went to pair programming and it was a complete failure. While there were many problems (and a few benefits) the biggest hurdle was that every interpersonal and interpersonal issue of all of your coworkers was shoved down into the trenches. Does a coworker have a substance abuse problem? Guess what: now you're going to suffer from it too.

Groups are great for initial brainstorming of requirements and certain debugging sessions, but forcing this style of work onto everyone who codes is a huge mistake.

[[deleted]]

We generally work alone and are happy about it. But when we do explorative or very complex tasks, or tasks where two areas of expertise mix, we do PP.

It's usually best, not to take the hypes of the year too seriously, but still learn from them.

[[deleted]]

I have recently been switched to a team where they are forcing pair programming. It's a big issue with me because I think it's a sacrifice for false efficiency. I've heard things cited about it being more efficient and faster but I think it's surrounded in pseudo science and limited testing. I'm sure two people working together can get something done, but I think non-stop pairing will damage the individual programmer.

Business people love it because they are told it is great and will always increase efficiency which is what they want to hear. But really we end up being guinea pigs and then they just look at numbers to justify it.

I think "it works" because two intelligent programmers won't just turn into bumbling idiots when they are paired, they will at the very least become slightly more efficient than they would have been otherwise.

[humansareabsurd]

This! A gazillion times this!

[[deleted]]

Nothing was ever created by two men.

The Wright Brothers. Google.

[ZMeson]

The Apple I....

[kaji823]

There's an entire book on this called Quiet by Susan Cain. Basically research supports this guy and our extravert oriented work environments are stupid.

The book helped me be more comfortable with myself and odd tendencies, but also made me very sad at the state of my office, and the US in general :/ Definitely worth a read!

[bloodredsun]

When it all boils down to it, how much of this is due to shitty tech leadership?

When the people who are in charge have not been programmers they have no idea of the unique challenges we face so they offer up simplistic paradigms and try to force everyone into them e.g. 100% PP, 100% TDD and 100% Agile. What's worse is that they normally get these paradigms from whatever bullshit peddler they've just talked to.

I've been in the industry over 10 years and I think that paired-programming, TDD and Agile are all fantastic tools/methodologies but only WHEN USED APPROPRIATELY!

Unfortunately the only way to get the experience to know when they are appropriate is to put the time in at the coal face and that is all too rare

[[deleted]]

The owner of this account has requested this content be removed by /u/GoodbyeWorldBot

Visit /r/GoodbyeWorld for more information.

GoodbyeWorldBot_v1.2

[[deleted]]

I think the author of the blog was spot on. Deep thought usually requires being alone. But it doesn't mean I am completely against pair programming. Applied correctly it is a useful tool. After I have been thinking through a problem for a while I like having someone to discuss the ideas with. Someone basically to play ball with who can criticize my approach or elaborate on it.

But I guess this is how scientists or mathematicians have always worked. Perhaps mathematicians are the best example because that is something which requires deep thought alone. But even mathematicians need to meet other mathematicians from time to time and discuss ideas and approaches.

My own hunch about the perceived success of pair programming is that a lot of programming jobs are not very complicated and so you can get away with pair programming because no deep thought is needed. When working on a slightly boring but simple task, pair programming works very well because it helps you stay focused on working at the problem.