Another pair of eyes: Reviewing code well

Many of us have been taught to code, but we know that software engineering is so much more than that. Programmers can spend 5-6 hours per week on code review, but doing that is almost ignored as a skill, and instead it is often treated as a rote chore.

How many of us have seen poor reviews - those which upset people, don’t catch bugs or block important features being merged? This talk explores the social and technical impacts of various code review practices as well as helpful tooling. The goal is to provide a structure to help improve how teams review code, and to introduce the costs and benefits of code review to anyone unfamiliar with the practice.

There are always trade-offs to be made - e.g. think how costly a security flaw in this code could be to your organisation - perhaps intense scrutiny is not necessary for prototypes soon to be thrown away. It is useful to consider the trade-offs in order to optimise for a particular problem domain. Perhaps right now it is more important to look for issues with maintainability, functionality or performance.

I talk about how some fantastic code reviews from mentors, colleagues and strangers have helped me become a better programmer and team member, as well as occasions where code review has been detrimental by slowing things down and causing arguments.

This is aimed at everyone from beginner to advanced programmers.