I have been offered an interesting job, but there's a big caveat for me: they use pair programming.

I hate the idea of pair programming, and I'm probably not suited for it: I like to do frequent pauses, I hate to see someone programming (I would constantly poke the pair away to code myself), I have to be in full control of the machine I'm working on, I like to work listening music, and basically I don't like to being tied to someone else. I'm not even a social person.

I have however never actually worked with true pair programming (besides few times for a short time to help someone else or to solve a complex task together)... so it is pair programming really that bad? And given my attitude, should I refuse the job or should I leave my current one and give a try?

For people that asked about it: I'm looking for a job where formal design and development are used, as I hate my current job where we are "coding in the wild". The company is very interested in my technical profile so they insisted even when I specified I never worked with pair programming and that I probably wouldn't like it (besides being an unsociable loner programmer, I don't like and believe the very concept of pair programming).

  • 8
    Well, you personally don't sound even a little keen on it, so I don't think you should do it unless you want to give it the old college try. – Paul Nathan Sep 28 '10 at 16:40
  • 1
    I find a compromise between total pair programming and solo programming is a nice mix. You get the benefit of a second set of eyes but also get some space and room to breath the other half of the time. – Chris Sep 28 '10 at 18:28
  • ITs usefull when you are new to that coding language ... you can get help right away .. you dont need to wait for ppl to reply On SO :P – GoodSp33d Sep 29 '10 at 5:28
  • 5
    @Lorenzo, what did you decide in the end, and how did it turn out? – Benjol Aug 9 '11 at 11:42
  • 5
    @Benjol: I've tried for a few weeks (I was able to keep my existing job in standby in the meantime) and then I realized that I really hate pair programming, so I went back to my old job. – Wizard79 Nov 15 '11 at 10:23

11 Answers 11


Based on your various comments here, you seem to to have a similar outlook/disposition to myself on the subject. And I have experienced "Pair Programming". And I certainly wouldn't join a company that required me to bite a scorpion. :)

What I'd recommend is: Go with your gut.

If the company would force you to do Pair Programming and you know you don't want to, don't join.

If they'll give you the opportunity to show that you can produce better work faster than any two of their current developers combined, go ahead and prove it.

Before you decide for definite though, I'd certainly agree with the recommendation that you ask to talk to the existing developers there, and get a feel for them as people. (I'd probably recommend that for any new job, regardless of the methodologies used.)

|improve this answer|||||

Guess what - nobody likes pair programming at first.

When I first tried pair programming I was against the idea and I had tons of objections similar to yours. I don't like to watch someone else coding, I like to listen to music, I feel I'll be quicker working on my own, I don't want to stop and explain myself constantly, etc etc etc.

Then I tried it. And guess what? It still sucked. We were having all kinds of problems - I wanted to work different hours to the other guy, we had different keyboard settings and shortcuts, our desks didn't work very well for pair programming etc etc.

This went on for about a week. During that week we were rewriting the entire legacy login system for a distributed application. We had to learn how some seriously difficult threading issues work, figure out how remoting sinks worked, change tons and tons of legacy code to work with our new login module and pretty much do some of the most hectic coding I've had to do in my career. After a week of this we deployed it.. and everything just worked. Not a single bug. Not one.

That's when I figured there might be something to this pair programming nonsense. We started to do more pair programming. We even started to force everyone to work in pairs. It rocked. I probably learnt more in a month of doing that than I did in the previous 2 years. The other issues didn't go away. Sometimes you'll be stuck with a pair that you dislike. It's gonna happen. Sometimes you'll struggle to find overlapping working hours. Sometimes you'll want to just work on your own. But the advantages of pair programming are just incredible.

Since then I've always tried to do as much pair programming as possible. It's simply the best way of learning. This company forces everyone to do pair programming? Where do I sign up? It seems to me they are really enlightened and you will be in a really intense working environment. Awesome.

