There are many benefits of code review---lower development costs, increased code quality, quick up-skilling and on-boarding of team members. Despite these benefits many teams don’t have code review as part of their process at all, while others don’t get the gains they should.

This talk outlines the business case for code review and explores how to make code review effective, specifically looking at:

* Expectations of what can be achieved with code review.
* What should be covered by code review (including example code).
* What should not be covered by code review.
* How to write code that makes code review easy.
* What makes good code review comments.
* What makes good responses to code review comments.

Finally, to wrap up, you'll be shown how to enable a code review with GitHub. Spoiler alert---it can be done it under five minutes!

So if you are on a team that isn’t using code review, or isn’t using it effectively, then you should be at this talk.


Comments are closed.

Ash Smith at 20:17 on 25 Apr 2018

Liked the scuba diving reference to kick things off! Lots of good examples of code that needs to be reviewed, and packed with useful tips!

The text on the slides could do with a little more contrast perhaps as it’s wasnt so easy to read from the back of the room, likely to be even harder in a larger venue :)

Lucia Velasco at 20:19 on 25 Apr 2018

Refreshing intro!
Loved use of props!!! Needs more visibility - maybe a thick, bright ribbon, higher up if possible?
V good analogy. I love life-or-death analogies for code because sometimes it really is.
It would be good to give examples of why bugs cost us and increase in cost, briefly. The arrow on the graph was really powerful.
Text on your personal info slide was too close to the edge, and a bit lightweight for the amount of text on the slide (did that make sense?).

I'd prefer more paraphrasing of the slides or examples of the bullet points in the slides.
I love that you went into the benefits of code review outside of bug catching.
I'm going to use those evolvability stats in a spike next week - useful!! My big fear when receiving very shallow reviews are evolvability bugs slipping under the radar.

I think it would be powerful to gesture to the green line at the beginning, when it's higher than the blue line, to acknowledge the upfront cost.

I live and breathe for the security review side!!

I love the 'How many tests do we need', they make me feel clever and they make a very good point.
I love that you talked about bad (or sometimes just unreadable/wizard magic) code, that's so important to me.

Cost of writing code slide was cool and well presented, I like fat graphics.
Reviewing naming! Yaaaasss! Slash documentation?

Are your code review standards/guidelines public? If so, please share it!

Talking about leveraging your IDE is really good, but a lot of it sounds like benefits after the fact of code review rather than IN code review?

Please mention the benefit of a no blame culture - which comes from the shared responsibility of the codebase. It is especially valuable because people are more likely to own/admit less than perfect things.

Do you review commit messages?
Those Cisco tips were REALLY valuable. Will bear that in mind.

I would add the receiving review tip of actioning feedback to the same standard as the rest of your code - I find a lot of people rush it or hack it because they want to their PR thru asap, but it just slows the follow up review.

Would potentially recommend putting a cross and a tick into the good/bad commit head circles for people who are red/green colour blind.

Really appreciated the summary slide, it was very good.

The conversation on reviewing juniors was really helpful and validating for me, thank you for answering my questions.

General delivery was really good, would have enjoyed a bit more humour to break it up, but overall it was informative, smart, comprehensive and useful. Thank you!!

MattRink at 20:28 on 25 Apr 2018

A great talk on code review with lots of things to take away from it. It would be good if there was a bit more time on the technical integration of it into workflow. I liked the examples and references throughout.

Great talk really enjoyed.

Great talk with attention grabbing introduction with the scuba diving analogy. A lot of useful information and tips on how to code review in addition to why you should code review. Delivery was good overall, but could have looked at the laptop screen a bit less and the audience a bit more.

A great introduction to a potential minefield that included useful tips on important business-level arguments to make the case for implementing it.

Roussetos at 08:05 on 26 Apr 2018

Nice talk about code review. As others pointed out, some slides need a bit more work on text readability.

Good approach / parallels on why to use code review. Great point for use it for nurturing junior developers as it is quite rare these days to do pair programming or have time to sit around and check for points.

I would like to see more of an effective way to 'sell' it to management and apply it as a principal across projects. The most difficult aspect is to start implementing it as a standard practice and in a world of clients and building a project as soon as and within budget, makes its implementation hard to justify sometimes.

And completely agree, a minimum of 2nd pair of eyes is always better than just one :)

This has the potential to be a very dry subject but Dave did a great job keeping it interesting and engaging. I enjoyed the diving reference. There was some really useful tips including making your code readable for yourself and other devs. I struggled with the length a bit, I thought it could be 15mins shorter but partly because I was hitting this after a days worth coding lectures beforehand. Very well presented!

Kyam Harris at 21:52 on 27 Apr 2018

I really enjoyed Dave's justifications to give to managers and superiors on how effective Code Review can be to business objectives. Also, it was really helpful to have the visual representation with the diving reference.

I do think however that the talk was a little long and could have been cut by 10/15 minutes.