This morning I had the opportunity to chat with software engineers and data scientists at the AI Dev World Conference on a topic I just happen to be v...
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 productivity 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 productivity and performance as developers.
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.
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.
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.
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:
Meet Andrew. He’s our Director of Backend Engineering and is a member of Team Bolt ⚡️ who is currently working on buildi...
Meet Mike. He’s a Platform Operations Engineer here a Pinpoint and member of Team Bolt ⚡️ . who is currently working on ...