Having said that, make sure that the pairs are rotated often. You don't want to be stuck developing with one other developer for months on end - you'll go out of your mind. We're all human, after all. Also, check that this has been an ongoing practice for a while. If it's not, it's not the end of the world, but if it's an accepted practice it's a massive green light.

Trust me, you want to work for a company like that.

|improve this answer|||||
  • 5
    I would suggest that the OP will only succeed at a company like this if he's open to learning that he's not actually as good at programming as he thinks he is, and then comes around to wanting to learn how to get better. – dash-tom-bang Sep 29 '10 at 1:29
  • 5
    They basically told me your same exact story. People there were very supportive and I acknowledge that coding that way rocks - and improves your skills. But that was driving me crazy. I couldn't live with all the limitations to my "personal freedom" and "living space" (choosing the timing, listening to music, keyboard configuration, color scheme in the IDE etc.), so after few weeks I give up. – Wizard79 Nov 15 '11 at 10:32
  • 6
    "After a week of this we deployed it.. and everything just worked. Not a single bug. Not one.": I haven't experienced a significant difference in number of bugs between using pair-programming and not using it. Discussing the essential points with your colleagues and then coding on your own can be as effective. Pair-programming is no silver bullet. – Giorgio Dec 18 '14 at 11:34
  • I recently completed my first project using pair programming with a more senior developer in the team. We shared the piloting and co-piloting of complex tasks fairly evenly and we both learned a few things from each other. We did split for trivial, mundane or "boiler-plate" tasks. – Dib Jul 13 '16 at 12:35
  • 2
    "Guess what - nobody likes pair programming at first.": Guess what - I did not like it after doing it for two years on a row. I left that company and in my new company / team nobody wants to do pair programming and we are all very happy and much more productive. In my experience, pair programming is only good for training beginners, for micromanaging, or for people who are not able to work on their own. – Giorgio Dec 10 '17 at 9:01

Pair programming is a great tool! It can be way more efficient – two heads are better than one – and a great way to learn new techniques. Of course, there are other benefits too. But, if you are not buying into it, then you won’t get anything out of it. Given your attitude, it sounds like you would not fit into it at all and it would probably be a waste of time. It looks like your mind is already made up before you even give it a shot.

