This article was originally a guest post for FogBugz.

As developers, we all know that code reviews are a good thing in theory. They should help us:

• Find bugs and security issues early
• Improve the readability of our code
• Provide a safety net to ensure all tasks are fully completed

The reality is that code reviews can frequently be an uncomfortable experience for everyone involved, leading to reviews that are combative, ineffective, or even worse, simply not happening.

Here is a quick guide to help you to create an effective code review process.

(Updated 23 July, 2020)

We know that Code Reviews are a Good Thing. We probably have our own personal lists of things we look for in the code we review, while also fearing what others might say about our code. How to we ensure that code reviews are actually benefiting the team, and the application? How do we decide who does the reviews? What does “done” look like?

In this talk, Trisha will identify some best practices to follow. She’ll talk about what’s really important in a code review, and set out some guidelines to follow in order to maximise the value of the code review and minimise the pain.

Content and resources for the Code Review Matters and Manners talk, including links to additional information and supporting material.

So I came to the blog to update my upcoming events (at least something stays up to date) only to find it’s been nearly a year since I last blogged! This is terrible!

It’s not that I haven’t written anything in a year, it’s that a lot of my writing energy goes into stuff for the actual day job. Which is good, because that’s pretty much what I wanted from the day job, but the blog makes it look like I don’t write any more.

So I’m going to cheat. Here’s the stuff I’ve written in the last 12 months.