tag:blogger.com,1999:blog-7545863793559798918.post2921811507914839807..comments2024-02-28T21:45:43.932-08:00Comments on Journal of a Programmer: Code ReviewsBryan Pendletonhttp://www.blogger.com/profile/01020254358854104453noreply@blogger.comBlogger1125tag:blogger.com,1999:blog-7545863793559798918.post-33965922982462386392012-03-24T09:08:30.610-07:002012-03-24T09:08:30.610-07:00Peer reviews of code are very effective. I starte...Peer reviews of code are very effective. I started doing them 30 years ago. <br /><br />The boss has to make it part of the process: insist on it and not undermine this with things like: "skip reviews -- we don't have time." In a leaderless/consensus group, someone has to be an advocate and use persuasion and peer pressure. <br /><br />Materiality is crucial too: toxic arguments over style drain energy and support. Often, the most vociferous opponents of good programming style are the worst programmers, especially when it comes to maintainability and testability. It is best to choose an existing style standard (there are hundreds of good and proven available for free) and use it, even if there are some objections. When someone insists on particular nit, make it their job to convince everyone that all should do it that way.<br /><br />There's always been someone who has an allergy to reviews, and I've never found a way to change their mind. Next time, I think I'll allow the sneezers to opt-out and then hold them accountable for bugs that escape and could have been found in a review.<br /><br />Tools help to reduce the friction and focus on problems that human intelligence is best at finding. I've created a list in my blog post<br /><br />http://www.robertvbinder.com/blog/supporting-software-inspections-and-reviews/debuggerhttps://www.blogger.com/profile/11344504858882752744noreply@blogger.com