This blog post is part of the series – Rethinking Metrics: Avoid These Common Pitfalls in Measuring Software Engineers.

In the world of software development, the performance of engineers often becomes a topic of discussion. Managers and organizations seek tangible ways to evaluate contributions, and metrics like code commits and code reviews are frequently considered. However, relying on these metrics to assess software engineers’ performance is not only reductive but also harmful to team dynamics and long-term project success.

Why Code Commits and Code Reviews are Bad Metrics

1. Code Quantity Does Not Equate to Code Quality

Using the number of commits as a measure of productivity incentivizes quantity over quality. Engineers may feel pressured to create many small commits or inflate their contribution with unnecessary changes to appear productive. This can lead to bloated codebases, technical debt, and reduced focus on writing clean, maintainable code.

Moreover, not all engineering tasks require the same amount of code. Refactoring, debugging, and optimizing existing code often result in fewer commits but are critical for the health and scalability of a project.

2. Code Reviews Reflect Collaboration, Not Individual Skill

While code reviews are essential for maintaining code quality and knowledge sharing, the number of reviews performed or comments made does not directly correlate with an engineer’s skill. Some engineers may excel at reviewing complex algorithms, while others may focus on broader architectural decisions or mentorship through reviews.

Incentivizing reviews as a metric can lead to superficial or excessive feedback that adds little value. Effective code reviews prioritize quality insights, not the volume of comments.

3. Context Matters—And Metrics Lack It

Metrics like commits and reviews fail to capture the context of an engineer’s contributions. For example:

• Role Diversity: Senior engineers often spend more time mentoring, designing architectures, or aligning with stakeholders, leading to fewer commits.
• Project Complexity: Some projects require deep problem-solving and innovation, which may not result in immediate code output.
• Cross-Functional Contributions: Engineers may contribute through documentation, automation, or process improvements—activities that are invaluable but not directly tied to code metrics.

4. Encourages Unhealthy Competition

Metrics-based evaluation fosters competition rather than collaboration. Engineers may prioritize their individual output over helping teammates or addressing broader team goals. This undermines the collaborative spirit essential for agile and DevOps practices.

5. Ignores User Impact

The ultimate goal of software engineering is to deliver value to users. Metrics like commits and reviews focus on process rather than outcomes. An engineer who designs a feature that significantly improves user satisfaction or revenue may have a smaller number of commits compared to someone resolving routine bugs but has made a far greater impact.

A Better Approach to Evaluation

Instead of relying on shallow metrics, organizations should consider holistic and qualitative methods to evaluate software engineers, such as:

• Peer and Manager Feedback: Collect feedback on collaboration, problem-solving, and leadership qualities.
• Impact Measurement: Focus on the outcomes of their work, such as system reliability, user satisfaction, or business growth.
• Skill Development: Assess how engineers are improving their technical and interpersonal skills over time.
• Team Contributions: Evaluate their role in fostering a healthy, productive, and innovative team culture.

Conclusion

Code commits and code reviews are easy metrics to track, but they’re also misleading. Evaluating software engineers based on these numbers alone risks promoting harmful behaviors, overlooking meaningful contributions, and devaluing the qualities that drive long-term success. Organizations must adopt more thoughtful and comprehensive approaches to recognize the true value engineers bring to their teams and projects.

Join the Conversation

What are your thoughts on metrics for evaluating software engineers? Have you encountered challenges with metrics like code commits and reviews, or have you implemented better alternatives? Share your experiences and insights in the comments below—let’s rethink how we measure success in software engineering together!