I am working in a company where I am forced to do pair programming with a guy 6 years more experienced than me. At the same time we work on the same code, design, or some other problem, on the same pc.
Disadvantage.
This takes away the feeling of ownership of result. Each other's mood starts affecting both.
Advantage.
Good well-thought result and output for company.
I want to know how other developers tackle this type of situation.
You solve the problem very quickly. You probably reduce bugs in the process. What exactly is the problem?
Do you feel like your more experienced partner is dominating the process and taking away your feeling of ownership of the result?
For these reasons, there should be little dogma and mandates about pair programming. I'm personally very much in favor of this practice, but I believe programmers and management should understand the requirement for the "proper chemistry" and there shouldn't be the least bit of resentment or judgment when a pair doesn't work well together.
To be sure, programmers should try this discipline at large and work with specific partners in earnest (for long enough periods, and also for various project types) before declaring personality conflict. It may happen too that a given pair works better on particular project types.
I take it you want to own something, to take responsibility of a module / set of modules and call it your own? It really depends on your project, maybe sitting down with your PL and talk about it would be a good idea. That way he could give some part to take responsibility for, you could still pair program though.
I think the main advantage from your perspective is having the opportunity to learn from someone who is more experienced.
The exception is if your partner is less competent than you, despite having more years of "experience".
In a word - YES!
But I think everybody finds it difficult at first.
Most of the good programmers I know doing XP said "my boss forces me to pair" at first. You're not alone!
The Producer If you want more of a sense of leadership, you can introduce a "story producer" role in the team . Each story has a "producer" - that's the person responsible for making sure that a specific story is fully complete (thought fully through, cleared with the customer, tested, deployed and demoed). Being producer can mean hammering out a substantial chunk of functionality and feeling in charge of something - even if you don't work on it every day in the iteration. Devs sign up to be the producer at the start of the iteration by writing their name on the story card.
There are positives:
Negatives:
I remember wanting to pair program but I still felt a lot of dread in the first few weeks.
To this day, I still feel drained after an intensive day's pairing - far more so than coding alone.
You get used to pairing after a while. Sometimes I find myself wanting to discuss "which way to go" with a design - that's when I miss pairing... I almost turned and asked this granny who was knitting next to me on a train about an object design once! ;-)
Pair Programming, especially when you switch partners often, in the context of an agile team is designed, in part, to enhance collective ownership. This reduces silos of knowledge (said another way: increases your project's "truck number") and reduces the attitude of: "this part of the code is poor, but it's not my problem because I don't own it". On the other hand, agile teams choose as a team to pair program because they believe it works best.
When programmers pair, knowledge, skill, and experience are transferred between team members. This transfer tends to be bi-directional, unless there is a significant mismatch, like in your case. Then it tends to be one-way. That's one of the reasons agile teams switch pairs often.
Forcing a practice on people, even a good practice, is a problem in itself. This tends to be especially bad if you are forcing programmers.
Certainly personalities can cause friction during pair programming. But if people can't work it out maturely, then my view is it's a people problem, not a practice problem. There are still devs that strongly prefer working alone and "owning" parts of a project. It can be difficult to convince them to work otherwise. If it can't be worked out, then it either festers, or someone leaves voluntarily, or someone is let go.
There are a few factors that would impact how I'd answer this:
Is the total dev team just the two of you? If so, then initially this could be a good thing to help get you up to speed and to prevent one of the pair from writing a lot of code without the other knowing anything about it. I'm not sure that I'd want to see the same pair together so much that you ought to be stuck together though.
Are you working on new development or fixing bugs? If new development, then it can be good to have a couple set of eyes looking over the code. On the other hand, fixing bugs isn't necessarily best done through a pair, unless it is a really complicated one.
You could view this as a way to work on practicing how patient you are and how well do you really understand someone else. It can be useful to be so close to someone that you could almost finish their sentences for them.
Where I work we can have pair programming on new features and it generally is a good thing. There are about 7 developers in total in the team so there can be some pairs and some solo work being done. There were even nicknames given to some pairings which helps give the team some cohesion and bonding to my mind. Usually the pair works on a story and when the story is done, the pair breaks up unless there is another story that both want to do. Generally I find it useful to have to explain things and get someone else to see my train or if I'm giving feedback as the other half of the pair has an idea that I get to test out and see how well it'll work.