How to overcome the emotional drawbacks of Pair Programming?

Question

Actually I have never tried pair-programming. Once offered, but I was not comfortable enough to give a try. My obstacle was not having the same speed with the partner -I am deep and slow thinker-, the feeling of boundaries and for sure the fear of being criticized in a sarcastic way from a partner who has much more experience than me. Even the idea of someone watching me coding is making me nervous, to be honest, like losing my privacy.

On the other hand, I can understand that this method can really bring many benefits.

I would like to ask you guys who pair-programmed if you have similar cases and how you overcame that?

Thanks!

Answer 1

I actually had this once when I joined the company. The senior guy was helping me to accomplish a task with their framework that was very new for me. It did help a lot. I do not remember feeling anything since we were focused on the code base and not on generic programming skills (which were no issues in my case).

I can't say for anybody but you should probably try not to take the work coding personally. Think of it this way: regardless of how you write your code, it will first be corrected by your partner to fit in the internal code policies, so you probably can't make it right straight away. Knowing this, ignore any feelings.

P.S. Yesterday I was watching Star Trek again. Tuvok was teaching Kim the Tahan Sahat technique - the intellectual deconstruction of emotional patterns.

To see through an emotional context is to rob it of its power

Not sure if it works but give it a try. :)

Answer 2

My obstacle was not having the same speed with the partner -I am deep and slow thinker-, the feeling of boundaries and for sure the fear of being criticized in a sarcastic way from a partner who has much more experience than me. Even the idea of someone watching me coding is making me nervous, to be honest, like losing my privacy.

It's okay to be weirded out slightly the first time. Pair programming is different from the way that a lot of people learned how to develop, and humans are always innately wary of things that are different.

That said, I don't think you should feel like you're getting criticized -- if you do, there's probably something at fault with either (a) your understanding of the goals of pair programming or (b) the personality of the person working with you.

The whole point of pair programming is to learn from each other. For instance, you say you're a slow and deliberate thinker, so it might be worth it to pair you with someone who works a little bit faster but perhaps charges ahead without thinking about all the possibilities. That way, when it's your turn to observe, you can ask if they've thought about special cases that they might otherwise have missed.

Answer 3

I know what you mean.

It is nothing to be ashamed of and you shouldn't feel that your code has a lower value than the other person's. Try to learn from the person (programmer). If the person is reasonable (most programmers are) they will see that you are trying your best and give you points and tips that will broaden your knowledge further. In the end you will be more experienced and more confident in writing and implementing your own ideas as you see them.

Take what you can from the pair-programming. Don't be afraid to ask questions even if they don't comply with the project. Learn from the pair-programming as much as you can, it will make you a better programmer in the end.

Answer 4

I've done a lot of pair programming but I'm probably not much use as I never really had an option not to like you did. In my first job we had to pair program, everyone in our team did. I was a recent graduate and quite quick to learn but I still had trouble sometimes at first. But it was the pair programming that helped me along and made me feel more comfortable that what I was doing was correct. And after a while I realized that the more experienced guys were the ones I wanted to pair with most, not avoid, as I could learn the most from them.

You have to realize your own limitations, those experienced guys will know you are less experienced, they're not going to punish you for it. I would say forget your worries and dive straight in. But don't behave as if you're under test, you're not. Be easygoing, ask about things you don't understand, and be prepared to accept you are wrong sometimes. Now as a more senior developer, there is nothing more annoying than pairing with someone who is afraid of being wrong - it just becomes really awkward. I did some pair programming interviews (which were actually tests!) but the worst guys weren't the ones who used Google for everything, asked me loads of questions, or said 'I need to think this through a bit'. Those guys got on quite well. The worst guys were the ones who sat there and suffered. The ones who thought they should know stuff so shouldn't Google it or the ones who panicked when they couldn't understand stuff at first shot and just went really nervous and kept saying 'Um' and 'er'.

Your ability to think deeply about things will probably be an asset in pair programming - thinking about upcoming problems as your pair solves the immediate one, or coming up with a better thought-through solutions, seeing extra edge-cases your pair didn't etc..

Answer 5

Odds are that your company will also have some kind of code review process, whether it is handled as part of pair programming or some kind of walkthrough/inspection. Other people looking over and editing your code is pretty much a way of life, and what another commenter said about not taking suggestions personally is spot on. That said, as developers we have a very strong sense of ownership for the code that we write, so it often takes time to overcome feelings of being judged by colleagues. It is important to see the forest from the trees and realize that it is the overall product quality that matters, and that's why we do things like pair programming and code walkthroughs.

Answer 6

Personally I think pair programming isn't the most optimal solution, or rather, I prefer doing it a different way. Especially if having someone watching over your shoulder while working makes you nervous like it does me.

A really good way to do pair programming is to do frequent code-revisions together. You can stille ach have your own privacy and work at the pace you l8ike. But the benefits of pair programming are still there - two pairs of eyes on the same code.

Answer 7

We learn new skills and techniques everyday. It isn't reasonable to believe that you should know everything there is to know about writing software. We all make mistakes too.

With that in mind, having someone else offer their perspective on your code and design should help you learn and fill in the gaps in your knowledge.

That said sometimes developers try to use pair programming sessions to show the other person how great they are - pair programming is not about your ego - it is about working together productively towards the goal of creating value for your business.

If anyone is ever sarcastic about your code during a pair session then they are definitely approaching it with the wrong attitude.

As for being a slow thinker - you can use bring this skill to the pair whilst you are in the navigator role - however you will need to learn to verbalise some of your thinking - this is something I personally have had to learn.

Answer 8

Chances are that the other developer has similar concerns - generally we all know we're not as good as we would like - and they could learn from you. If you're a deep thinker, then you have definitely got something to offer a more impulsive developer who may take the first approach that passes the unit test without considering the best way first.

Answer 9

If you have to do it, just do it. don't make it a drama, you'll learn something.
I'm not agree at all with this methodology, but every time one should give a chance to it. Your experience will vary depending on who is your pair.

Answer 10

At my workplace we've talked about doing code reviews and pair programming has come up before, but it's always just talk and we never do these things to my chagrin (particularly on the code review front). Having said that, I would be nervous in the even we started doing these things. Sometimes it feels like my boss is being overly critical, even when I know he's trying to communicate "this is a better way to do something". Part of that is on me, but part of is his style.

Answer 11

Try the Test Driven Development approach to pair programming. Flip a coin. Heads you are the coder, tails you are the tester.

For each method/function you write, the "tester" writes another method to test it, and the coder's method must pass the test. As a by product you have a kick-ass test suite/specification to help you document and maintain the code as you go.

Also, with this way of pair programming you aren't "looking over each other's shoulder". Just sitting side by side. Of course if one of you gets stuck it is perfectly fine to ask the other person questions when you have them.