I am a mid-level developer and leading a project at my company. I am very strongly encouraged to pair with another dev who is relatively new (half a year now). He is a good guy, but working with him can be very slow. When we pair everything takes about 3 times longer. If I split a large task into smaller bits so that we can work in parallel and ask him to do one of them, usually an easier one, he ends up taking way too long, and I end up helping him again.

Now to be clear, I'm not opposed to pair programming. I realise that it's ok to be slower for a bit if it means bringing a new dev up to speed. But it's been some time now, and it's not getting much better. I am struggling however to bring it up to my boss because I can't quite find the words that won't sound arrogant. I don't want to shoot the guy down, I actually quite like him, and I know my boss thinks he has good potential. So if I say plainly "This guy is slowing me down quite a bit", I know it won't come across well.

I know it's not strictly my job to train the guy. In fact, I'm not even officially leading the project (it just kind of happened that I'm de facto leading it), so I can't even say to my boss "my project is failing because of this guy". But I want to do the right thing, not just the minimum required thing. And the fact is, I need to address it one way or another, I want to finish the project soon + I'll start looking bad because of the delays. I want to do it in a nice way to not offend the dude and not to come off arrogant. Please help me find the right words.

  • I'm not an expert in pair programming, but my understanding is that in pair programming you are both at the same computer, with only one of you typing. The "working in parallel" makes it sound like that is not what you are doing. What exactly does "pair programming" mean in this situation? – Jim Clay Apr 24 at 18:21
  • 2
    By the way, do you have enough information already to determine whether it’s a skill problem (incompetent) or will problem (irresponsible)? Because that’s what your manager probably needs as the starting point to frame the conversation with your colleague accordingly. – Fleischpflanzerl Apr 24 at 18:42
  • he ends up taking way too long - Compared to what or who? What is the benchmark? Who created the benchmark? Who quantifies what is slow or fast? As it stands, that statement is completely subjective. – joeqwerty Apr 24 at 20:38

You're starting with the right foot by searching for the best way to deal with the situation rather than letting the problem blow up.

Now, as any other work where more than one person is involved, the key is:

Ask for the current perception

It's useful to double check that your concern is also perceived, even at different levels, from your manager and from your peer. Listen is very important. Put yourself on other's shoes. Once you understand their opinions, you can move into the next step

Set expectations

You have to be candid with your peers. Considering what your manager and your peer told you, explain them your perception. The SARAH technique might be helpful to be considered here.

Once you have talked to both, you have to set expectations on what can be achieved. Autonomy to deliver a specific piece of code within a given time under a specific accepted quality. It should be minimally clear but don't over engineer it. Evolve as the time goes by.

Track expectations

Now that you have set the expectations, you can present specific results of your exercise. You will have evidences of the performance (or lack of) evolution during the period. From this point onwards, any action (pushing harder, more training or even let the peer go) will be clearer.

YMMV. As a side note, good to take a look on suggestions on how to properly promote the sustainable usage of peer programming.

For reference, SARAH feedback model:

enter image description here


I dont think that this is about finding the right words but instead the right solution with your manager.

I think it is perfectly OK, responsible even, to say "This guy is slowing me down quite a bit" as long as you follow it up with something like "I want this person to succeed and I am happy to help them but the project will fail at the current pace... should we change the project timeline? Should I focus on my work for the next few weeks to get the project done and shift back to paired programming once the project schedule allows it?"

It is extremely common that new and junior developers are going to have a negative effect on the team's productivity while they get up to speed so there is nothing wrong with acknowledging that fact and adjusting for it. Your manager should understand this but may not be focused too hard on it because you have remained silent about it.

If this developer does have potential like you think then they should be able to understand "The next couple of weeks are crunch time for me, would you mind if we pick this up after that? Our shared manager said it was OK"..

Your Answer

