Comments on: The Fine Art of Being an Asshole in All the Right Ways http://www.entertainingcode.com/archives/the-fine-art-of-being-an-asshole/ Coding and the games industry Sat, 10 Jul 2010 08:04:20 +0000 http://wordpress.org/?v=2.9 hourly 1 By: Gregg Sporar http://www.entertainingcode.com/archives/the-fine-art-of-being-an-asshole/comment-page-1/#comment-166 Gregg Sporar Mon, 16 Mar 2009 18:51:05 +0000 http://www.entertainingcode.com/?p=224#comment-166 >be the most nitpicking, hard-to-please obsessive-compulsive asshole the earth has ever seen Fair enough, but keep in mind that diplomacy counts - in other words, it's not just what you say during a code review, but also how you say it. More thoughts on that topic here: http://smartbear.com/docs/CodeReviewSocialEffects.pdf >be the most nitpicking, hard-to-please obsessive-compulsive asshole the earth has ever seen

Fair enough, but keep in mind that diplomacy counts – in other words, it’s not just what you say during a code review, but also how you say it. More thoughts on that topic here: http://smartbear.com/docs/CodeReviewSocialEffects.pdf

]]> By: slicedlime http://www.entertainingcode.com/archives/the-fine-art-of-being-an-asshole/comment-page-1/#comment-165 slicedlime Fri, 13 Mar 2009 14:17:47 +0000 http://www.entertainingcode.com/?p=224#comment-165 Interesting comment. We tend to do something more akin to a "design review" -- you've got to discuss your design ideas with someone before you go implementing them. You're absolutely right in that after all the code's done, design errors hurt much more to fix. Interesting comment. We tend to do something more akin to a “design review” — you’ve got to discuss your design ideas with someone before you go implementing them. You’re absolutely right in that after all the code’s done, design errors hurt much more to fix.

]]> By: Peter Jaric http://www.entertainingcode.com/archives/the-fine-art-of-being-an-asshole/comment-page-1/#comment-163 Peter Jaric Fri, 13 Mar 2009 14:11:17 +0000 http://www.entertainingcode.com/?p=224#comment-163 My experience is that I often find stuff that are not actual errors, but design issues. These will not cause bugs in the short run and can not easily be faulted that way. I am talking about code that should be abstracted, or code that could be changed to use a common design pattern, etc. It is much harder to persuade the coder to change that kind of code than to point out an obviously missing !, unfortunately. I just wish everyone understood that I am the authority on these matters :). And about logic errors, I've also noted that unit tests often find them before the code gets to the code review stage, but someone has to review the test code too, I guess. All in all, a very interesting post, though, and I totally agree with you that there's no point in doing a code review if you don't point out the faults! My experience is that I often find stuff that are not actual errors, but design issues. These will not cause bugs in the short run and can not easily be faulted that way.

I am talking about code that should be abstracted, or code that could be changed to use a common design pattern, etc. It is much harder to persuade the coder to change that kind of code than to point out an obviously missing !, unfortunately. I just wish everyone understood that I am the authority on these matters :) .

And about logic errors, I’ve also noted that unit tests often find them before the code gets to the code review stage, but someone has to review the test code too, I guess.

All in all, a very interesting post, though, and I totally agree with you that there’s no point in doing a code review if you don’t point out the faults!

]]>