Leverage your Git Code Reviews

During the last few years, I have provided Pull Request code reviews for many FE engineers at Degreed.com.

• Some of the reviews requested refinements and polish work.
• Some of the reviews identified notable flaws with RxJS
• Some of the reviews identified issues with UI component libraries
• Some of the reviews requested significant changes to the Pull Request.

Most organizations encounter these ^ same issues and struggle with improving the code review process.

Software engineers (aka developers) - both FE and BE - can be easily intimidated, alienated, and offended by Git PR Code Reviews.

In Degreed's Slack, I recently posted a department-wide note to engineering (> 120 engineers) regarding Degreed's Github Pull Request process.

I am posting this here as this may be helpful to other teams and organizations.

@Engineering

I want to encourage the Degreed Engineer to use our Pull Request Code Review?process (PR CRP) as the BEST opportunity to learn and refine your skills.

Often we “think” we understand concepts. Yet real-world efforts reveal real “gaps” between classroom (or book/video training) and production.

Thoughts for Code Authors

Be mindful of the following considerations:

• The Pull Request review and feedback may provide requests [for changes] the you can simply do immediately!
• Other times, the changes will require zoom calls and pairing to understand the issues and solutions.

As the PR author, you should expect 1-2 cycles/iterations of review. No more.

During your Pull Request CRP:

• Build trust,
• Build skills,
• Build relationships,
• Build great collaborations with your reviewers,
• Mark your PR as "Draft" if you are not ready for a code review. These types of PRs are considered previews and intended for online sharing; not for formal reviews.

And more specifically:

• Avoid creating "fake" test code, and
• Do not use the same Reviewer for your PRs.

You should feel that the reviewer is focused on improving both code quality and your skills.

As the code author, please consider these situations as “training” opportunities. Relish these moments!

A “software engineering” life without mentoring and guidance is most often super frustrating and lonely.

Thoughts for For Code Reviewers

Code Reviewers should be mindful of these ^ "Author" thoughts and considerations.

Here are some additional recommendations for PR coder reviewers:

• You can be blunt, but do not attack,
• Strive for good or “great” code; but avoid goals of “perfection”
• Avoid nitpicks and code-style differences,
• Be prepared to have video sharing sessions to explain and guide.
• Focus on quality and up-skilling,
• In general, avoid commenting on a PR if you are NOT the requested reviewer,
• If the issue is complicated, avoid a lengthy review comment. Instead simply schedule a Zoom pairing to review,
• Prepare solution concepts in advance,
• Prepare to pair program if needed. Use VS Code LiveShare to pair program, and
• Be prepared to change your mind, to compromise on the final solution... the goal is steady improvements while avoiding immediate disasters.

May our Github/GitLab Code Reviews be great and fruitful!