Skip to main content
8 events
when toggle format what by license comment
Mar 19, 2012 at 18:47 comment added Wil Moore III +1 to code reviews. Instead of feeding your developers, it is always better to teach your developers how to fish for themselves. Further, a coding standard, style guide, developer documentation, unit tests, and continuous integration will be your best friend. If you are the lead developer and you haven't put this in place already, what are you waiting for?
Mar 17, 2012 at 0:13 comment added TehShrike Even if you never transition to "real" code reviews, simply talking to the other person - asking why they did certain things, and why they didn't do it [some other way], is a great way to accomplish many of the same goals. +1
Mar 16, 2012 at 20:49 comment added Paul Nathan Agreed. Don't muck with other people's code without asking. You can get some gnarly bugs that way. I've fixed goal-tending bugs, and they are not pleasant. If you are concerned about code robustness, write unit tests.
Mar 16, 2012 at 17:05 comment added Kevin McCormick Brilliant answer and thanks for the insight. I think a bringing copy of this question and a humble attitude to my manager might convince him that code reviews would be beneficial to the team and will reduce the need for "goal tending".
Mar 16, 2012 at 17:03 vote accept Kevin McCormick
Mar 16, 2012 at 16:37 comment added Mike Cellini This. Real code reviews would be a much better path here. The two big upsides being, like you said, the developer learns the application architecture more quickly because you are showing him the issues. The second being that you won't be introducing bugs because you don't fully understand the new code being written. Perfect answer for this question.
Mar 16, 2012 at 16:34 comment added Doug T. Big +1. Code reviews help build the team while the "goal tending" he describes seems like it might rub people the wrong way.
Mar 16, 2012 at 15:08 history answered Justin Cave CC BY-SA 3.0