Don't Measure Code Stats

While Software Engineers love to look at data, not all data is equal. While ensuring your team remains productive is important, you must look at valuable indicators when evaluating productivity.

Throughout my career, I’ve seen many metrics used to measure the “productivity” of an engineer including but not limited to:

1. Number of code changes submitted

2. Number of bugs closed

3. Average number of comments received on code changes

4. Average number of revisions before submitting code changes

5. Average lines of code per change

6. Number of lines of code reviewed

7. Hours of meetings attended

Typically these metrics were measured and evaluated over some time period like weekly, monthly, quarterly, or yearly. While I believe it’s possible that these data points could be an indicator of an engineer’s productivity, they don’t paint the entire picture.

For example, these metrics can’t capture the value an engineer’s design document provides for a team and its roadmap, the amount of money recouped after a one-line config change saves eighteen percent CPU utilization across a fleet of servers, or the documentation created to onboard new engineers to a team’s tech stack faster.

Because of examples like these, as well as the stress it can place on a team, I largely disagree with leaning on these or similar metrics. Furthermore, and most importantly, measuring bad statistics for engineers is not just illogical, but it’s counterproductive. Instead of focusing on doing good work, your engineers will now start gaming the system.

A widely called method can be renamed to be more specific? An engineer will happy jump on this to create a quick three-hundred-line change to boost their lines of code. A small change can be broken up into multiple changes? Another engineer will do this to boost the number of total code changes they’ve submitted.

Instead, managers should be able to easily tell when someone is not productive or producing enough value. This can be easily accomplished over time during normal weekly check-ins as well as during other project status update meetings. Sometimes life happens — someone gets sick, an unexpected roadblock pops up, etc. But if someone continuously fails to deliver either at the quality or cadence expected it shouldn’t be that hard to spot.

The bottom line is Software Engineers should not be monitored like a production application. Unlike a service, you don’t need to know the P99 of my code submissions.

Drop a like ❤️ and comment below if you made it to the end of the article.

50% off sale - Learn data structures and algorithms with The Daily Byte. Work through a single problem each day, delivered to your inbox, in an order that encourages learning as opposed to rote memorization.