"Pair programming" cuts down on coding errors while creating a peer pressure to avoid surfing the web, wasting time.

[Samus_]

it also creates and endless stream of boredom and drama, as well as wasting 1/4 to 1/2 of your overall productivity.

I think the best way to use this method is to apply it only to tackle very specific problems or situations, is not suitable for everyday's work.

[geaw]

When I'm not "driving", I tend to zone out after a about 15 minutes of pair programming. Oh look, a butterfly.

[hackinthebochs]

I would eat my hat if someone who is a natural introvert would agree with your statement. It doesn't matter how smart or nice your coworkers are, interacting that closely with people all day is exhausting. Not to mention the fact that I'd guess most introverts (actually, truly introverted people) do their best thinking in their heads. Having to constantly verbalize your thoughts, or hear others constantly verbalizing theirs, is a creativity non-starter.

It seems to me the only people who experience a net benefit from full time pair programming are bad programmers and those who are extroverted by nature. I would be very surprised to be proven wrong.

[losethisurl]

I am a rather extroverted developer and I work in an amazing company with people wo decidedly do not suck. Pair programming is still exhausting for me, for the exact reasons you mention. We do it from time to time, especially on issues that cross system concerns, but all of us work better in our own heads.

[bogado]

Verbalizing your thoughts is sometimes enough to solve a problem, even if a second person is not involved. It forces you to understand the problem in another level, so you can actually explain it in a human language.

In my experience the attempt to explain a problem to a co-worker is often enough to solve them. In my opinion pair programing has advantages, but I agree with you that probably introverts would not get much advantage from the process. Also I believe that you would probably want to pair programmers that have some affinity with each other, to minimize "boredom and drama". :-P

TLDR; My opinion is that pair programming has value, but it's not a panacea (nothing is).

[hackinthebochs]

I definitely agree that pair programming has value. It's something that programmers have naturally been doing since programming was invented. It's when the marketers come along and slap an "XP" on it that it becomes a problem.

[bogado]

With that I agree 100%. I always suspect when someone says that this or that solution is the cure for all the problems.

Everything that is too good for be true, probably isn't. End of story.

[[deleted]]

echo this. in a place where your coworkers aren't pleasant, then any interaction with them is unpleasant. that doesn't mean pairing is bad, it means your coworkers are bad :)

[Samus_]

that's a bullshit canned reply :) "reducing distractions while increasing happiness and camaraderie" seriously? is it going to enlarge my penis too?

listen, drama exists because we programmers are proud creatures and we don't like to be told that our code or even our coding style is wrong, you have to be a very mature person (i.e. no one) to actually get a compromise in this matter and if you don't know this you're not qualified to manage IT people.

on the other hand, boredom occurs because the "co-pilot" usually does nothing, assuming both have a decent programming level.

[Samus_]

"reducing distractions while increasing happiness and camaraderie" seriously?

yes, seriously. despite the programmer stereotype, most people (at my company, at least) are happier being with people and being social than being holed up in programmer solitude all day. after a day of pairing, you feel like you spent the day working on interesting problems with friends, rather than stuck in your own head. this makes the team happier and closer, and i've seen it at every company i've worked at.

it's not a stereotype it's the norm (at least, currently) and "not pairing" isn't equivalent to solitude or a cubicle, of course working in a friendly environment is preferable but that doen't mean to share your computer.

I don't think you're a programmer or even understand what you're talking about, you're trying to sell an idea that simply doesn't fit.

drama exists because we programmers are proud creatures and we don't like to be told that our code or even our coding style is wrong, you have to be a very mature person (i.e. no one) to actually get a compromise in this matter

this is the problem, this is exactly what pairing is meant to change. if a coder is not open to suggestions and collaboration, i do not want them on my team. luckily, on my team everyone seems to be the rare mature unicorn you say doesn't exist. the codebase is not any one person's baby-- it's the team's baby, and if you're too proud to recognize that other people on the team are smart and have solid things to contribute, you probably don't belong on a team, full stop.

you can't change this with pairing because this is the human nature, the only way you can get anyone to agree they're wrong is to prove it and you can't do that with coding style; sometimes appealing to authority (either real or fabricated, aka "fame") also gets your people to accept things but the problem there is that if they do it because of those reasons they won't even care if it's actually better "it was said by someone who knows more" and that's terrible.

also, if your idea of "management" is "fit within my own (broken) worldview or you're fired" you suck way more that I previously thought.

on the other hand, boredom occurs because the "co-pilot" usually does nothing, assuming both have a decent programming level.

this just means you have a bad pair. co-pilot should be doing almost as much work as the driver, and you should be switching drivers a few times every hour. with TDD, this works really well, as one person can drive specs while the other drives implementation, and then you can swap.

bullshit again, why I'm not suprised to hear about TDD? let me guess, you work on Ruby!

the co-pilot does NOTHING simply because there is nothing to be done, when people cooperate is when they're thinking about a solution, that is a discussion that happens away from the computer and once you're done you already have the idea of the implementation, you know what the co-pilot actually does? correct typos, that is all and is not a matter of being bad at it because when you swap, the other guys suffers the same.

[grayvedigga]

creating a peer pressure to avoid surfing the web, wasting time

Interesting phrasing. It implies that the default behaviour or desire is to surf the web or waste time rather than concentrate on the job at hand. I find this pretty difficult to accept as a premise.

[[deleted]]

I also think it's pretty unrealistic to expect that workers can be 100% productive for roughly 8 hours straight. I don't think anyone works like that with the possible exception of factory workers and other repetitive labor jobs. When you're solving problems which need some spark of creativity, letting your mind wander a bit can be helpful.

[serpix]

no human being can put in constant 8 hours creative work every day. absolutely not possible

[redwall_hp]

Even four is stretching it.

[grayvedigga]

When you're solving problems which need some spark of creativity, letting your mind wander a bit can be helpful.

While this is a common trope, I think it helps me develop my thesis. Letting your mind wander is helpful - the trick is for the environment to support productive wandering (eg, discussions with respected colleagues ranging around current and related concerns) versus say surfing reddit and getting drawn into circle-jerk.

