2

I know two very good developers. They are capable of solving any kind of problem and explaining how they came to the solution and how it works. They are also very receptive to observations after they show their idea. But they prefer to work alone and get immersed in their own thoughts the rest of the time.

And now they are part of a team which applies Pair Programming almost all the time.

The effect of Pair Programming is not being very favorable for these 2 developers.

I have noticed that they cannot get a very good solution when someone is telling them "let's move this to here", "let's don't forget to...", "oh! you should not use camel casing there", "what if we do this instead?". Usually, when they receive such comments, it seems like they're thinking on something more important (and they probably are) and their mood goes down with every comment.

One of them has asked to leave the team because he doesn't feel appreciated, and, in his own words:

  • He can't concentrate well enough during pair programming
  • He feels that his teammates just want to talk loudly about any silly idea without enough analysis
  • He feels that the "loud talkers" will always introduce their ideas, no matter how bad they are

I'm afraid that it will happen with the other developer as well. I know, "nobody is indispensable", but these 2 developers have delivered important amounts of well-done-features in the past, much more than others in the team.

I have seen this happening in other companies as well, but this is the first time that I can see closely the situation both before and after.

So I'm curious about others' experiences and how to deal with this.

4
  • Do you have dedicated driver/navigator roles for pairing? Do these developers both drive and navigate? Do the complaints come when these devs are driving, navigating, or both?
    – Sarov
    Commented Oct 20, 2021 at 18:41
  • I have not introduced officially these roles. They usually drive, but I have seen that they also don't enjoy to navigate
    – zameb
    Commented Oct 20, 2021 at 18:51
  • 2
    There's your problem. They shouldn't be driving with junior navigators.
    – Sarov
    Commented Oct 20, 2021 at 18:52
  • I have to try, thanks for advice.
    – zameb
    Commented Oct 20, 2021 at 18:55

3 Answers 3

7

You have the seniors driving with junior navigators.

And therein lies your problem.

Pair programming works best when the more senior developer is navigating and the less senior developer is driving.

That is, the junior dev is the only one with a keyboard+mouse connected to the code. The junior is the one writing the actual code. The senior is the one assisting, guiding ion architectural decisions, looking up information, etc.

In this way, the junior developer gets better, which is one of the primary purposes of pair programming.

Thus, I suggest a two-fold solution:

  1. When you pair a senior dev with a junior dev, make sure they both understand that the junior's job is to write code and learn, and the senior's job is to guide and teach.
  2. You give your senior devs time to drive without a junior navigator. This means either pairing your seniors with each other and having them occasionally switch roles, or else let them write code without pairing.

The first is so that your juniors can learn. The second is so that your seniors can actually get stuff done sometimes. Do not try to combine the two at the same time. And make sure everyone understands this.

The important part is to make sure your senior devs understand that when they are pairing with a junior dev, their job is to teach, not to write code. This way they can mentally separate the time when they are teaching (and thus focusing on teaching, and thus should not be thinking about 'more important' things in the first place, and thus won't get annoyed at being interrupted) and the time when they are developing (when they won't get interrupted (except maybe by another senior dev who is navigating for them and pointing out something important)).

3
  • Probably your answer has an error?: "senior developer is navigating and the less senior developer is navigating" (both navigating)
    – zameb
    Commented Oct 20, 2021 at 18:55
  • 1
    @zameb Whoops. Fixed.
    – Sarov
    Commented Oct 20, 2021 at 18:56
  • 1
    Excellent advise, I had the idea that "everyone is exactly the same" when PP is applied. Nice to know these roles can help
    – zameb
    Commented Oct 20, 2021 at 19:00
1

I strongly agree with Sarov. "Pair programming" really is just: "work together." But the "pairs" have to figure out just what that means. And you, as their manager, need to give them some guidance as to just what you want to get out of the arrangement. Software isn't written by a committee, but everyone can always "use some help." There is no cookbook here.

1

a team which applies Pair Programming almost all the time

My, what a horrible waste of good time. Pair Programming is a tool. An incredible useful tool. But a tool. Not a life philosophy.

Just imagine you had a construction company and a jackhammer. An incredible useful tool. How does "we apply the jackhammer almost all the time" sound? Probably like a seriously messed up construction, certainly like a noisy, headache inducing workplace you don't want to be around.

Pair Programming is a tool. Use it like a tool. When it's neccessary. And not more.

2
  • Yes, I am strugling trying to understand when is fine and when is too much. Everything is vague when you need more precise information. At least some fuzzy logic like "no more than X% of your time" would be fine. Pair programming is good to raise the quality, to get better solutions, to train the less experiences. For the "propaganda", it only has positive statements, but when something fails, it's because you have used too much of it or similar reasons.
    – zameb
    Commented Oct 21, 2021 at 21:35
  • 1
    Pair programming is good for learning. There can only be so much time devoted to learning new things until your brain shuts down. There is a reason even kids in school don't learn news things every day. It's a lot of repetition and practice. So... I don't know how much learning people need and how much teaching they can do. That depends on the individual. But your individuals are telling you it's way too much for them. So scale it down. A lot.
    – nvoigt
    Commented Oct 23, 2021 at 7:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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