In the early days of software engineering management, we didn't have good data. So we counted what we could see: Lines of Code (LOC). It seemed logical. A builder lays bricks; a coder writes lines. More lines equals more work, right?
Wrong. In fact, often the opposite is true.
The LOC Fallacy
Junior engineers solve problems by adding code. Senior engineers solve problems by removing it.
If Developer A writes a 500-line function to parse a CSV, and Developer B imports a library and does it in 5 lines, who was more productive? Developer B shipped faster, introduced fewer potential bugs, and created less technical debt to maintain. But on a LOC dashboard, they look lazy.
What actually indicates impact?
Instead of raw volume, we need to look at the nature of the contribution.
1. Complexity and Churn
Velocinator looks at "Impact" by weighing changes based on the file's history and complexity. Editing a core authentication module that hasn't been touched in months is higher impact than updating a CSS color variable or auto-generating a migration file.
2. Refactoring Ratio
Healthy codebases breathe. They expand and contract. We track deleted lines as a positive metric. A PR that removes 2,000 lines of dead code is a massive win for the team's long-term velocity.
3. Traceability
Does this code solve a user problem? By linking PRs to Jira tickets or GitHub Issues, we verify that the code serves a business purpose. High activity without traceability often indicates "gold plating" or unplanned work.
Use Metrics for Questions, Not Answers
Never use data to rank developers. Use it to ask better questions.
- "I see you wrote a huge amount of code this week but merged no PRs. Are you stuck on a massive refactor? Can we break it down?"
- "Your impact score is low, but you've reviewed 30 PRs. You're acting as a force multiplier for the team—thank you."
Context is king. Data is just the conversation starter.