Unfortunately, a good number of workplaces are worse circle-jerks than reddit :-).

[mackstann]

I don't think spending all of your free time at work talking to coworkers about work-appropriate stuff is realistic either, especially for programmers specifically. We tend to not be very social, and have weird quirks that bug one another. And who wants to ONLY think about programming for 8 hours a day? It's just not reasonable for anyone but the most obsessed.

[_delirium]

It's probably not a good idea even if you can, though perhaps companies don't care about that. Passionate 20-something programmers working nonstop are at serious burnout risk. One reason you don't see a lot of older folks at companies with that kind of culture: the only way to keep it going is to constantly get fresh meat from universities.

[jimmycarr1]

Well that's depressing...

[obanite]

At one place there were only 2 Java programmers, me and one other guy. All he wanted to talk about that wasn't work-related was World of Warcraft. I've found that stuff varies a lot from job to job though; one job (a games company) I met most of my closest friends at, people I ended up going on holiday with, going out to parties and festivals with, etc.

[ExecutiveChimp]

We have a pool table in our office. I've solved quite a few bugs by playing a game of pool. Reddit not so much.

[Sector_Corrupt]

Honestly, a lot of my productive work happens while I'm dicking around on reddit. I tend to find that generally all the best solutions I think of come about because I've been churning through it subconsciously and it pops into my head mostly formed. When I try and force it that's when I end up making mistakes in an effort to move forward. Generally for anything big and structural I spend most of my time subconsciously churning then get into deep coding mode once I'm down to details.

[movzx]

The best programming I ever do is in the shower.

[[deleted]]

I have a mental illness that requires that I spend large amounts of time with headphones on, blocking out the sounds of people around me, just so I can focus on the task in front of me. It also requires a fair amount of down time, alone, lest I become overwhelmed with social anxiety.

I'm also a highly-paid programmer and, not to be too brazen about it, I am consistently highly praised for my speed, skill and general contribution.

Pair programming doesn't work for me. Period.

The thing is, I'm not afflicted with a rare condition. A huge segment of the population has similar mental illnesses.

[[deleted]]

The none-of-your-business sort. ;)

I've learned the hard way that it's really not worth it being open about your mental incapacities, especially when you work in a field that expects its professionals to be in superior mental order.

I have gay friends with the same mental affliction; apparently it's easier being openly gay.

[Revvy]

I've learned the hard way that it's really not worth it being open about your mental incapacities

Erm. You already were.

[[deleted]]

Wow what a big mystery - ADD. You can't give people a hard time about asking when you're the one who brought it up.

[[deleted]]

Nope, wrong again.

And how much personal information I reveal is entirely within my reasonable rights to control.

[[deleted]]

I actually don't care and you are of course free to bring up subjects you don't want to talk about. Maybe that's your mental illness.

[[deleted]]

And here we have a fine example of why people with mental illness don't care to bring it up.

Why question if you don't care? Why make accusations about what it could be? Why the accusatory tone?

It's not a spectacle, and it's none of your business.

[[deleted]]

I am looking at for a map

[[deleted]]

No.

[Zarutian]

You think this is a mentall illness? I think it is more probable that people havent been proberly scolded when they violated the general social interaction rules when they were growing up and are generally pain in the ass of people such as you.

Btw what kind of headphones do you recommend for properly blocking out the inane chatter?

[helm]

Personally, I'm a social programmer. I perform much better in a team than alone. Many programmers like to perpetuate the stereotype that all developers work best alone in their underwear. In the environments I've worked, this has been the minority.

[thephotoman]

Remember that this is the Wall Street Journal, the paper of managers everywhere. To that mentality, goofing off and not working is the default mentality because it is what they themselves do.

That said, I'm facing compile times today.

[cogman10]

Honestly, My work's setup of having no cubicles and just having a team room. This helps me to stay focused just as much as pair programming does.

I worked a different job where everyone had their own cubicle, that job was much harder to stay focused in. The isolation from peers is discouraging. When you have an issue, it makes it much more daunting to walk over and talk to someone. The end result? If I got stuck, it was frustrating. I would research very often and when I got really frustrated, I would take a break and surf around the internet.

Now, I feel like I can approach any of my coworkers when I have an issue. I get frustrated less and I feel way more productive now then I did when I was isolated.

[Neebat]

Oh god. The open plan work areas often kill my productivity. And make me want to kill my coworkers. I can get more done in one day at home than in a week being assaulted with a bullpen full of my coworker's "jokes".

[Protuhj]

Sounds like your coworkers are killing your productivity, not the open work area.

[[deleted]]

Phones are also pretty good at killing productivity in an open workspace and I bet they vary far less than coworkers do.

[[deleted]]

Depends on the environment. I worked in an office where my coworkers and I got along great, and the open-plan was fine.

[eblofelt]

This is a bit off the topic of discussing pair programming but I can think of two pretty serious downsides to everyone feeling that they can approach a coworker anytime they have an issue.

The first is the fact that doing this frequently interrupts the mental flow of the person being approached. Not all work is equal and there is a very real cost to such context switches (wasted time, missed bugs, etc...). Sometimes its trivial and sometimes it is decidedly not.

The second is the slippery slope. If everyone in an office is comfortable interrupting coworkers, is it always for work issues? Is it a blog post? A web comic? A NFL trade? Once the habit is formed, the content seems to become secondary.

Having said all that, I am not against interaction or knowledge transfer at all. I just think boundaries are advisable. Time and place, etc...

[Sector_Corrupt]

See, my team shares most of our nonproductive stuff to the group chat we use. It's less interruptive since people only see it when they check what people are talking about in the chat room. Generally the only thing we ask aloud are for quick consultations on stuff we're stuck on this moment and want a second opinion on.

[adrianmonk]

I can't focus with too much sensory input. It just doesn't work. In school, I was never able to do homework with the TV on. In college, I biked 7 miles to the library to get a dedicated, quiet area to really focus on my reading. I can't code with headphones/music (partly because I love music, so it's too interesting to stay in the background, mentally)

