As a Tech Lead on the application engineering team at Pinpoint, I work on front-end web products, including prototyping, developing new features, and architecture development. When I think about improving my performance as a software engineer, there are actually two things I focus on. The first is my individual performance, which generally comes down to code quality — in other words, how reliable, maintainable, and clear the code is. The second is how well I’m working with my team — how healthy the team dynamic is. That means there is a healthy workload balance, minimal or no bottlenecks around reviews, and all team members are contributing to progress towards our goals. 

At Pinpoint, we believe that there is a wealth of data available to engineering teams sitting idly in their systems.  We also believe that bringing this disconnected, unused data together can provide us meaningful insights that will help us become better engineers, better team members and ultimately build better software engineers, like me, are often looking for insights on how well they are doing, broken into metrics specific to their individual and team performance. In any discussion about metrics, we think it’s incredibly important to keep in mind that metrics should never be used in isolation, but remember that they are a good place to start conversations about performance and uncover trends in yourself and your team’s workflow. 

These metrics are helpful for engineers to look at on a weekly basis in order to see how they are trending and spot areas for improvement. Point-in-time information isn’t terribly useful, but looking at trends over the past 30, 60 or 90 days can reveal patterns. Are you getting better or worse? What areas might need improvement?

Looking at these trends with a sliding window approach can provide important feedback as we try to improve our efficiency and quality of our work. These metrics are also valuable for managers or leadership when looking at across teams and even across the entire organization to identify larger areas of improvement or investments needed to support the business. 

Here are the seven metrics I think are most important for tracking and improving our performance as developers. 

Code Quality Metrics

Delivering code that is up to the expected team standards, as bug-free as possible, easy to maintain and for other engineers to understand, is a core part of an engineer’s job. But there are a number of things that contribute to the code’s overall quality. Pinpoint brings these metrics together along with data from the entire software lifecycle, from the pull request process through code in production. Here are the four metrics I look at to help me understand the quality of the code I am delivering: 

1. Code coverage measures how much of the code has been tested during the testing process. The higher this number, the better. This is important because the more code is tested, the less likely it is to introduce bugs into the production environment and the easier it will likely be to maintain over the long run.

2. Code complexity is important because simple code is easier to maintain and easier for other engineers to work in. More experienced engineers tend to write simpler code. Lower code complexity is better. 

3. Code churn measures what percentage of the original code has to be reworked during reviews. The lower the churn, the better — that means reviewers don’t need to change much and it’s production-ready. Low code churn generally indicates that the engineer is writing good code from the beginning. 

4. Defect ratio tells you whether you’re creating more bugs than you’re closing. If so, there’s a quality issue somewhere in the pipeline. It’s also a sign of how effective the team is at catching bugs during the review and testing phase. Nonetheless, a lower defect ratio points to an individual engineer’s ability to write solid code. 

This gets us into the team measures — even defect ratio and code churn aren’t really strictly individual metrics, but there is a line when the metrics start to measure team health, at least as much if not more than, individual performance. 

Team Performance Metrics

These measures help me understand how well I work with other developers —  maintaining a healthy workload balance and minimal or no bottlenecks in our workflow. 

5. Merge time is the time it takes a pull request to be merged into the main branch. No one wants to see their code sitting around getting stale — and the longer it takes to merge code, the more likely it is that the main branch will have moved forward already, leading to rework and further delays. However, this depends on too many team factors to be a purely individual metric. 

6. Pull request review distribution measures how many people on the team are reviewing pull requests. It’s important for pull request reviews to be a true team activity and not fall entirely to one or two team members. Tools like Github’s round robin pull request review feature can help teams ensure everyone is contributing to reviewing PRs. 

7. Cycle time measures the fundamental capability of a software team, or the timely completion of issues. This is the “meta-metric” because it is calculated using many of the metrics above. Shorter cycle time indicates an optimized development process and faster time to market. Longer (or lengthening) cycle time may signal an understaffed team or inefficiencies in the team or process. You can learn more about how we calculate cycle time here

Using These Engineering Metrics for Incremental Improvement

I look at these metrics as a way to improve my mastery of my craft, which has both individual and team components. The best way to move these metrics in the right direction is usually by increasing coaching, mentorship and education. As engineers, there is always something new we can be learning, whether it’s a new way to manage our workflow, a new tool or a new platform. Using these metrics helps identify places we can look for additional opportunities for professional development. 

Looking for more engineering metrics? We recommend the following posts:

 


Get the data science behind high-performance teams.