When you are altruistic, you leave the code base better than what it was before, provide inspiration for fellow engineers to not only mimic but aspire to in their own work, and you become a shining example of what is achievable. Engineers that exhibit this level of care tend to be architects but can be seniors too.

You leverage good patterns and practices. Achieves functionality without sacrificing simplicity and conciseness. Demonstrates good practices for others to follow. Is a joy to work with, reference, and maintain. Senior engineers are the minimal level that tend to exhibit this level of the craft.

You demonstrate proper handling of the OWASP Top Ten security risks and much more. Mid to senior engineers tend to be the minimal level in which to be aware of these concerns.

Your code is written to be read and understood by a fellow human, including the associated Git commit explaining the reasoning behind the what, why, and how of the implementation. Modules, classes, methods, and variables are self-explanatory. Coding conventions are adhered to. Tests are brief, capture edge cases, and document the overall capabilities of the implementation. Mid engineers tend to be the minimal level where this skill is usually on display, but every now and then, younger engineers will break through.

Provides an implementation that does what it’s required to do, handles edge cases, and is decently tested. Unfortunately, this kind of code is usually hard to read and/or understand. You’ll generally discover such unreadable to code be written by a young engineer or someone who doesn’t grasp the language that well. All engineers start out at this level before progressing upwards. Sadly, a lot of code tends to not move beyond this point.

What Maslow’s Pyramid provides, in this context, is an illustration of the various gradations in code quality that can be achieved if you make these goals a team effort. The pyramid not only gives you a way in which to grade yourself and others but also to hold everyone accountable. Having this North Star is a big part of a healthy team and good engineering culture in general.

At a high level, the main objectives each code review are:

In addition to the objectives above, the following basic rules are worth following/enforcing when reviewing code:

Templates are great for providing a basic structure people can follow when submitting code for review or reporting an issue. These templates should clearly define what is required and what is optional when reviewing code. Otherwise, anyone can provide any structure they like or nothing at all which is a detriment to consistency. For example, consider the following templates which are provided for you via the Rubysmith or Gemsmith gems when building new Ruby projects:

Since the above templates are written in Markdown, the comments (i.e. <!-- and -->) never render, but they are none the less shown to instruct someone new to the team what is required and what is optional. As a side note, these are quite valuable to test one’s attention to detail when interviewing, as well.

Emojis are a powerful way to convey mood and/or liven up the conversation, especially when you are communicating asynchronously. Since you can’t see one another, it’s important to convey understanding with emojis — and preferably a select few. You can use more, of course, but here’s what I’ve evolved over the years:

Emojis are only necessary when initiating new feedback but sometimes they can be useful when joining an existing conversation. A delicate balance is required in order to not overwhelm the author but when used judiciously, emojis are a great way to improve discourse between the author and you, the reviewer. The greatest benefit from this practice is that it:

For more details, I’ve spoken specifically about emojis and have an associated talk which might be of interest.

Here’s a breakdown of each emoji and how to use them effectively:

It’s important to a team’s cadence, workflow, general camaraderie, and respect to review feedback early and often. At a bare minimum, ensure you check in, at least three times a day on what your team is doing. As an example:

While the above is the minimum, realistically, as you pop up for air, you’ll most likely be curious about feedback on your own work and want to help other’s move their work along as well and check on feedback more often. Depending on the size and/or velocity of the team, checking too often can be distracting, so make sure to time box yourself and provide quality feedback without holding others up for too long.

Lastly, avoid letting code reviews linger more than a day. Otherwise, you risk hampering moral and diminishing the productivity of the team.

In order to ensure code reviews are consistent, of high quality, and swift to resolve, you’ll want to automate as much of the process as possible. For details, check out my Code Quality article to learn more as I detail all of the tools you can use to speed this process up.

Enforce a rebase workflow for all of your GitHub projects. You can do this via your project options (i.e. https://github.com/<owner/<repository>/settings) and editing your merge options for code reviews as follows:

You’ll want to add branch protection rules for your main branch. To do this, follow these steps:

With the above applied, you should have the following result:

Applying the above changes will help maintain a clean Git history.

Viligant Mode provides an additional layer of security and verification for all Git commits and tags. You can enable this setting via the following steps:

Upon successful completion, you should end up with the resulting configuration: