Developer Summary shows a condensed view of an individual’s core metrics. Visualize work patterns and progress over time, quickly spot and eliminate any blockers that are holding your team down. The Developer Summary includes a view of your engineers’ output, which is particularly useful to help you understand the shape of an engineer’s week or month across all work types.
How to use the Developer Summary
In the Developer Summary, you can see engineers’ core code metrics, a breakdown of their commit risk and work focus. If you scroll down, you will be able to view a timeline of their commits, along with the risk and work focus assigned to the commits.
One of the toughest and most important responsibilities in engineering management is asking great questions and communicating the actionable answers. With the Developer Summary, it’s now possible to have a better understanding of what’s going on before you enter a one-on-one, so you can spend less time talking about what’s going on and more time talking about why which might shine a light on opportunities where you could help and when you’re advocating for a specific individual on your team. You can leverage trends from the Developer Summary to tell a more compelling, proven story.
Developer Summary metrics
Throughput — Total amount of code of new, churn, help others and refactored code.
Productive Throughput — The proportion of code without churn.
Efficiency — Is the percentage of an engineer’s contributed code that’s productive, which generally involves balancing coding output against the code’s longevity. Efficiency is independent of the amount of code written.The higher the efficiency rate, the longer that code is providing business value. A high churn rate reduces it.
Technical Debt— Is the amount of refactoring code done by the developer.
Commits — The amount of commits done by the developer.
Days Active — The amount of days the the developer check in code.
Work Type — The highest types of work an engineer is focused on.
Risk is a measure of how likely it is a particular commit will cause problems. Think of this as a pattern-matching engine, where Waydev is looking for anomalies that might cause problems.
Some of the questions we ask when looking at risk are: ‘How big is this commit? Are the changes tightly grouped or spread throughout the code-base? How serious are the edits being made — are they trivial edits or deeper, more severe changes to existing code?’
tt100 is the time it takes for an engineer to create 100 productive lines of code (code without churn).
PRs is the number of pull requests created by an engineer.
PRs Open is the number of open pull requests of an engineer.
PRs Closed is the number of closed pull requests of an engineer.
PRs Merged is the number of merged pull requests of an engineer.
PRs Merged Without Review is the number of pull requests merged without review by an engineer.
PR Comments Addressed is the number of comments addressed by an engineer in all pull requests.
PR Reviews Addressed is the number of reviews addressed by an engineer in all pull requests.