|improve this answer|||||
  • 7
    Two heads are also twice as expensive, and that's the big downside =) But this concerns the company not you – Thomas Bonini Sep 28 '10 at 18:21
  • 7
    -1 Is pair programming great? It is the worst thing ever happened in my working life! – Wizard Sep 28 '10 at 18:48
  • 4
    Pair programming should be used on difficult tasks. That's when you're saving money and time. Otherwise it's kind of a waste. I like it though. – Joe Phillips Sep 28 '10 at 21:15
  • 3
    I think it should also be used as a mentoring tool for "greenhorns" to help them until they get the hang of real-world coding. – Muad'Dib Sep 28 '10 at 22:45
  • 3
    @Kop: I disagree. The goal of pair programming is precisely that two heads together create better software than the same two heads each on their own, while begin just as expensive. (That is, of course, if you aren't reaching that goal, then it is not worth it). – Sergio Acosta Sep 28 '10 at 23:09

Let's look at this from another POV: given your predisposition, you're likely doing a disservice to the employer. They certainly don't want to hire someone who "hates" one of their development practices. Have you informed them of your perspective given such a tight-collaborative environment? If not, you're potentially misrepresenting yourself.

As an employer, I would be pretty frustrated to hire someone who knew, coming in, that they wouldn't be happy with the development practices we had put into place. It's a recipe for discontentment and frustration for everyone involved.

Edit Given that they understand where you're coming from (and are willing to take you on, as you mentioned in your comment), why not discuss how you feel with a few developers in the company? It's possible they'll be able to address any concerns or biases you have against PP. It's also important for them to know you're not terribly keen on the idea since you'll be working with them full-time.

It will also give you an opportunity to learn something about the people you'll be working with so closely.

If everyone is on board, I would certainly advocate PP for the same reasons mentioned in the answers here. You have immediate accountability for what you're writing; another set of eyes on your code will likely catch defects or trouble-spots you might otherwise miss; you get great exposure to someone else's perspective on coding (and get to provide your own experience); and the end result is very often much better than you would expect.

I appreciate your bias against PP; there are times I want nothing more than to sit at a computer banging away at a problem, and PP gets frustrating (I'm also an introvert, which means PP leaves me feeling a bit more drained at the end of the day) because someone is always there. This said, the results, in my experience, speak for themselves and I'm much more amicable to it on a regular basis.

|improve this answer|||||
  • I talked about it to the employer, and they asked me to try. – Wizard79 Sep 28 '10 at 18:28
  • 2
    @Lorenzo, fantastic. It's so important to accurately represent yourself to an employer, and if they're willing to let you give it a try, then it's something to consider. – bedwyr Sep 28 '10 at 18:34
  • that's why I don't have already refused the job, however leaving the current job for something I probably will not like scares me a lot... – Wizard79 Sep 28 '10 at 18:37

I tried pair programming and hated it. I share almost all the doubts and concerns you have expressed against it. I resigned for this very reason.

My personal advice is always against pair, and given your attitude I strongly advice you to not even give it a try.

|improve this answer|||||
  • 5
    +1 for honesty. :) It's not for everyone, indeed. – dash-tom-bang Sep 29 '10 at 1:31
  • 2
    @Wizard: Some people like pair programming, I don't. I prefer to discuss the structure of the code in advance, then do the coding, then do a code review. This puts a filter between myself and my colleagues so that we only exchange relevant information. – Giorgio Dec 18 '14 at 11:43
  • 1
    @Wizard: I find with pair programming you discuss too many insignificant details: there is a lot of noise that slows down your train of thoughts and makes you less efficient. Other people find it stimulating and like the unstructured but continuous feedback they get. Some people say I am an individualist, I object that you can work as a team and still be structured, in the same way as a soccer team occupy the whole playground instead of going all where the ball is. Anyway, I think it is a matter of how each programmer works and not all programmers work in the same way. – Giorgio Dec 18 '14 at 11:45

You sound like you are definitely not psyched to do pair programming, but the fact that you asked the question would lead me to believe that you're keeping an open mind to it.

Why not be up-front with the employer and let him know how you feel. If they still think you are the candidate that they want then you could suggest a 2 week trial (or whatever time period works) to see if your intial feeling are valid or not. If the employer declines, it doesn't sound like you really wanted the job to begin with so it's no great loss. If the employer agrees then you will at least know definitively one way or the other for the next job.

|improve this answer|||||
  • 1
    Yes, however the problem is that I have a full time permanent job in the biggest Italian company, so I wouldn't leave that job "just for a try" even if the current job sucks... – Wizard79 Sep 28 '10 at 18:33
  • 3
    No, I wouldn't want to do that either. – Walter Sep 28 '10 at 21:43

I recently went to a pair-programming code retreat. I don't use it at work and am very new to it. I am like you in the sense that I like to have control of my own machine. Several programmers who pair-program a lot kept stressing that pair-programming significantly improves one's coding skills because you get constant feedback, your code is being consistently reviewed, and you are less likely to write hacky code. I agree with the fact that it is a significant change for someone who has never pair-programmed before. However, it is hard to have a strong opinion on the matter unless you try it for an extended period of time.

|improve this answer|||||
  • 2
    When I have to assist a coworker, or even to stay next to him for a couple of minutes, I have to keep my mouth close, otherwise I would start criticizing every single line of code... – Wizard79 Sep 28 '10 at 18:30
  • @Lorenzo so you're ok giving criticism but not receiving it? – dash-tom-bang Sep 29 '10 at 1:30
  • @dash-tom-bang: actually I just avoid giving criticism at all, or I would criticize every line of code... – Wizard79 Sep 29 '10 at 8:05
  • 2
    If yielding to your criticisms would make the code substantially better, you should give them. If your criticisms' suggestions make no positive impact then you should figure out why you feel compelled to make them. – dash-tom-bang Sep 29 '10 at 18:06

I hate the idea of pair programming


I never actually worked with pair programming

You must clarify that first.

You can't say you dislike something without trying it. I personnaly disliked tomato sauce until I actually tasted it.

|improve this answer|||||
  • 2
    Tomato sauce is just tomato soup without the spices... Or ketchup without the sugar and vinegar. :) – greyfade Sep 28 '10 at 17:43
  • 5
    I never tried it but I know the idea and concept of pair programming and don't like it. You don't really have to be bitten by a scorpion to know you'll not like it! – Wizard79 Sep 28 '10 at 18:44
  • 1
    How do you know that? You might love being bitten by a scorpion! ;) – Peter Boughton Sep 28 '10 at 18:55
  • I sure you all understood the message – user2567 Sep 28 '10 at 18:56
  • 2
    Pierre, there's a difference between understanding and agreement, and just because you incorrectly extrapolated how tomato sauce tasted doesn't mean Lorenzo is doing the same with Pair Programming. :P Sure, he might be, it might be solely down to the people he's worked with that he feels the way he does, but it's certainly possible to determine if that's the case without actually experiencing 'true' pair programming. – Peter Boughton Sep 28 '10 at 19:26

