Creating a measurable Pull Request process 🔍
Objectives:
- Improving the quality of code before being released
- Sharing knowledge across the team
- Keeping the PR cycle itself short
Metrics:
About Reviewer’s metrics:
- Reaction time: the time that passes between the submission of the PR and the reviewer leaving her comments. We want this to be low.
- Influence: the percentage of comments that later get actually addressed by the submitter. We want this number to be high, because we want the reviewer to write things that make sense.
- Review coverage: the percentage of the code that gets addressed by the reviewer’s comments. We want this number to be high enough to make sure the review is substantial, but not so high that makes us wonder whether the whole PR is wrong.
- Involvement: the percentage of the overall team PRs where that particular reviewer is involved. We want this number to be balanced with respect to our team size, to make sure everyone is involved in the process.
About Submitter’s metrics:
- Responsiveness: how fast the submitter responds to reviewer’s comments. We want this to be high.
- Comments addressed: the share of reviewer’s comments that get actually addressed by the submitter at least via a comment reply. We want this number to be quite high because reviewer’s comments should not be ignored.
- Unreviewed PRs: the share of PRs that get approved without review. We want this number to approach zero.
- Receptiveness: the share of reviewer’s suggestions that cause actual changes to the code before the release. Again, we want to be this high enough to make sure the submitter listens for feedback.
We track these KPIs by using an engineering analytics tool, such as Waydev, Pluralsight Flow or LinearB.
Improving Metrics
- having regular team reviews where the OKRs are discussed
- keeping a low number of open PRs at any given time
- keeping the average PR size under a defined threshold
- Primary Metric: % of PRs merged within 24 hours
Staying Technical as an Engineering Leader 👔
Assuming you are on a path where you end up writing less code than before.
Understanding your Schedule
- As a Maker, you benefit from long, uninterrupted streaks of time where you do your focus work.
- As a Manager, your schedule is run by meetings where you make decisions that drive the work of your team forward.
🙅 Giving up main development work
You should give up critical development work due to 2 reasons: unpredictable your time and decaying your dev skills
💁 How you can contribute
- ✍️ Design choices
- 🔍 Code Reviews
- 🔭 Tech Exploration
