21: Efficient Code Review Process (The changes I wanted to do in one of my teams)

3 people assigned and two reviews are required. The more the merrier.

Why do I want to do?

We have a lot of (unintentionally) hidden knowledge about our services.

Domain knowledge is not spread across the team.

Learning domain knowledge is hard if you are trying to discover it by yourself. There are many legal or non-legal aspects of the features.

Onboarding people is hard, and our onboarding process still needs to get better.

What I want to do - and what’s the value of that?

I want to

• Increase the number of code reviewers to three
• Set merge requirements to two approvals
• Automatically assign people using the Load Balance algorithm instead of Round Robin as the routing algorithm within the whole team, not task-forces.

Value & Goals:

• Prevent creating new unintentionally hidden knowledge
• Increase domain knowledge
• Increase tech stack knowledge
• Give and receive more valuable and effective feedback from different members
• Have a better onboarding process
• Increase communication between task-forces
• Improve code quality.
• Lower the efforts in new feature/project planning phases.

How do I want to do?

I will go to GitHub team management and change everything as I propose above.

I will remove squad GitHub groups. I will keep task-force groups. If someone has a question related to the task force, they will be able to mention others.

What you will have to (do/learn/change) after I finish it

You will use only the team group on Github (and remove other subgroups) while assigning code reviewers.

This process will require everyone to review the code of others and other projects actively. It will add a little bit of overhead. But an important and valuable one.

You will have to learn each task force’s mission and their work. You will have to spend some time reading Jira tickets and ask questions proactively to challenge others.

The code reviews will probably take >0.5 days per person per week, but I don’t expect it to take more than one day per week.

Risks

If we change the code review mentality from “yet another task to do” to “it’s another chance to make this team better than I found,” we can lower the following risks.

PR review waiting times might get longer.

People will not actively review the code but will let the third person do it.

Communication overhead. If people don’t check the code at a certain time, it will require pinging people in person to take a look at the code. To lower this risk, everyone can review once a day the PRs that they have been assigned.

Measurement

Faster software designing for new projects, features. (We can measure how much time it will take us to plan the next feature/project implementation and compare with the last one)

Fewer bug reports. It’s hard to directly measure since we’re using different projects, boards, etc. But I know that it’s possible in Jira.

Faster and better onboarding. We will get feedback from the people who are currently in the onboarding stage.

• Related Note(s):
  • 13: Be Kind at Work;
  • 19a: Knowns and Unknowns;
  • 20: Influencing Others;
  • 26: The Cost of Software Deployment and Continuous Delivery;
  • 4b: Monitoring & Inspection to Learn;
  • 31d: Effectively Learn from mistakes;
  • 1h: Continuous Improvement Means Changing The System;
  • 27a: Increasing awareness of the actions and behaviors;
  • 2a: Take breaks to write better;
  • 27f: Try to keep your learning in ‘Just Manageable Difficulty;

This note is mentioned in: