Features
Visualize work patterns and progress over time, quickly spot and eliminate any blockers that are holding your team back. Understand what's going on before entering one-on-ones.
Developer Summary shows a condensed view of an individual’s core metrics.. It includes a view of your engineers’ output, which is particularly useful to help you understand the breakdown of an engineer’s week or month across all work types.
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 crucial responsibilities in engineering management is asking great questions and providing 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. This makes it easier to highlight opportunities where you can help your reports.
Throughput — Total amount of code, organized by: “new”, “churn”, “help others”, and refactored code.
Productive Throughput — The share of code without churn.
Efficiency — The percentage of an engineer’s contributed code that is 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— This is the amount of refactoring code done by the developer.
Commits — The amount of commits done by the developer.
Days Active — The number of days the the developer check in code.
Work Type — The highest types of work an engineer is focused on.
Risk — an estimate 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 — the time it takes for an engineer to create 100 productive lines of code (code without churn).
PRs — the number of pull requests created by an engineer.
PRs Open — the number of open pull requests of an engineer.
PRs Closed — the number of closed pull requests of an engineer.
PRs Merged — the number of merged pull requests of an engineer.
PRs Merged Without Review — the number of pull requests merged without review by an engineer.
PR Comments Addressed — the number of comments addressed by an engineer in all pull requests.
PR Reviews Addressed — the number of reviews addressed by an engineer in all pull requests.
Ready to improve your teams' performance?