I'm somewhat germophobic. I hate the idea of anyone touching my mouse and keyboard. I hate the idea of touching someone else's mouse and keyboard. I take the long way around the perimeter of the office complex rather than going through the courtyard to get to the cafeteria just so I won't have to touch any door handles.

On the other hand, I like the concept of programming in pairs. I might learn something interesting. Or I might instruct. Either way, it would be a good experience.

My proposal (for myself): do pair programming from a distance. Use Office Live Meeting and share your screen. Dude stays at his desk, I stay at mine.

|improve this answer|||||
  • Why not just bring your own mouse and keyboard? Or leave two hooked up to the same machine? – Alex Feinman Sep 28 '10 at 16:47
  • 1
    @Alex, possibly. But I generally feel the entire workspace has been contaminated. Don't ask me why. If you could explain insanity, it wouldn't be insane. – Anthony Pegram Sep 28 '10 at 16:49
  • 3
    Reaaaaaly long USB cables? :) – Alex Feinman Sep 28 '10 at 16:53
  • 1
    But this still requires two people being constantly in sync, something I really don't like. – Wizard79 Sep 28 '10 at 18:31

Is there any way you can do some pair programming independently, to get a better feel for it? There seem to be people who like pair programming, and people who don't, and before committing to a job that uses pair programming you really do want to have the feeling you can do it.

Alternately, you can talk to the hiring manager, or somebody in a similar position, and talk this over. They may have use for a non-pair-programmer. They may have experience with people who feel negative about pair programming. Tell the manager why you're uncomfortable with pair programming, but emphasize that you have no experience and are very interested in the job.

Right now, you're in the best possible negotiating position with the company: they've offered, and you haven't accepted yet. The company has an interest in hiring you, and is very unlikely to drop you just because you need to talk to somebody in the company first.

|improve this answer|||||

If you already know the technology, you will hate it. But if you don't know the technology, you will learn it by PP. If you don't know it and you don't do PP, then you will just sit there and not get anything done.

The worst case possible is if both parties know it and it turns into a race or a pissing contest.

|improve this answer|||||
  • 2
    Hi oregon111, it's great that you're trying to answer questions, but you've picked a bad tag to answer questions in: the [jobs] tag generally contains a lot of bad questions that we haven't gotten around to closing yet. Rather than trying to answer long-dead questions in a specific tag, consider looking at the newest questions coming in and seeing which of those you can answer. – user8 Sep 28 '11 at 8:05

Not the answer you're looking for? Browse other questions tagged or ask your own question.