There’s a specific flavor of despair that hits when your manager slides a spreadsheet across the table and says, “Your commit count is down this quarter.” You stare at the numbers, and somewhere in the back of your mind, a tiny Fritz is screaming into the void. Because you know what those numbers don’t show: the three weeks you spent untangling a race condition that crashed production only on Tuesdays, the architecture overhaul that deleted 4,000 lines of spaghetti, or the ten hours you sat with a junior dev explaining why their O(n²) loop was a war crime against CPUs.
Engineering culture has a measurement problem. And no, I’m not talking about fuzzy stuff like “happiness” or “collaborative spirit”—I wouldn’t touch those words with a ten-foot patch cable. I’m talking about the hard, supposedly objective metrics that make managers feel like they’re running a factory floor instead of a team of humans who type for a living. Lines of code. Number of commits. Velocity points. These numbers aren’t just wrong; they’re actively destructive. They turn smart people into point-chasing hamsters and make codebases worse than a PHP script from 2003.
What Happens When You Measure the Wrong Thing
Let’s get one thing straight: measuring output isn’t inherently evil. Goodhart’s law gets quoted so often in tech circles it’s basically a meme, but people still ignore it. “When a measure becomes a target, it ceases to be a good measure.” You’d think after decades of software pileups, we’d have learned. But nope. Every few years, some exec reads a book on manufacturing efficiency and decides engineers are just assembly-line workers with nicer chairs.
Incentivize lines of code, and you’ll get lines of code. Lots of them. Devs will inflate boilerplate, dodge abstractions, copy-paste entire functions, and soon your codebase looks like it was typed by a drunk Markov chain. Incentivize commit count, and you’ll get micro-commits. “Fixed typo.” “Added comment.” “Removed whitespace.” The git history becomes a landfill of noise that makes git blame useless and git bisect a form of self-harm.
I once worked on a team with a brilliant senior dev who realized his quarterly review depended on commit count. Within two weeks, he’d automated a process that split every logical change into six separate commits. His numbers went through the roof. The codebase? No better. The team? Not shipping faster. But the spreadsheet looked fantastic. That’s not engineering. That’s performance art for middle management.
The Invisible Work That Actually Matters
Most engineering work is invisible to simple metrics. Debugging a memory leak that only manifests when the moon is in retrograde? Zero lines added—maybe even negative lines if you delete the offending garbage. Mentoring a junior engineer who’s about to quit because they feel incompetent? Zero commits. Designing a database schema that won’t explode in two years? Maybe a few SQL files, but the real work happened in your head, on a whiteboard, or in a heated Slack thread at 11 PM.
These activities are the difference between a team that survives and one that thrives. But they don’t show up in a burndown chart. They don’t generate green squares on GitHub. So they get devalued. Over time, the engineers who do this invisible work either stop doing it—why bother?—or they leave. What’s left is a crew of optimization bots who churn out code like it’s a bodily function, and a codebase that rots from the inside out.
Commits as a Status Symbol
Look at any developer’s GitHub contribution graph. Those little green squares are basically a Fitbit for typing. People game the hell out of them. They’ll push meaningless commits on weekends to keep a streak alive. They’ll fork repos and commit README changes just to paint the lawn green. I’ve seen people write scripts that auto-commit a timestamp to a private repo every day. That’s not productivity. That’s a cry for help.
The commit-count culture sets up a perverse incentive. It rewards activity over impact. A developer who spends a week researching a library, reading docs, and then writes a ten-line integration that solves the problem perfectly? That’s a “lazy” week on the spreadsheet. Another dev who spends that same week writing 2,000 lines of their own half-baked implementation that breaks in production? That’s a hero. The spreadsheet says so.
I remember a project where we had to migrate a massive legacy database. The engineer who did the work spent two weeks analyzing schemas, writing migration scripts, testing rollback procedures, and documenting everything. Total lines added: maybe 200. Total commits: 12. Meanwhile, a dev on a parallel track wrote a feature with 3,000 lines of React components and 50 commits. Guess who got the promotion? The React cowboy. The migration engineer saved the company from a data-loss catastrophe, but nobody saw it because the work didn’t “show up.”
Why Velocity Points Are Also Nonsense
Agile teams love story points. They’re supposed to be abstract, relative estimates of effort. But give it three sprints, and some product owner is dividing points by hours and asking why velocity dropped from 30 to 28. Same disease, different skin. Points become a currency, and engineers start negotiating them like they’re haggling at a bazaar. “This ticket is at least an 8.” “Can’t we split it into three 3s?” Congratulations, you’ve turned software development into a game of Fibonacci poker.
The real crime is that velocity gets compared across teams. Team A has a velocity of 50, Team B has 30. Therefore, Team A is “faster.” No, Team A just inflates their estimates. Or they’re working on simpler tasks. Or they’ve got a senior dev who can crank out boilerplate at lightning speed. Velocity is a team-internal calibration tool. The moment you expose it to sunlight, it turns into a vampire and starts sucking the honesty out of planning.
The Deeper Problem: Engineering Culture as a System Failure
Here’s where I get blunt. The obsession with measuring engineers by lines of code or commits isn’t just a management mistake. It’s a symptom of a broken engineering culture that doesn’t understand itself. We’ve let people who can’t read code define what “good” code looks like. We’ve let project managers who’ve never debugged a null pointer set the standards for technical work. And we’ve accepted it because, honestly, it’s easier to nod along than to explain why a ten-line refactor took three days.
Engineering isn’t manufacturing. You can’t count widgets because the widgets don’t exist. Software is abstract, creative, and often counterintuitive. The best code is the code you don’t write. The best engineer is often the one who deletes the most. But deletion is a negative metric. It makes the line-count go down. It makes the commit history look like a retreat. In a culture that worships addition, subtraction is a sin. And that’s why we have codebases with 17 layers of abstraction for a CRUD app.
This culture problem feeds itself. Managers hire for “output” because that’s how they’re evaluated. Engineers optimize for those metrics because that’s how they get paid. The codebase gets worse, which creates more work, which requires more hiring, which means more managers who only understand output. It’s a doom loop. And the only way out is to blow up the metrics entirely and start measuring what actually matters: outcomes, not output.
What Good Measurement Might Look Like
I’m not naive. I know organizations need some way to evaluate performance. So here’s a radical idea: measure the things that correlate with actual success. Did the feature ship on time and not break? Did the bug fix stay fixed? Did the team’s technical decisions reduce future maintenance burden? These are hard to quantify, sure. But so is code quality, and we don’t throw up our hands and stop trying.
One angle is to track customer outcomes. Did the work lead to faster load times? Fewer support tickets? Higher conversion? Engineers should be tied to the business impact of their work, not the volume of their typing. Another is peer review. Let the people who actually understand the work evaluate it. If three senior engineers say someone is doing great work, that’s worth more than a thousand green squares. It’s messy, subjective, and human. Exactly like engineering.
Some teams treat “negative line count” as a badge of honor. A refactor that removes 10,000 lines of dead code gets celebrated. A commit that simplifies a complex module gets a shout-out in standup. This flips the incentive: instead of rewarding addition, you reward clarity and simplicity. It takes a strong technical lead to push this culture, but when it works, it’s something to see.
What This Does to Engineers’ Brains
Let’s talk about the psychological toll. When you tell a creative, problem-solving human that their value is a number on a dashboard, something breaks. They start optimizing for the number instead of the problem. They stop thinking about architecture because architecture doesn’t commit. They stop refactoring because refactoring looks like standing still. They stop caring, because the system clearly doesn’t care about them.
I’ve seen brilliant engineers burn out because their deep work was invisible. They’d spend months designing a system that would save years of effort, and their reward was a mediocre review because their “velocity” was low. Meanwhile, the person who shipped a half-baked feature got a bonus. The message is clear: don’t do the hard stuff. Ship fast, break things, let someone else clean up. And then we wonder why technical debt is a trillion-dollar problem.
This is how you lose your best people. Not through layoffs or bad pay, but through a slow erosion of purpose. When engineers feel like assembly-line workers, they start acting like assembly-line workers. They clock in, crank out code, and clock out. Innovation dies. Ownership dies. And the company slowly becomes a place where mediocrity is the only survival strategy.
The Manager’s Dilemma
I have some sympathy for managers caught in this mess. They’re often under pressure from above to “prove” their team’s productivity. They don’t have time to read every pull request. Metrics feel like a lifeline—a way to show executives that the engineering department isn’t just a black hole of salary dollars. But the answer isn’t bad metrics. The answer is better storytelling. A good engineering manager can translate technical work into business terms without resorting to line counts. “We reduced page load time by 40%,” “We eliminated a class of bugs that caused 200 support tickets a month,” “We shipped feature X which drove a 5% increase in signups.” That’s what executives understand. Not commit graphs.
If you’re a manager and you’re reading this, here’s your homework: spend a week not looking at any metric. Instead, talk to your engineers. Ask what they did. Ask what was hard. Ask what they learned. Then go tell that story upward. It’s harder than copying a number from Jira, but it’s the actual job. Metrics are a crutch, and the crutch is breaking your team’s legs.
FAQ
Why do companies keep using lines of code if it’s so bad?
Because it’s easy. Counting lines of code or commits takes zero effort—you can pull it from a tool in seconds. Understanding the nuance of engineering work takes time, technical knowledge, and trust. Many organizations lack all three. There’s also an inertia problem: these metrics have been around for decades, and replacing them requires cultural change that most companies are too lazy to attempt. The irony is that the effort saved on measurement gets spent tenfold on fixing the bad code those metrics incentivized.
What’s a better way to measure individual engineer performance?
Focus on outcomes and impact, not output. Look at what the engineer’s work actually achieved: did it solve a user problem, reduce technical debt, improve system reliability, or help the team move faster? Peer feedback from other engineers is often more accurate than any metric because it captures the invisible work. Some teams use a lightweight regular review where engineers write a short summary of their impact, which gets calibrated in a group discussion. It’s not perfect, but it’s better than pretending commit counts mean anything.
Do story points in Agile have the same problem?
Absolutely. Story points were designed to be a relative estimation tool for a team to plan their own work. The moment they’re used to compare teams or evaluate individuals, they turn toxic. Engineers start gaming estimates, inflating point values, or arguing over whether a task is a 5 or an 8 instead of just doing the work. The core issue is the same as with lines of code: a metric meant for internal calibration gets hijacked as a performance indicator, and everyone loses.
What if my manager insists on using these metrics for my review?
You have a few options, none of them fun. First, try to educate: share articles, data, or anecdotes about how these metrics backfire. Frame it as helping the team, not criticizing the manager. If that fails, document your actual impact in a “brag doc”—a running list of your contributions, especially the invisible ones. Bring that to your review and make the case that your work matters even if the numbers don’t show it. If the organization still won’t listen, that’s a strong signal that the culture is broken, and you might want to polish your resume. Life’s too short to be a hamster on a wheel.
The bottom line: measuring engineers by lines of code or commits is like judging a chef by how many pots they dirty. It misses the point entirely, rewards the wrong behavior, and makes everyone miserable. The fix isn’t a new tool or a better formula. It’s a shift in how we think about engineering work—from factory output to creative problem-solving. Until that shift happens, we’ll keep getting the software we deserve.
