Providing and responding to review feedback

It is worth remembering that code reviews are aimed at the overall quality of code in keeping with the company's guidelines. Feedback, therefore, should be constructive and not used as an excuse to put down or embarrass a fellow colleague. Similarly, reviewer feedback should not be taken personally and responses to the reviewer should focus on suitable action and explanation.

The following diagram shows the process of issuing a Pull Request (PR), performing a code review, and either accepting or rejecting the PR:

Providing feedback as a reviewer

Workplace bullying can be a problem, and programming environments are not immune. Nobody likes a cocky programmer who thinks they are big. So, it is important that the reviewer has good soft skills and is very diplomatic. Bear in mind that some people can easily be offended and take things the wrong way. So know who you are dealing with and how they are likely to respond; this will help you choose your approach and your words carefully.

As the peer code reviewer, you will be responsible for understanding the requirements and making sure the code meets that requirement. So, look for the answers to these questions:

• Are you able to read and understand the code?
• Can you see any potential bugs?
• Have any trade-offs been made?
• If so, why were the trade-offs made?
• Do the trade-offs incur any technical debt that will need to be factored into the project further down the line?

Once your review is complete, you will have three categories of feedback to choose from: positive, optional, and critical. With positive feedback, you can provide commendations on what the programmer has done really well. This is a good way to bolster morale as it can often run low in programming teams. Optional feedback can be very useful in helping computer programmers to hone their programming skills in line with the company guidelines, and they can work to improve the overall wellbeing of the software being developed.

Finally, we have critical feedback. Critical feedback is necessary for any problems that have been identified and must be addressed before the code can be accepted and passed on to the QA department. This is the feedback where you will need to choose your words carefully to avoid offending anyone. It is important that your critical comments address the specific issue being raised with valid reasons to support the feedback.

Responding to feedback as a reviewee

As the reviewee programmer, you must effectively communicate the background of your code to your reviewer. You can help them by making small commits. Small amounts of code are much easier to review than large amounts of code. The more code being reviewed, the easier it is for things to be missed and slip through the net. While you are waiting for your code to be reviewed, you must not make any further changes to it.

As you can guess, you will receive either positive, optional, or critical feedback from the reviewer. The positive feedback works to boost your confidence in the project as well as your morale. Build upon it and continue with your good practices. You may choose to act or not upon optional feedback, but it's always a good idea to talk it through with your reviewer.

For critical feedback, you must take it seriously and act upon it as this feedback is imperative for the very success of the project. It is very important that you handle critical feedback in a polite and professional manner. Don't allow yourself to be offended by any comments from your reviewer; they are not meant to be personal. This is especially important for new programmers, and programmers who lack confidence.

As soon as you receive your reviewer's feedback, act upon it, and make sure that you discuss it with them as necessary.