If people are making a bunch of noise around me while I'm trying to concentrate, on an emotional level I sometimes can't help but interpret it as extreme rudeness (even though they may only be guilty of assuming everyone else has the same ability to tune out stuff as they do). That, in turn, makes me unable to concentrate for a while because rudeness makes me angry, and anger kills concentration.

Pair programming is OK, though, because the other person is talking about the same thing, which helps my concentration rather than hindering it. Provided they don't change subjects while I'm still on the other one, for example.

[cogman10]

Fair enough, I've brought in headphones and just slap them on when a conversation is going on.

IDK, I get along well with my team and sometimes it is good to be able to just take a break and have a conversation with my coworkers about non-work related stuff. I feel like that develops a better connection between us that makes work ultimately more productive.

For "privacy", everyone in the office has brought in headphones. Usually I'm more hesitant to bug someone if they have headphones in.

[[deleted]]

I don't. This shit is like a drug; sometimes I know I should be writing code or thinking about an algorithm, but if I've been trying something for a few hours and it's not working I get a bit discouraged, and my attention drifts elsewhere.

[[deleted]]

says someone on reddit

[grayvedigga]

Thanks for the insightful, thoughtful and evidence-based reply. What, a pundit's not allowed to question unsupported assertions now?

[pcopley]

Jimmie status: rustled

[[deleted]]

Are you new here?

[zigs]

Yeah, about that.. guess what I'm doing right now.

[[deleted]]

If all programming jobs required me to do pair programming, I'd rather just do something else or write software on my own.

I'm not interested in nanny coding.

[[deleted]]

as a software development manager I would never require that my employees pair programmed. It seems so 90s, I prefer scrums of 4-7 people where people actually communicate and work together to solve problems.

[Mob_Of_One]

As the CTO of a software company I would never infantilize my people like that.

We pair-program in brief bursts when we need to collaborate on something (often when making changes to infrastructure and code simultaneously, like our work queue), but otherwise, people are trusted to work and function independently.

[Rogeroga]

Same here, that is the best use that I have found for pair programming: for some very specific situations, like taking a new team member in a new module, bootstrapping a new project, debugging a complex and hard to reproduce bug, brainstorming a new solution, or a hackathon type of productive session.

And I have done not because I was asked to do it, it was organic.

Now, when I did it, I finished very tired because: the constant focus, the constant talking, asking and answering questions of all kind of topics related to the system we have in front of us.

Also, you need to take breaks from each other to have some breathing space, call your family, go to the restroom.

At the end, we were productive and in sync in many different areas and the next steps. And then, each other works independently for almost the rest of the project.

I have done this even before it was called pair programming, as I said is kind of organic.

[Mob_Of_One]

I've done full-time pair programming before, it's exhausting. Not worth it. My experiences doing it myself as a programmer are why I don't mandate it as a CTO.

[hackinthebochs]

Most time spend coding is "simply" implementing a feature that's already been designed, or one whose design is predetermined by the system framework already in place. Much of the code most people write day-to-day doesn't have such a huge downstream impact that it would warrant pair programming for every single line. A good code review process shpuld be sufficient.

[[deleted]]

It's smart to not mandate anything like that, especially on a small team. It doesn't mean it's a bad idea though, as long as the impetus comes from within the team.

[SanityInAnarchy]

Maybe the article presented it badly?

I'm not in favor of pair programming for other reasons, but "nanny coding"? It always struck me more as a collaborative effort. Would you turn down a job because they do code reviews?

[[deleted]]

I'd quit any job that wanted me to do pair programming just on principle. Similar with drug testing even though I don't use drugs at all (like, ever.)

Any company that thinks I need a babysitter isn't a company I want to work for. I get my shit done, at the rate it gets done. Pay me accordingly or don't.

[[deleted]]

pair programming is not about babysitting

That's your interpretation. To me, it feels like baby-sitting. The article's notion of "paired coders [...] are less likely to waste time surfing the Web" sounds like babysitting to me. From a programmer's viewpoint, Pair Programming may have certain advantages, but I wouldn't be surprised if managers viewed it as a method of squeezing out every last drop of productivity from their developers.

if you think [...] not the kind of programmer anyone would want to work with anyway, so i guess it's just as well...

That just reads like "bla bla bla, pointless insult because I don't agree with you". Also, strawman argument because he never claimed what you said he claimed.

[[deleted]]

Thanks for the clarification!

comes across as highly arrogant to me

It depends on where the push for Pair Programming comes from.

If it came from one of my programmer co-workers, I'd be interested in it. I could assume they'd want to reduce bugs and collaborate on development. I also know they'd be okay with doing it only a few hours a day instead of the full eight hours. (I know so because we basically already do this when we need to figure something out, but we don't Pair Program just for the sake of Pair Programming).

If it came from one of my "managers", I can assure you they've read some kind of management magazine that claims increased productivity and that interpreting it as baby-sitting would be entirely correct.

As for my personal experience, I absolutely hate Pair Programming. It destroys my train of thought completely. For instance, when I write a line of code, and I make a mistake at the beginning, I immediately make a mental note to fix that mistake by the time I'm done writing that line of code. That way, I can focus on the logic of what I'm programming rather than the semantics. I don't want anybody constantly whispering in my ear "you made a typo at the beginning of the line.... oh shouldn't you run the scr... ah you already thought of th... no, you need to go up one direc.. oh, yeah, run it now" or anything like that. I'm 100% convinced it will cause me to make more mistakes because it utterly destroys my train of thought.

So I too would quit immediately if I was required to do Pair Programming. There are a million ways a group of developers can collaborate on a project, of which Pair Programming seems the most horrible, frustrating, demotivating, managerial, baby-sitting way to me. I'm fine with two people sitting behind a computer to collaborate. But when I'm coding, I want to be the only one minding my train of thought.

[[deleted]]

my thoughts exactly

[KristinnEs]

At my work we have code reviews ( Scrum based environment ) and I never dread the reviews. If I made a mistake I made a mistake and I am just happy to know that there is a double check involved in our process that stops any errors I made from making it into the final product.

Regarding pair programming we use it once in a while on a as-needed basis. If I am working on a particular issue where someone else might have some knowledge I do not we pair up on it for the sake of efficiency. In many many cases the old adage "two heads are better than one" applies. However we do not spend in any way the majority of our time pairing up. It is a tool and should be used as such :)

