Since we started working together in squads, we’ve noticed that every developer has his own approach to coding. This results in different work approaches and coding experiences, like for example, how we iterate over lists, access data, or build classes.
We consider these differences as valuable opportunities to share experiences, learn from each other, and ultimately, guarantee a better quality of code. So we decided to experiment with ad-hoc face-to-face peer code reviews.
We started doing them about a year ago, and now, we can gladly conclude that we will keep organizing them as they have been very successful.
How does it work?
Whenever a developer finishes a piece of code or has some doubts about its implementation, they ask someone—or multiple developers—within the squad to review the code with them. We continuously question and challenge ourselves: “Can the code be better?”, “Where could it be improved?”, “Is there another approach?”, with the goal to keep improving and delivering excellent code.
We kick off our face-to-face reviews by providing some context and giving a short demo of our code. We use Visual Studio to compare the commits* and go over the code together to give feedback and improve where possible. Easy, but effective!
*Visual Studio > Git Changes > Manage Branches: Select the version from which you branched off and the latest version you worked from, then right-click and choose “Compare Commits”.
What we’ve learned: opportunities & pitfalls
After a year of frequently using this face-to-face peer review method, we’ve learned quite some things. First of all, there are lots of opportunities to improve your coding skills and your code.
Opportunities
- Gain experience with Visual Studio IntelliSense (intelligent coding features)
- Share knowledge and learn from each other
- Improve your understanding of the code thanks to a clear overview of all the changes and a better overall picture
- Improve squad collaboration and the understanding between reviewer and reviewee by communicating openly and regularly
However, there are also some pitfalls that you need to be mindful of. But we’re more than happy to share these pitfalls with you, and how you can avoid them when you start your own face-to-face peer code reviews!
5 Pitfalls & how to avoid them
- Pitfall #1: spending too much time on a code review. These reviews tend to take some time, so we try to timebox them upfront. This can of course be extended, if everyone agrees.
- Pitfall #2: reviewing big chunks of complex code. By reviewing smaller iterations, you avoid confusion, which helps you to get more done in less time.
- Pitfall #3: jumping right in. Before you take a deep dive into the code, try to provide some context first. This will clear up any possible confusion.
- Pitfall #4: trying to change everything immediately. Not everything needs to be changed during a peer review. When a suggested improvement is too big for the allotted time budget of the task, you can just document it and tackle it during the next related task.
- Pitfall #5: feeling the need to give/get feedback. Sometimes it is possible that no feedback is given. And that’s fine! Because getting/giving feedback is not the goal, it’s just a means. The real goal is to grow, learn and improve, and that’s exactly what happens when you go over the code together with your team members.
How it looks
Enough reading, it’s time for some action! let’s take a look at how we do this:
In this short recorded session, Emilie reviews a smaller method I wrote. The code is situated in an interactive automation script and is responsible for formatting retrieved data.
In the previous version, the end user defined a specific data format:
Header A: data A1, data A2
Header B: data B1, data B2
Now requirements have changed and the end user wants a CSV format:
Header A, Header B
Data A1, Data B1
Data A2, Data B2
To keep the video brief and to the point, certain steps, like giving a demo, have been cut.