Stefan Koopmanschap has a new post today talking about code reviews and introducing the concept for those not familiar with what they are or their usefulness.

Code reviewing is exactly what it sounds like: It is reviewing code written by another developer. There are different ways of doing this, but in the end it all comes down to having at least one other set of eyes checking any code written before it is released. There’s many reasons for doing code reviews. It can be to prevent security issues, to ensure correct performance of your application, to prevent bugs but eventually it all comes down to the more generic term of ensuring the quality of your application.

He goes on to talk about some of the most common ways to do code reviews, either in something a simple as a pull request out to face-to-face discussions as the code is being introduced. He includes some hints on preparing for the review, steps to perform the review, dealing constructively with the comments made and finally the approval. He talks about who should do the reviewing and how they can still be useful even if you work alone or with a QA department.

In the latest episode of their "Cloud Out Loud" podcast series, Elizabeth Naramore (of Engine Yard/Orchestra.io) interviews Laura Beth Denker, and Anthropologist of Developer Culture at Etsy).

They talk about one of Laura Beth's passions (software testing), what her role means there at Etsy, their "startup culture" and how they handle deployment and code reviews.

You can listen to this latest episode either via the in-page playerdownloading the mp3 or by subscribing to their feed.

In a new post to his blog today Hannes Magnusson talks about the benefits of doing a code review and getting your eyes on as much other people's code as possible (and a bit about a pleasant side effect of it).

Reading code is not only fun, its also a great way to exercise your brain - not to mention a fantastic way to discover new ways to solve problems. At work (we are hiring btw!), for example, I read pretty much every single commit (and merge requests, for that matter) - and I'm subscribed to several different OSS commit lists. I can't say I read every commit to PHP, I focus on the areas I care about, but I do skim over the rest - if only just to see when new features are added.

He talks about the various mailing lists that are around the PHP project (like the documentation, PEAR and PECL ones) and how many of the subscribers are cross-list, following along with multiple parts of the project.

Just the simple fact that I know people will be reading through my commits makes me think about what I am doing a bit more; "Is this really needed?", "Is there be a better way solving this?", "Could it potentially break other things?", "Is this actually correct?".. The people who review the commits often don't seem like the friendliest people in the world.. If there are issues with the commit; You will be told. No doubt about it.

What's the side effect I mentioned? Hannes' account credentials were hacked but, because of the code review process, a random commit from another developer was caught.