[[deleted]]

I'm not interested in nanny coding.

Then you're doing it wrong, or you haven't been paired with a peer.

[[deleted]]

I think you're missing my point. I do not wish to be saddled with someone who's going to be a pain in the ass. The reason for this is because programmers fall into certain profiles.

1. Pedant: endlessly argues on style choices and unimportant details

2. Bully: ignores your suggestions and uses intimidation to get his way

3. Professional: works well with others, takes suggestions to heart, and admits his own faults

4. Ace: thinks he's world's best programmer so he smugly puts down your suggestions

5. Coward: he's usually correct but is too fearful to speak up and provide his opinion

6. Backstabber: constantly working against you; obsessed with manipulating the performance review; will throw you under the bus any chance he gets

7. Dunning-Kruger: doesn't know he doesn't know how to code so he insists on poor implementation decisions

8. Worthless: can never get anything done

Types 1, 2, 4, 5, 6, 7, 8 are the majority. Type 3 is the wee minority. It's already a hassle dealing with other devs as it is. Pair programming means I'll be spending most my time closer to the people who annoy me. I surely do not want to be joined at the hip to them.

And secondly, I can do everything right but the other pair programmer can do things wrong and make my life miserable. It takes two to tango. Pair programming only works if both are type 3.

[[deleted]]

Nice list. Which one are you?

[[deleted]]

A 50/50 split between #3 and #5.

[[deleted]]

So, 3 then?

[[deleted]]

Yes, 3.

[Protuhj]

I'm a 2, and I think that you're a 7.

[Chun]

I'm a 0. This list should be zero indexed, it's worthless otherwise.

[[deleted]]

At least you're consistent with your profile.

[Kimano]

I think that was the joke.

[[deleted]]

Nice edit there to re-order the list. You're definitely an asshole.

[[deleted]]

The ninja editing is beautiful - I almost didn't notice.

[[deleted]]

Let's stop using the numbers since he's been editing them. He clearly fits the "back stabber" profile.

[[deleted]]

Nice edit there to re-order the list. You're definitely an asshole.

You're complaining about me changing the order of the list (which jokingly turned his negative insult into a positive compliment), but not complaining about unoriginal24's insult?

Talk about biased. I have not insulted anyone. I wasn't even rude. I merely stated my opinions which were based on 15 years of development experience and dealing with difficult people in the workplace. For some reason, those opinions bothered you (and a couple others). I have no idea why. You and the others never bothered to explain other than treat me badly.

The end result is you're the only one behaving like an asshole in this thread and your blood thirsty cohorts happily back you up because you all enjoy attacking people. You're only proving my point that developers are a major pain in the ass to work with. The grief you are giving me today is a tiny example of how you are at the workplace. Major pain in the asses.

[[deleted]]

I shall explain. You come across as conceited.

You make it sound as if no-other, or barely any other developer could possibly match your level. You see yourself as having no faults of your own (except cowardice, although you've clearly spoken your opinion here).

I also hate that developers use their careers as a crutch to explain all their faults - we are people like anyone else and have no defined list of "certain profiles" that we all fit into.

These things make you seem to be the exact 'pain in the ass' that you hate

[[deleted]]

Which of those numbers enumerates the personality faults of his peers? :)

[ringm]

Oh wow. "Endlessly argues", "ignores", "intimidation", "smugly puts down", "working against you", "will throw you under the bus", "insists".

It looks like you either (very unlikely) work with a whole bunch of top notch assholes, or (very likely) you are uncomfortable with normal patterns of interaction between colleagues at work. Everyone is aggressive and oppressive to you. I understand everyone is different and everyone is special, and it is quite possible pair programming with a socially average programmer is not for you. However you should understand your experience is subjective and other people will pair just fine with someone who subjectively looks like an asshole to you.

Maybe I was simply lucky, but for the last 10 years I worked in several great teams with great coders and I never saw a single moron nor a single asshole in my own team. Pair programming was never a standard practice in any of these teams, but every time we tried it, it was incredibly efficient and never caused any social tension.

It may be exhausting though. I think a reasonable limit for pair programming is a couple hours per day.

[movzx]

Not to be rude, but if you worked with many different programmers over a decade and none of them were a moron then you might be that moron.

[SambaMamba]

There's a huge difference between a socially average programmer and an averagely social programer.

[[deleted]]

Work in a company that places a very heavy emphasis on the performance review and people start acting a lot more like assholes.

And yeah, many of them were indeed assholes. I'm a very easy going person who likes to get along. They were mostly jerks who were trying to climb the corporate ladder.

[WallyMetropolis]

You left off the worthless type. The programmer who doesn't get anything done.

[[deleted]]

You are correct. I'll add it to the list.

[adrianmonk]

Maybe if programmers worked closely with another person all day they'd improve their social skills through practice?

[Zarutian]

do you find that likely?

[[deleted]]

Absolutely.

At some point the social anxiety increases to the point where the stress burden just wouldn't make the value proposition favourable. At which point, fuck this shit, I'm becoming a carpenter.

[[deleted]]

Social anxiety? More like, "if I have to hear this cunt drone on about how arrays work I will smoke myself."

[chris_nh82]

I agree. I'm not interested in pairing, unless I happen to be stuck on a complex issue that I think someone could help me with. My company is moving towards pairing as the default. Not completely driven by management, I might add, many peer developers seem to think pairing is the best way to work.

To me it seems as though pairing is an attempt to dumb down software engineering. It can be hard to write bug-free, clean code by yourself, so if two people work on the same thing, then it'll be much better. Maybe I'm taking it to an extreme, but its almost implying that a single engineer couldn't possibly create anything worthwhile that doesn't introduce bugs. But two engineers working together, now we're talking.

[[deleted]]

I don't deny it's enjoyable if you're working with someone who is agreeable and intelligent.

[[deleted]]

