For the last decade, I‘ve always had the pleasure of working with development teams where code review has been practiced on daily basis. If somewhere there was no code review in a project when I was joining, I’ve just tried to introduce this process into practice. All this time, I’ve been collecting a lot of experiences, thoughts and consternations that I wish to share with you.

Let’s introduce code review

Let’s establish the code review process as soon as possible, because it’s a well-known and opinionated technique.

Such thinking often accompanies us while start with a new project. Thousands of people describe code review as good practices, and hundreds of books confirm it. What can go wrong? Experience shows that everything, because the biggest problem is ourselves and our level of mutual incomprehension.

Photo by Jon Tyson on Unsplash

First knowledge, then action

We, software developers are usually knowledgeable and skilled people, but I notice one thing: programmers often do not have developed skills in giving and receiving feedback. No offence, it doesn’t mean we are different, specific or bad. We just don’t have enough knowledge about it. Simple, but don’t worry. After programming hours, I mentor people, not only about technical things, but about soft ones also, and I can confidently say that the problem of poor skill in providing feedback is a nuisance for all people. Unfortunately.

First and common issues

A combination of good intents for code review and poor feedback skills has nothing to do with it. Unfortunately, good intentions will not help when we have gaps in knowledge. There are many feedback techniques and I can not really say which one is the best, but for sure the ones listed are very good and you can start working with them and try on your own. Opinionated techniques that I used in past are: SBI, FECE, NVC . There is one more “opinionated” techniques so-called the sandwich feedback method, but in my opinion does not bring much value. Moreover, it can even be harmful at times.

FECE technique

As I mentioned, there are many techniques, but the most important thing is to learn at least one and start applying knowledge in practice. In the case of code review, I truly believe that the FECE technique can bring big long-term results.

FECE is an acronym from Facts, Emotions, Consequences and Expectations. Each word covers typical question about subject:

• Facts: What’s going on in your code? What can I observe in your code? What can I read in your code review? What can I see in your code review? What exact fact am I referring to?
• Emotions: What am I feeling? What is my attitude to this observation? What breath into me that make me notice it?
• Consequences: What are the consequences of particular fact? How does it affect to project? How will affect it to project? What will it break?
• Expectations: What is the solution that I’m fine with it? How can you correct it so that I don’t have any more objections?

These four simple fact-based points can make any code review a process that delivers quality and improvements. Real quality and real improvements. Because if we write that something needs to be improved, then there is nothing to do with the quality.

#software-development #feedback #code-review #programming #communication