Developer Coaching

Developer Coaching allows those in a management or team lead position to view insights about an individual team member's workflow in order to identify information on developer wellness and experience. To view Developer Coaching, go to People > Coaching.

Please note: To access the feature, you must turn on “Show Individual Metrics” via the Company Settings menu.

Filtering the dashboard

To control which developer you're seeing information about, select their name from the dropdown list on the left of the page.

On the top right of the page, you can filter by team and by time frame. If a team filter is selected, only members of that team will show in the drop-down menu. The time frame selection will adjust the time frame of the data used to generate insights:

Teams, knowledge areas, and coding languages

Next to the developer's name in the drop-down menu, you'll see a quick summary of the teams the developer is a contributor to in LinearB. Additionally, you'll see a list of the repositories they contribute to, and the languages they work in most frequently.

Knowledge areas

This section displays up to the top 3 repositories based on developer activity over the past 6 months. Repositories are ranked by developer engagement, including pull requests (PRs) and code reviews. Only repositories with over 10% of the total developer activity are considered, highlighting areas of significant work.

Insights:

This analysis can identify knowledge islands, showing where specific developers have concentrated their efforts. This helps manage expertise distribution and promotes better collaboration and knowledge sharing.

Top Code Languages

Among the merged PRs coded by the individual developer in the last 6 months, we calculate the percentage of lines written for each programming language relative to the total lines across all PRs. We account for excluded file patterns and only display programming languages with a percentage above 10%.

Insights:

This analysis provides several valuable insights:

• Expertise and Focus: Understand the developer's expertise and areas of focus by highlighting the languages they are most proficient in and where they have made the most significant contributions.
• Frontend vs. Backend: Reveal any imbalances between frontend and backend work, helping to ensure a more balanced distribution of efforts.
• Adoption of New Languages: Track the adoption of new languages, such as transitioning from JavaScript to TypeScript, to see how quickly and effectively new technologies are being integrated.
• Strength Recognition: By understanding these metrics, teams can better recognize the developer's strengths and allocate resources effectively.Calculation:

Development experience

The development experience graph tracks:

• The developer's individual pickup wait time for the time period (how long did PRs they create sit before being picked up)
• How long their PRs waited before being merged
• How long their merged code waited before being deployed

The top graph in each category represents the values for the current time period. The gray graphs below represent that value for the previous time period, so that you can track changes over time.

Wellness workload

The wellness workload graph tracks the size of a developer's PRs per-branch. This allows you to see how the developer work is spread across the selected time period. How many lines of code a developer is committing, and whether it's broken up into appropriately small PRs. If not, you can dig in to why:

• Are our stories not broken into small chunks of work, forcing large PRs?
• Is this teammate just on a code-heavy week and feeling good?
• Do we need to set expectations with the team on best practices for their PRs, and perhaps set a team goal around PR size?

Developer metrics

This spider chart shows metrics associated with the individual developer as both a PR submitter and a PR reviewer.

Reviewer metrics include:

• Reviews
• Review depth
• Pickup time

Submitter metrics include:

• PRs opened
• PR size
• PR maturity

This allows you to understand the strengths and challenges each individual developer is facing. For example, are they writing small, manageable PRs—and a lot of them? Then you might see them picking up fewer reviews in that time period.

Similarly, a senior dev may be reviewing a ton of reviews, and doing so in-depth and quickly—but as a result, they may have fewer PRs opened. Or, a team member might be in the middle of the pack on all of the metrics: they're a good team player helping both create new code and review their peers' PRs.

This isn't intended as a performance measuring tool. After all, a team needs all three kinds of developers in most cases. But it can be good to validate stress points for a developer and make sure that your team is spending the time where it's most valuable for your overall goals (maybe the senior developer needs to assign some of the reviews to mid-career teammates to work on a really important piece of architectural work). These graphs can help facilitate those conversations.

Hovering over any point on the graph will show you more info on that metric:

And checking the second and third radio buttons will allow you to compare that developer's work split to another team or to every developer at the org:

This can be especially helpful for showing onboarding teammates how they're progressing relative to peers, giving them reassurance that they're spending their time on the right tasks.