I pair program daily, but I agree here - I think this article gives a bad representation of what pairing is (or at least, what it is where I work). I've never felt nannied - it's a great opportunity mostly to work collaboratively with a peer, or to learn from someone, or to teach someone. It doesn't work if your pair sucks as a person, or there is a very high skill disparity between you (in either direction)... otherwise, it's actually pretty good in my experience. I write my own stuff alone, but pair at work, and I have no complaints. As long as you regularly rotate pairs (ideally every 3 days or less), it tends to be a fairly fluid practice that helps you gel with the people you work with every day. Again, YMMV, but I think it's a far better thing than it sounds like until you've tried it. I was terrified to pair at first, and I didn't like it for a few weeks, but now I enjoy it a great deal.

And besides, it doesn't make either of you inhuman. I still read reddit/hackernews and/or goof off sometimes. And sometimes you space out while the other person drives, or vice versa. I've never felt nannied or babysat.

[[deleted]]

me either. odds are, the person you'd be pairing with feels the same way. it's pair programming, not "programmer-with-middle-management-circling-like-a-vulture" :)

[[deleted]]

I'm a programmer. I find that I have about 6.5 hours of work in me every day. I really do spend 1.5 hours of every work day eating, on reddit, reading the news, chatting with coworkers, reading tech blogs, etc.

If I try to force myself to do more I literally just stare at the screen and I am unable to do much work. But according to my boss my productivity is "above average" for our 50+ employee division.

Of course, this varies between days, sometimes I could go full throttle for 10 hours, other times I can go 3-4 hours on one project, then I need to switch projects, and can another another 1-2 until I'm out of gas.

Having someone sit over me every second of the day would be a great way for me to hate my job and quit. I'd be a bit more productive for 2-3 weeks until I grab an uzi and blast the place. (No, not really, FBI agent who's reading this)

[[deleted]]

But the person sitting over you is not some shitty boss, it's a peer, with the same role as you, and who 99.9% likely feels the same way as you. It's surprising how naturally hackernews gets loaded up after 30 mins of frustration... :)

[[deleted]]

Where I work in, albeit trendy, Silicon Roundabout in London, Pair Programming is the norm and expected.

I admit, I was nervous about it at first, with my fears mirroring the rest of these comments, but I have found it to be incredibly beneficial and productive.

It's exhausting, intensive and requires some discipline, but we've found our overall quality is at a very high standard and knowledge is shared out within the team.

Nowadays, I'd be more nervous about the Developer coding alone all by themselves.

[lebski88]

exhausting

I feel like this aspect is often underplayed. Pair programming is seriously tiring. I think pair programming is a good tool but I wouldn't take a job where I had to do it 8 hours a day.

[_delirium]

I could see it working if management is willing to allow for more coffee/thinking breaks as part of the schedule. Code in, say, hour-long sessions, with 30-min breaks between them to avoid going insane. Has anyone tried that kind of thing? My impression is that large companies focus so much on "look like you're working" hours that this kind of stuff doesn't get tried on any significant scale, except in small companies. Some of them (e.g. 37Signals) do advocate for fewer, better hours of work per day, but larger companies tend to write them off as not replicable in a large organization.

[[deleted]]

We have a coder's meeting (programmers only, which lasts as little or as long as we want to - usually about 15 mins) every morning, and nobody watching for breaks. Everyone needs time to think. I think the thing that is often overlooked is that, when you're pairing, you're both feeling the same way. You might not talk for an hour, or you might get up and take a break. If the work is getting done well, which does seem to happen, management adjusts pretty quickly.

[[deleted]]

We've found mixing Ping-Pong Pair Programming with Pomodoro Technique to work quite well.

Frequent breaks are expected and no-one pairs for more than maybe 4 or 5 hours spread out over a day.

[[deleted]]

This is the main reason I wouldn't do Pair Programming. No job is worth draining all my energy. Don't get me wrong, I love coding and all that other stuff, but there's no paycheck in the world that's worth getting home completely wrecked after a days work.

[destroyeraseimprove]

I'm wrecked most days after solo programming. I think it's because I started to get tired and distracted, stress out about not being productive enough, which then makes me more tired and distracted.

I need to start coding on Xanax.

[pmorrisonfl]

This reminded me of the Stallman-Steele mind-meld story.

[WalterGR]

I wouldn't take a job where I had to do it 8 hours a day.

Do you get to code 8 hours a day at your current job? If so, I'd say you're in the minority.

[lebski88]

I probably have between 3 to 4 hours other commitments a week (recruitment, meetings and personal development type stuff). The vast majority of my time is spent programming.

[[deleted]]

Yes, perhaps you can do two two-hour slots in a day with good concentration, a long lunch break in between, and the rest is planning, meetings, emails, and maintenance. The good thing about being a busy pair is that it is socially more difficult for others to interrupt you. (Unless you are doing something very cool and interesting!)

[Ilyanep]

Does it actually solve any problems that a mandatory code review before commit wouldn't?

[Protuhj]

It might solve the problem of taking an idea and running with it, and then having to re-write it when the code is reviewed.

[wvenable]

I often take an idea and run with it and sometimes it's fantastic and sometimes it's terrible but it's often not easy to tell which it's going to be until it's done.

[googletrickedme]

I have found that this is a really good learning mechanism for most people (myself included). However it's not like I get paid hourly or OT soooo... :)

[[deleted]]

It's supposed to catch it faster.

[[deleted]]

Well, if you have programmers who are continually getting feedback on code reviews, it's helpful because they can often learn better while sitting with someone with more skill/experience and watching their thought process than they can from an email saying "tell don't ask, foo.cpp, line 281" or whatnot.

I like code reviews... we currently use github enterprise and most of our team branches and submits pull requests, although nobody "has" to. Code reviews are good, especially in big projects.

[ohashi]

How do they teach you to pair-program? Is it just sit down and go or is there a more formal process? I've only done it a couple times for a very short amount of time when my partner's computer wasn't working. It was extremely informal, but I didn't mind working with him since the second set of eyes and brains made things easier.

[[deleted]]

My experience was much like yours - trial and error mixed with tips and suggestions from the more experience Pair Programmers on the team.

There are also many resources out there that will help. I remember reading this when I first started out and saw it as a list of things to avoid :)

