Why lines of code is a terrible productivity metric

Lines of code is the most tempting engineering metric because it's easy to count — and the most misleading because it measures the wrong thing. A senior engineer who deletes 500 lines and fixes a race condition in 20 shows as "negative productivity." A junior who commits a generated lockfile shows as a hero. That's backwards.

It rewards exactly the wrong behaviour

Optimise for lines and you get bloat: copy-paste over abstraction, verbose over concise, and nobody wants to delete dead code (it hurts their number). The best engineering — small, surgical, well-scoped changes — scores lowest.

Generated files drown out real work

A single regenerated schema, lockfile or snapshot can be thousands of lines and zero human effort. If your metric counts them, one machine-generated commit can outweigh a week of careful work. Any credible effort model has to detect and discount generated content.

What to measure instead

• Effort by content — infer the real work from what changed and its type, not the raw line count.
• Delivery — tickets finished and how cleanly (cycle time, reopens).
• Discount the noise — generated, lockfile and vendored dumps count for almost nothing.
• Credit the invisible — debugging and review that leave few lines are still real work.

truelo's effort estimate is content-based: it classifies each commit, caps and discounts generated dumps, and folds in self-reported non-code work — so a small high-impact change isn't punished and churn isn't rewarded.