Constructive Criticism

Question

While peer programing what is the most optimal way to offer constructive criticism?

How do you critique without pointing out flaws?

Answer 1

Instead of focusing on the flaw, focus on the improvement that can be made. Of course, it depends -- it helps a lot to know the person involved. I used to work with a guy who thought it was great when I acted like the most trivial typo was going to destroy the world!

Answer 2

1. Always point out specific suggestion on how to improve, not just what needs improvement.

2. Always point out exact reasons WHY a change offered is beneficial.

3. Preferably, point out how it's beneficial for the reviewed (e.g. saves him time later on)

4. Put shades on criticism. Meaning, "this one point is a must to fix for those N reasons. These 2 places I would strongly recommend changing for those reasons but only if you have a spare hour to redesign. And these 5 points are minor and probably somewhat subjective, so I will give you my POV and let you decide on whether to take my advice"

Same rules as for code reviews, BTW.

Answer 3

Tell them why, not what.

Nobody wants to hear what they're doing wrong, even people with open minds can get tired of that. Rather, people want to know what the possible downfalls are. If X is good, but Y does it better, don't say that. Tell them what X might fail at, and suggest Y as an improvement.

Let them improve themselves, only show them where.

Answer 4

There's a fine line between

Hey, buddy! Perhaps System.exit(1) is not the best way to handle that ParseException?

and

Who the hell names their variable "date37"?

Which is why the optimal way is to not do pair programming :-)

Answer 5

One thing I've found helpful when doing code reviews is instead of saying "You shouldn't do X, you should do Y instead" I'll instead ask "Why did you do X instead of Y?". I find that this tends to put everyone on more equal footing. Rather than the reviewee being in a position of defending their choices, the two of you are evaluating the alternative options together. Sometimes the reviewee has good reasons for doing things differently than you expected (and these are often reasons to add documentation or tests).

Answer 6

I believe if you are going to tell somehow how to improve, that first off they have to want to improve. Otherwise any suggestions will be seen as an insult to them.

So rule number one is to have a company ethic of perfecting their craftsmanship.

This also means that no one is "above the law" so to speak. Suggestions for improved code go both directions, and a mutually beneficial dialogue is created.

It is all about "Why?" Why is one way better than another? Let's discuss, and in the process both improve our skills.

Answer 7

I have also found it helps if you point out that reason why you would consider x vice Y is that you learned the hard way why Y is better. If you can point to having made the same mistake and how changing to Y improved the performance or maintainability or whatever it improves, then it doesn't seem as much a criticism as a sharing of lessons learned. The more painful your learning was, the more someone will see you are trying to help not criticise.