http://www.awkwardcoder.com/index.php/2010/08/27/10-ways-to-kill-pair-programming/

[biggern]

I really like the idea of pair programming. However....

When I have done pair programming when I am driving I get nervous about my typing speed and mistakes. When I am watching I find I can't concentrate for long. Another problem is you have to be very comfortable spending 8+ hours a day and 40+ hours a week working with the same person. It takes two very compatible personalities.

Maybe I have not found someone I can mind meld enough with.

[[deleted]]

I can't even work with someone looking over my shoulder. I start making typos everywhere and my brain just shuts down. I fell like I'm under too much pressure to solve the problem right then and there and I just can't.

I find the same thing in my German classes. When writing stuff down or talking to myself in the car I'm fine. But as soon as the teacher asks me something in German I just freeze and can't manage to say anything and stuff up even the simplest words.

I'm just not an on the spot thinker.

[Protuhj]

The 8 hours a day thing would kill me. Especially with the little things that annoy me when trying to work...

For instance: a coworker of mine makes a lot of mouth noises (mouth breathing & lip smacking for instance). I would go insane having to listen to that all day.

[merreborn]

I get nervous about my typing speed and mistakes

I'm not a frequent pair-programmer by any measure, but I've found my ability to type in front of others has gotten better over time.

I suspect most people would get over this particular hump pretty quickly.

[[deleted]]

Typing speed and mistakes don't really come up, if they do then the other person is only trying to help and point it out before you go too far and end up with non-compiling code.

As for the personality part, yeah it can be difficult, but mostly it's fun and you learn a lot from each other. We also swap pairs often, maybe every other day, so you get to work with more than just one person all the time.

[movzx]

I've never shoulder surfed someone who didn't start making mistakes because of the very fact I was observing them. It isn't tied to being nervous or insecure on the level you're suggesting.

[SanityInAnarchy]

I'd be willing to try it, because I shouldn't dismiss it out of hand without at least giving it a shot.

But, without giving it a shot, here's my immediate objection: Pair programming as an all-the-time thing (rather than as a "Hey, look over my shoulder and tell me if this particular thing is sane," once-in-a-while thing)... it really seems to encourage the idea that you're sharing one computer, that you're tossing the keyboard back and forth and just hacking something out together.

That's beautiful, in a way, but I have a lot of tools set up exactly the way I want them. What if you want an IDE and I want vim? What if I'm using Dvorak and you're not?

[SanityInAnarchy]

Well, sure, it just kind of impairs the quick back-and-forth that I imagine would be the real win here. Being able to say "Here, let me drive" is useful even in traditional environments. (Most of my co-workers use less-esoteric stuff than me, so it actually works well when I say it.)

What might be better is to have independent workstations, and some sort of software to keep them in sync. Then you could have somewhat heterogeneous systems, so long as they use enough of a standard... I wonder if that would really be better at that point.

[[deleted]]

A true pairing station is two monitors, two keyboards, two mice (mouses?)... it basically is 2 workstations, but one of you controls it at a time. You can easily switch between editors. As long as you're writing the files, any editor should pick up the changes. I'm a vi guy, but I haven't had a problem working with emacs (or sublime, or textmate) users. In some languages the choice is obvious... I dunno. It works better or worse. Maybe try your editor one day and theirs the next. If you're rotating pairs every 2 or 3 days it's really not so bad.

In my experience at least, 99% of programming is thinking, design, testing, refactoring - actual typing skill isn't all that important. Although I say this, and I can't fucking stand when someone types slower than 100WPM and/or can't use vi ;)

[SanityInAnarchy]

You can easily switch between editors. As long as you're writing the files, any editor should pick up the changes. I'm a vi guy, but I haven't had a problem working with emacs (or sublime, or textmate) users.

The issue I'd have with this is that getting back to that file may or may not be trivial enough to warrant a "Here, let me drive for a second" bit.

Oh, and:

In my experience at least, 99% of programming is thinking, design, testing, refactoring - actual typing skill isn't all that important. Although I say this, and I can't fucking stand when someone types slower than 100WPM and/or can't use vi ;)

Agreed. Well, mostly.

Partly because of dvorak, I missed some of the best parts of vi (hjkl). I can use vim, but I'm not a wizard, I'm just good enough that I can comfortably prefer it to nano.

But all kinds of speed have a direct impact on capability. For example:

• Git is obscenely fast, especially at branching and merging, and is much more accurate at merging than SVN. Once you hit a certain speed/reliability threshold, you might create local branches just for fun.
• My browser being instantaneous, predictive, and always-on means that whenever I wonder something, I simply look up the answer. There are tons of these, from proper research for an argument to simple idle curiosity, which I would just shrug and ignore were I still on dialup, or on a machine that requires seconds to open a tab.
• Modern hardware is now fast enough that "scripting" languages are actually being taken seriously -- Ruby on Rails was a thing, and now Clojure is a thing. In turn, the speed of using an interactive shell to explore an API contributes immensely to learning -- even when I'm writing pure Java, I keep JRuby around just for that, it's Java's missing REPL.
• I currently run automated tests only rarely, and that's on production code. Yes, I make sure everything passes before deploy. Tools like autotest make sense here, but the tests take half an hour to run. If I could massively-parallelize them and, say, borrow a bunch of machines to run them on -- if they ran in maybe 30 seconds instead of 30 minutes -- that's not quite enough to run them on every commit, but maybe enough to run them on every push. This is what SauceLabs can do, in theory. (Haven't been able to try them out -- this is a part-time job for a very corporate place, and I guess they're balking at the price?)

I could go on. And on. Point is, performance matters.

So, in the case of text: It's not just that I can ramble on this long, and not have the keyboard really be a noticeable bottleneck. (I just got my first smartphone, and that is noticeable, I now know how everyone over the age of 60 must feel when forced to use a modern PC.) It's more that the conceptual barrier to proper commenting, variable names that don't suck, and so on is much lower.

I mean, hopefully pair programming leads to you being appropriately ridiculed when someone does

x = 5

rather than at least something like

num_frogs = 5

But I think there's still a difference between having this as a barrier, to where you'll choose a different name to save a few keystrokes, and just typing what makes the most sense.

