Clever Geek Handbook

Best Approach to Constructive Criticism During Pair Programming

While para programming is the best way to offer constructive criticism?

How do you criticize without pointing out flaws?

+2


source to share


7 replies


Tell them why, not what.

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



Let them improve, just show them where.

+11


source


One thing I found helpful when looking at the code, instead of saying, "You shouldn't do X, you should do Y instead." Instead, I'll ask, "Why did you do X instead of Y?" I find this tends to put everyone on an equal footing. Rather than the reviewer being able to defend his choice, you both evaluate alternatives together. Sometimes the reviewer has good reasons for doing something differently than you expected (and this is often the reason for adding documentation or tests).



+4


source


Instead of focusing on a disadvantage, focus on the improvement that can be made. Of course it depends - it helps a lot of the knowledge of 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!

+3


source


There's a fine line between

Hey buddy! Perhaps System.exit (1) is not the best way to deal with this ParseException?

and

Who the hell is calling their variable "date37"?

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

+2


source


  • Always point to a specific suggestion for how to improve, not just what needs improvement.

  • Always state the exact reasons WHY a proposed change is beneficial.

  • It is advisable to indicate how it is beneficial for those considered (for example, saves it later)

  • Put shades on criticism. Meaning ", this paragraph needs to be corrected for these reasons N. These 2 places I would strongly recommend to change for these reasons, but only if you have an hour to spare for redesign. And these 5 points are insignificant and probably somewhat subjective, so I will give take your POV and let you decide whether to take my advice "

Same rules as for code reviews, BTW.

+1


source


I believe that if you are going to somehow tell how to improve, they will need to improve first. Otherwise, any suggestions will be considered an insult to them.

So, rule number one is to have a company ethic that improves their craft.

It also means that no one is "above the law," so to speak. Code improvement suggestions go both ways and a mutually beneficial dialogue is created.

It's all about "Why?" Why is one way better than the other? Let's talk, and in this process we improve our skills.

0


source


I also found it helps if you point out why you think x vice Y is that you learned the hard way, why Y is better. If you can point out that you made the same mistake and how moving to Y improved performance or maintainability, or whatever improved it, then it doesn't seem as critical as sharing lessons learned. The more painful your training was, the more someone will see that you are trying not to criticize.

0


source






More articles:


All Articles