15

Performance reviews have come up recently at my work, and I was put in an interesting position. Our team does a lot of pair programming, which has a tendency of averaging out the skill differences between team members (especially considering we rotate pairs). Generally, when doing performance reviews, you look back at the work you've done, and demonstrate what you've accomplished, and how you've exceeded expectations to try to negotiate a raise or other benefits.

How do you demonstrate (or even measure) individual performance in an environment like this?

Improve this question
2
  • 1
    I would keep track of what I personally worked on. I would give credit when I solved a problem only after talking to my peer.
    – Ramhound
    Commented Jun 21, 2011 at 16:27
  • I don't know the answer... and I know in some workplaces, there are potential problems of one member of the pair trying to take credit for everything. As soon as the second member tries to take credit just for some things honestly, they could become suspect since it's probably not possible that both members deserve all the credit for the pair's accomplishments.
    – FrustratedWithFormsDesigner
    Commented Jun 21, 2011 at 17:15

9 Answers 9

Reset to default
13

include the value you added to the pair programming in the performance review - did you help the other programmer learn useful things? (and vice-versa, did you listen to his/her sage advice and cooperate well?)

a performance review should not be a competition, it should be a coaching evaluation relative to your personal goals (which are presumably in line with the company goals and mutually agreed upon at the beginning of the year; otherwise it's just arbitrary)

Improve this answer
2
  • 3
    +1, but it's probably hard to create a "coaching evaluation relative to your personal goals"-kind of environment when your next salary raise depends on the performance review (as the tag "salary" implies).
    – nikie
    Commented Jun 21, 2011 at 17:13
  • 1
    @nikie: at many of the places I once worked, personal goals were discussed at the beginning of the year, and the performance review was done at the end of the year relative to those goals. At many more of the places I once worked, performance reviews were done without your input at all. At some of the places I once worked, performance reviews were repeatedly promised but never done at all. At once place I was told to fill out my own performance review paperwork because management was 'too busy'!
    – Steven A. Lowe
    Commented Jun 21, 2011 at 17:39
2

It would be hard to definitively prove one performance benefit over the other scientifically.

Your hypothesis is that pair programming increases developer performance and improves quality. Your test will involve giving a pair a set of requirements constrained to a specific architecturen and having them implement it.

Your control in this case is that you give the same requirements to a single developer of equal standing, skill and experience (as judged objectively by his peers) and also constrained within the same architecture.

To verify your hypothesis of time performance, the pair programmers must complete their work in less than half the time as the control. To verify your hypothesis on quality you must have the experiment pair and the control code reviewed by an objective third party, and have an objective QA group test the results of both groups without telling them which team produced what. The pair programming group must have better code and less bugs.

It is not a perfect experiment but I would be fascinated to hear if anybody has attempted something similar.

Besides this however I can't see how you can factually prove that Pair Programming is superior to a single programmer on a given feature.

Improve this answer
3
  • Interesting experiment, but I am not asking to compare individual performance vs pair-programming; I am asking in a pair-programming environment, how do you measure the impact of an individual?
    – NT3RP
    Commented Jun 21, 2011 at 17:07
  • 1
    Perhaps it is just a bad metric then in your case? If the company primarily utilizes pair programming then from a managers perspective the ability to accurately determine the impact of a specific programmer is severely diminished. I can see how an annual performance review that is done fairly can be difficult.
    – maple_shaft ♦
    Commented Jun 21, 2011 at 17:25
  • I agree that it is probably a bad metric, but unfortunately we have to live with it :)
    – NT3RP
    Commented Jun 21, 2011 at 19:07
2

In your performance metrics, call out separately 1) individual growth and development, and 2) mentorship and peer support. Allow each employee to self-evaluate, and incorporate their lead's feedback. If it makes sense in your company culture, consider peer reviews or testimonials.

If done correctly, the employee who is getting the most educational value out of a pairing gets rewarded for their long term ability to contribute to the team, and the employee who is helping bring them up to speed gets rewarded for transferring knowledge and experience. People who are somewhere in the middle (learning new domains instead of just moving from junior to senior) get recognized for both ends of the equation.

In practice, rating individual performance is tricky in the best case. It's pretty hard to do it without creating some feelings of resentment or competition. But if you rate the individual contribution to the team and you value both learning and teaching, there's some chance of making it work with somewhat less friction.

Improve this answer
2

Are the pairs switching often? If so, you could use anonymous reviews to come up with a gauge. For example, if person A said that B did 60% of the work, person C said person B did 30% of the work, and person D said person B did 90% of the work, you could average that out to person B doing 60% of the work. If the work that person B accomplished in his pairs has a relative factor of 100 points, then person B did 60 points worth of work!

However, this isn't (anywhere near) perfect. People are likely to give themselves more credit than they give the other person, so you may need to take this into account in the calculation. This could also lead to an environment where the pairs are suspicious of one another. The calculation may also be shifted by someone not liking the person they're working with, etc.

Improve this answer
1

I say if two of us worked together to create X, then both of us get credit for having finished and deployed it. Where you might have an issue is when one part of a pair did not work at all. In this case, the manager should have been informed about this all along and thus should use that feedback when filling out his comment to the performance review.

Improve this answer
1

You are in the exact situation that my teacher puts us students through in our Game Development curriculum. We are paired off (2, 3, or 4 people depending on the class size and the project size) and at the end we are told to evaluate each individual team member and ourselves in relation to the project and what work was done as well as the other teams' projects as a whole. A grade is formulated based on these evaluations.

During team formulation the teacher would deliberately place a strong programmer and a weak programmer together hoping they would work off each other and/or help but 99% of the time the weak programmer would skate by and do very little work to none at all or have no clue as to what they are doing (This being the advanced courses, it is very frustrating).

The evaluations are supposed to be private, but lets just say, there are a few people that everyone refuses to work with anymore.

Improve this answer
1

Pair programming means that one person thinks what and how something should be done, and the other plays a coding monkey. Then at some point they switch (one gets bored, tired, etc). It is good, because both are not interrupted at their activities.

Some people also consider it as "the code review on steroids". You get reviewed code, which should mean higher quality.

Improve this answer
1

Nice question. What is important is not merely what you contribute, but how your peers see your contribution. Ask them for their candid feedback for it is this feedback that helps you be a better 'whatever'. Seriously, it is important that your peer understands your contribution and they understand it only when they have fair deal of learnings while pairing with you. Happy coding, sharing, and learning thus resulting in good earning.

Improve this answer
0

The disadvantage of pair programming is that the more experienced programmer productivity is restricted to the least experienced programmer productivity, for short, medium term. For long term, the experienced and productivity is increased in the junior developer.

Improve this answer

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.