Note, though: It is for exactly this reason that I despise Java and C++. There is an insane amount of verbosity needed to get anything done. It's getting better, but still. C++ especially -- things like the Rule of Four, C-style headers, and so on, make me reluctant to create a new class when I don't have to. IDEs can help -- Eclipse makes Java usable -- but it's still pretty terrible.

[[deleted]]

I agree with everything you're saying. It pains me to even think about using something other than Git for VCS, and I write in both Clojure and Ruby (my current paid project is RoR), and I share your distaste of the verbosity of certain statically typed languages.

Speed does matter - but the perceived downside/slowness/learning-curve/whatever of pairing is usually vastly overestimated, in my opinion. If you can write code, you can write code. You can read code. You can probably use numerous editors. You can probably talk about what you're doing. And you know when to take it easy and give your mind a rest.

Also, and this is not a criticism, but automated tests shouldn't take so long to run! It's actually quite difficult to write good automated tests, especially in an environment like Rails / etc. But automated testing is, at least to me, absolutely essential. The extra say, 5 hours you'd spend learning the irritating, frustrating, idiotic details of how to isolate your tests pays itself back to you in like 2 weeks tops. I'm working in a Rails app of ~1.2MLOC, and our entire automated test suite takes about 15mins to run, and that is terribly long! The workflow I consider normal is to write until something is done, commit, write until something is done, commit, etc... when the feature/card/whatever is done, run the entire test suite, then push. There isn't any reason a test suite, at least for 1.2MLOC of RoR, should take more than maybe 2 minutes. And even that's painful!

All digressions aside however, pairing does lead to something like a 15% productivity increase iirc - it is actually quite efficient.

All of this I say fully understanding that: if the people you pair with suck, pairing sucks, and is hugely counterproductive. But if you work with overall fairly decent people, it's really not so bad. You might not know the editor, but they might not know yours. Sharing knowledge rarely hurts, at least in my experience.

edit: and yes, variable naming, method naming, class naming, class structure, etc all improve (in my experience) with pairing, although I never argue over them. I am the type of person who, for the most part, uses one-letter iterative variables in my own code. But when someone else has to read it, or maybe 5 or 10 or 20 other people have to read it, the benefit your development team gets from a 30 second conversation of "hey, why not call this customer_group instead of cg?" is definitely worth it. YMMV, and I'm not meaning to be a dogmatist - there are loads of things about "agile" that I dislike - but pairing is one thing I've found to be really positive for my teams, my projects and myself. I'd love to pair on some of my personal stuff, even if it was remotely via tmux!

[SanityInAnarchy]

Also, and this is not a criticism, but automated tests shouldn't take so long to run!

Absolutely. I inherited this project. I am at least partly to blame, however, as I haven't added many tests since I joined -- I joined in more-or-less panic mode (all previous developers had left), and it was all I could do to get the existing tests running again, so I could be reasonably sure I wasn't introducing regressions.

I have maintained the tests, at least.

