Tips for the Reviewer

  1. Critique code instead of people – be kind to the coder, not to the code. As much as possible, make all of your comments positive and oriented to improving the code. Relate comments to local standards, program specs, increased performance, etc.
  2. Treat people who know less than you with respect, deference, and patience. Nontechnical people who deal with developers on a regular basis almost universally hold the opinion that we are prima donnas at best and crybabies at worst. Don’t reinforce this stereotype with anger and impatience.
  3. The only true authority stems from knowledge, not from position. Knowledge engenders authority, and authority engenders respect – so if you want respect in an egoless environment, cultivate knowledge.
  4. Please note that Review meetings are NOT problem solving meetings.
  5. Ask questions rather than make statements. A statement is accusatory. “You didn’t follow the standard here” is an attack—whether intentional or not. The question, “What was the reasoning behind the approached you used?” is seeking more information. Obviously, that question can’t be said with a sarcastic or condescending tone; but, done correctly, it can often open the developer up to stating their thinking and then asking if there was a better way.
  6. Avoid the “Why” questions. Although extremely difficult at times, avoiding the”Why” questions can substantially improve the mood. Just as a statement is accusatory—so is a why question. Most “Why” questions can be reworded to a question that doesn’t include the word “Why” and the results can be dramatic. For example, “Why didn’t you follow the standards here…” versus “What was the reasoning behind the deviation from the standards here…”
  7. Remember to praiseThe purposes of code reviews are not focused at telling developers how they can improve, and not necessarily that they did a good job. Human nature is such that we want and need to be acknowledged for our successes, not just shown our faults. Because development is necessarily a creative work that developers pour their soul into, it often can be close to their hearts. This makes the need for praise even more critical.
  8. Make sure you have good coding standards to reference. Code reviews find their foundation in the coding standards of the organization. Coding standards are supposed to be the shared agreement that the developers have with one another to produce quality, maintainable code. If you’re discussing an item that isn’t in your coding standards, you have some work to do to get the item in the coding standards. You should regularly ask yourself whether the item being discussed is in your coding standards.
  9. Remember that there is often more than one way to approach a solution. Although the developer might have coded something differently from how you would have, it isn’t necessarily wrong. The goal is quality, maintainable code. If it meets those goals and follows the coding standards, that’s all you can ask for.
  10. You shouldn’t rush through a code review – but also, you need to do it promptly. Your coworkers are waiting for you.
  11. Review fewer than 200-400 lines of code at a time.

The Process

What happens after a Developer completes the work on a big fix or an enhancement?

  1. They click the “Request Code Review” button on the Home page and complete the checklist before submitting their request.
  2. Once the Code Review request has been submitted, the Developer will receive an email letting them know that their request was received by the Reviewer. (The Reviewer also receives an email letting them know that a new Code Review request has been submitted.)
  3. Once the email has been received, a new Item will be generated in the Code Request Bucket (in Microsoft Planner) that will allow the Developer to track their request.
  4. The Reviewer will review the submitted code, completing their own checklist in the process, and, if needed, will schedule a 15 minute meeting to discuss any points of concern or ask any questions.
  5. If the Reviewer has no questions or concerns with the code, they will provide feedback in the Item (in Planner) and mark the Item as complete.
  6. Once the Item is marked as Complete, an email will be generated and sent to the Developer, letting them know that the code has been reviewed, provide them with feedback from the Reviewer, and instruct them to request a Merge with Master.
  7. The Development Manager will approve the Developer’s Merge request.
2019-03-05T14:58:44-06:00March 8th, 2019|

About the Author:

×