Remote code review

Code review is one of the best tools for developers to make good quality software. Code review means you show your colleagues your work, they read your code, ask questions and give you some advice about improving your work. A good review can greatly decrease the number of bugs, so if you work in the environment, where it is not common to do code reviews, I highly recommend to introduce it.

When I was a junior developer there were only one person who I was thinking about: It was me. I have written my code, sent a mail to the team to ask for a code review and went to the next item on my to do list. Today, I think this is the most inefficient way. Imagine that you get an email to review a code and you know nothing about the task, about the requirements, generally you are not familiar with the context.

Do not worry, it can be worse: what will happen if you get the same email with high priority and you have to throw away your current work and try to figure out the code that you see. You will ask a lot of questions about the task and interrupt the other side multiple times to get the picture. That is the perfect way to waste working hours of several people.

How to do code reviews

The best way to do code reviews is as follows: do everything that needs to be done to minimize the interruption of the reviewers time and help them do their work as fast as possible. I know my teammates and I almost always know who will do the code review. The reviewer has to be able to allocate time to the review, so my job is to gather all the necessary information form him/her to be able understand the task and get the picture and schedule a review meeting for the next day. The reviewer will have only one job: accept the meeting and take time only for the review. Actually I solve two problems with that:

  1. I create a time window for the review. There will be no interruption at all.
  2. Reduce the number of possible questions. The code review will be more effective.

Code review as a remote programmer

If you work remotely, you become an invisible developer. You cannot just walk to your colleague to schedule a meeting for the next day and prepare him or her to the code review next day. And you also cannot sit down next to the reviewer to help to understand your code.

Actually, we live in the 21st century so we have really great tools that can support us to do the proper communication. I give you some examples of software  I use every day and they are very useful if you want to do a code review online:

  • We use Outlook. This is a great tool. If I want to schedule a code review session, I just use the scheduling assistant, so I do not have to disturb the reviewer to find the proper time. I pick a good and short topic for the meeting, e.g.: ‘Code review – Refactor new login flow’ and I always fill the description with the necessary information that helps to understand the change.
  • JoinMe is the next great tool. I can create a personal URL that contains a single link. If you schedule a meeting in Outlook, you can add the place. As I am invisible in the office, the place will be always a JoinMe link with my personal URL. It is easy to remember and the reviewer has nothing else to do but click on the link.
  • A great diff application. Yes, I know. If we use proper version control, we have pull requests and we can check the diff easily. However, I always find some exception and for that case, I have an application installed called WinMerge and I am able to show any kind of diff with that.
  • A great diff tool for version control. Sometimes I have to check some diff in my local computer. If you have ever tried to use the embedded diff in SourceTree, you know it is terrible. I recommend to set up P4Merge. It works perfectly with SourceTree.

Human factor

As a developer it is easy to forget, but we work with human beings. That means we can have any kind of software toolset in our repertoire if we do not care about our colleagues. It is really important to know the people that we work with to be prepared for their reactions.

My examples for my boundary personality types

The easiest personality type: the silent thinker. The analyzer.

I know a guy who needs no instructions at all. He is a typical thinking machine. I put the ticket into the machine, it processes it and sends the output. That is the example when you do not have to schedule a meeting. You will receive a whole list with his findings and you can talk all of them in a short call later.

My hardest type: the important man.

I know an other guy who thinks he is the most important man in the Company. If you want to ask him you have to be prepared. If he has any question, he calls you immediately. That is the hardest type. I had a lot of painful code reviews until I could figure out the solution.

He does not need any written information at all: I just have to call him one day earlier, tell him that I really need his help and it would be great if he could help me on the next afternoon to walk through my work. After that, I tell a brief introduction about the task and tell him how much time I will need next day.

Actually, I tell him the very same information that I would write down to the meeting description for other people. I can write down the description and read that for him, it does not matter. He will never ever read the description. He just needs to know, that I need his help and he is really important to get the job done. Next day, I call him again to tell I could finish my job and I kindly ask him sacrifice some of his time for me to check my work.  He says ‘OK, show me what you have’ and we are already in the finish. He does the code review.

Handling different personality types

I only introduced two examples: the easiest person type and the hardest person type. Actually every person is different and they have different behavior. You have to analyze your colleagues and find the best way to handle each of them. Maybe it is some extra effort, but it has huge benefit and  it will help you a lot during your daily job.