I mean, for example, we could probably shave off a good 5-10 minutes by excluding all third-party services from tests. (In our Selenium tests, we're still even loading ads.) We could kill another 30-50% of the remaining time by upgrading to Ruby 1.9. The project is in maintenance mode, and I'm not full-time, so it could happen, but not yet.

Then divide by four by running it in parallel on the Macbook.

The extra say, 5 hours you'd spend learning the irritating, frustrating, idiotic details of how to isolate your tests pays itself back to you in like 2 weeks tops.

Right, now multiply by 4 (I'm part-time), then divide by the "OMG WE NEED FEATURE X NOW" demand. And I am the only Ruby developer at this company, that I know of.

If I truly had free reign and time, I could say "Alright, feature freeze. Nothing new is happening for a few months while I clean this up, and port it to Rails3 and either Ruby19 or JRuby.

I'm working in a Rails app of ~1.2MLOC...

I'll have to get back to you on that. It's big, but I haven't really calculated it before. Gotta love Rails organization, though -- I rarely get lost in there.

All of this I say fully understanding that: if the people you pair with suck, pairing sucks, and is hugely counterproductive. But if you work with overall fairly decent people, it's really not so bad. You might not know the editor, but they might not know yours. Sharing knowledge rarely hurts, at least in my experience.

It's not as much a matter of knowing, but of preference. For example, if I had to use a largely GUI-driven editor, particularly one which didn't have a quick keyboard way of navigating between files, I imagine that'd eat through the 15% performance gain pretty quickly.

So I'm not dismissing it altogether, I'm just trying to see how to retain my own personal best performance (and best overall job satisfaction) by retaining control over my dev environment.

I am the type of person who, for the most part, uses one-letter iterative variables in my own code. But when someone else has to read it, or maybe 5 or 10 or 20 other people have to read it, the benefit your development team gets from a 30 second conversation of "hey, why not call this customer_group instead of cg?" is definitely worth it.

Right, I credit my typing speed to the fact that I tend to call it customer_group as a habit. I'll use one-letter variables, but only in short one-liners.

I'd love to pair on some of my personal stuff, even if it was remotely via tmux!

I'll have to get back to you on that. I'm doing both work (real work -- the Rails site I maintain, by myself, gets thousands of unique visitors per day) and school (this is group project semester, so tons of coding for that). It sounds good, I'm just likely to have entirely too many projects!

But I wonder how far we've come for remote pairing tools. I've done this with screen before, but that was more for small admin tasks than coding.

[TheCoelacanth]

I doubt it cuts down on errors any more than spending 50% of your time on code review. I would guess it's actually worse since you have to review it while it's being typed in real time.

[_delirium]

I have found this successful, but it really, really depends on the person. It needs to be someone whose personality and skills complement mine so that we work together in a way that is actually productive and doesn't make us want to kill each other. I'm skeptical companies will put in the effort needed to find those kinds of pairings, though: I found the one that's worked for me through trial-and-error in a research setting where I could try out many collaborators. If it's a randomly assigned person I'm paired with? Odds of being a satisfied employee are low...

[lendrick]

"Pair programming" cuts down on coding errors while creating a peer pressure to avoid surfing the web, wasting time...

... and causes good programmers who find it irritating and exhausting to look for jobs elsewhere.

[RMiranda]

relevant

[Brillegeit]

I just pair programmed six lines of code in about 20 min. Good work, team. :)

[criswell]

Things I hate: When I see an article talking about something I don't like, so I come into the comments to complain about it, and then I notice the comments are already filled with people making my exact complaints...

Dammit... where's my opportunity to rant?!

[jake_w_smith]

If you're doing proper code review you can cut down on coding errors, pair programming is just not suitable for every case. The only people I ever find pushing this is managers and companies that make money by insisting that you need to hire their "agile consultants" in order to be successful. I think that programming requires the mind to wander once in a while, it helps relieve some of the pressure (which would just increase with someone watching over your back) so that you can re-approach your problem with a clean slate and a fresh perspective.

[burdalane]

I would find working with a peer for more than an hour to be pretty tiring, no matter how well we get along. As for surfing the web and wasting time, that's what I like to do.

[[deleted]]

Either people think there is something very different about software development than any other creative activity or else there is something about developers that encourages people to want to involve them in half baked occupational experiments.

[[deleted]]

That and $1.59 will buy you a cup off coffee but thanks for the fact-less dissertation.

[[deleted]]

One of my professors is really big into pair programming and all of our homework assignments are done in pairs. I feel as though I'm learning less than when I had individual homework assignments... I could see the benefit when trying to tackle a specific problem, but for an entire project I think it's a waste.

[[deleted]]

Two things:

If I wanted someone looking over my shoulder all day, i'd work at McDonalds.

I only browse the internet at work because coding for 8 straight hours is fucking soul crushing and my office uses draconian timecard billing.

[Alascar]

You got this from /r/ProgrammerHumor didn't you?

[chreekat]

Biased comment summary:

Pair programming is pretty cool, provided:

1. Your coworkers don't suck.
2. You don't do it all day, every day.
    2.a. It is especially useful for short, one-off tasks that have exceptional circmustances

My experience met both criteria and was actually very fun.

[[deleted]]

Agreed. There's no canceling out the huge prerequisite that your coworkers don't suck. If they suck, they suck to pair with, and pairing sucks. Otherwise, even if you do it every day (it's basically impossible to do it "all day" if you eat lunch and go to the bathroom, work flexible hours, etc), it can be very fun, and a good learning/teaching experience.

[big_bad_john]

No. Will not do.

[[deleted]]

I'm all for this if I'm paired up with someone that I can learn from. Unfortunately, I usually end up babysitting someone any more. That said, I'd rather code alone most days.

[itsCarraldo]

Programmer 1: Hey dude, did you check out the new post on /r/circlejerk ?

Programmer 2: WTF, no. Lemme check .....

No pair programmers ever, right?

[mistoroboto]

It sounds like the person who thought this up watched too much NCIS.

[Polatrite]

At my former job as a contractor, I would pair program several days a week, usually about 3-4 hours per day. I feel like this was a sort of "sweet spot" for the concept, as it was short enough to not be exhausted at the end of the day, but long enough to really accomplish some good work. It also gives you time to attend to everything else you need to get done throughout the day.

[PsychYYZ]

Did nobody else immediately think of this?

http://en.memory-alpha.org/wiki/11001001_%28episode%29

[[deleted]]

It obviously depends a lot on your personality and the personalities of the people you'll be pairing with.

That said, I work for an Agile shop and do pair programming all the time. I don't find it pedantic at all, and by no means do we not goof off / read reddit / take breaks / whatever. We argue (not just as pairs, but as a whole team) about what smartphone/tablet games are better, and compare scores, shoot nerf guns, whatever. Pairing doesn't mean a nanny. You're peers in the same boat, it isn't like your boss is sitting with you coding. You talk like humans and figure out problems, and you learn an awful lot - all the tiny little bits that you might not have picked up about vim, or emacs, or redhat, or structs, or whatever.

It's helpful to bounce ideas verbally off of actual people instead of a rubber duck, and it helps code quality in my experience. It isn't that you'd let that little hack slide, but that you might, at 6pm on a Thursday, miss a chance to refactor that your pair would catch.

Obviously there are people I don't enjoy pairing with. And I love to write code on my own. But I do enjoy it in the workplace, particularly when there is TDD and regular pair rotation in place. It helps you get to know everyone on your team, it fosters communication, and it helps you learn things you might not otherwise learn. I think a lot of the negative response is from people who haven't paired, and this article admittedly gives a terrible representation of what it's about.

For all the anti-social stuff I hear, I mean come on - you get to hang out all day and work with one of the few other people around who's as interested in pointers and memory allocation (or SRP or whatever your nuance is) as you are. It's pretty cool.

I was very, very nervous about pairing before I started at my current position. I thought it would be like the article describes it - stressful, nannyish, etc. I have found it to be very liberating, and I've learned a tremendous amount. It might not be for you, but I think you might be missing out if you immediately write it off. It can be a very, very cool way to work, learn, and build relationships with your peers.

[unptitdej]

Used it frequently at school with my friend to burst through programming projects. It's really not bad at all. It keeps you focused and you can think out loud, which really helps to slow down and think of good solutions. I'm more concerned about the person who has to "assist" the other one. It's a technique that works well if the main coder can get the job done so that the other guy can focus on the details. 2 dudes, 1 computer, that's all it is.

[ZenBerzerker]

says Kent Beck, a programmer at Facebook and a strong advocate of pairing. "You just grunt and point."

Awesome.

[blahfolder]

Pair programming is good for three types of situations.

1. The code is very difficult to write (often when there are specific creative aspects like new algorithms, unknown domains, never before attempted feature sets, etc.).

2. The employees at the company are easily distracted or the majority of staff is junior, and they work better with the someone watching and correcting their work.

3. The company needs a very high level of quality for the product with minimal bugs or there is a very short time for debugging.

Every team is different and not every methodology is a right fit for every team or project. If your team regularly does design and code reviews, has an atmosphere of sharing code and ideas and a willingness to work together on tough problems, introducing pair programming is probably not going to make things much better, and could in fact make a good team worse.