It’s been an exciting month, with most of us back to work with renewed energy and purpose. Here’s this month’s Dev Breakfast with a little something on Code reviews.
Meet Martin, this month's curator
Martin Schenck is a Senior Consultant and Tech Lead at Futurice. As a former startup CTO and software engineer, he has helped shape many teams of various sizes. One topic that is dear to Martin is the social aspect of teams, and in that, the various interactions between engineers. That’s why he dedicates this edition of Dev Breakfast to one of those interactions: Code Reviews.
This guide conveys a strong foundation to build review practices upon. It is two guides: one for reviewers and one for developers. They are collections of recommendations that are based on long experience. The reviewer's section starts with some basic principles and continues into specific recommendations on how to do an effective, meaningful review. The developer's section talks about the importance of good descriptions, smaller-sized changes, and how to handle reviewer comments.
In this article, Michael Lynch presents a framework for code reviews. It gives concrete recommendations to code authors that are easy to implement with some practice. Michael also wrote How to Do Code Reviews Like a Human, which I specifically like, because it emphasizes that interactions between engineers are social interactions between humans.
The code review pyramid by Gunnar illustrates the difference in effort and importance between the various building blocks of a code review. For each building block, it gives a concrete high-level overview of the questions that you should ask yourself as a reviewer. It is more of a cheat-sheet, rather than a compendium.
In this piece, Julia makes general recommendations on how to learn at work. However, she devotes two sections to topics that code reviews cover: “read every pull request” and “read the source code”. I think “learning” is an important factor when thinking about code reviews. And it goes both ways: reviewers and developers can learn from one another.
In his post, Thomas elaborates on why he thinks code reviews should be an exception rather than the norm. According to him, reviews: discourage trust, don’t prevent bugs, and slow down. In my experience, all three of his base assumptions are wrong and I strongly disagree with his sentiment that code reviews are bad if required. On the contrary, code reviews can create trust, prevent bugs, and ensure long-term high velocity with only a comparably small investment. As is evident from the other links, there are more benefits to code reviews. Having said that, I think it is important to have a look at sources you don’t agree with. Often, they can improve your opinion on a matter.
With talented professionals around, you will get to work on a variety of projects, domains, and business cases potentially in the automotive, energy, and health sector.
With your business mindset and commitment to building close, human, and trusted relationships with customers, you will help us to succeed in delivering outstanding impact for our clients.