One developer writes 500 lines of code. Another writes 100.
Who accomplished more?
It’s an easy question to answer if you’re measuring output. It’s a much harder one if you’re measuring engineering value.
Baseball spent decades leaning heavily on a similarly simple statistic: batting average.
Hits divided by at-bats. It’s easy to calculate, easy to compare, and useful up to a point. But it can’t tell you everything you need to know about a player’s value.
Using lines of code as a productivity metric causes the same problem.
It can tell you how much code an engineer produced. It can’t tell you whether they solved the right problem, made a sound technical decision, or avoided unnecessary complexity.
That’s especially important when you’re hiring senior engineers, because sometimes the most valuable thing they can do is figure out that those 500 lines never needed to be written.
Batting average tells you something useful about a hitter. It just doesn’t tell you everything.
It doesn’t account for walks or hit-by-pitches. It also treats a single and a home run the same way: one hit in one at-bat.
You need more information to understand a player’s overall offensive contribution.
The same problem shows up when engineering organizations try to reduce developer productivity to a single, easily measured number.
Lines of code has an obvious appeal as a productivity metric. It’s objective, countable, and directly connected to something developers do.
But developers do much more than produce code.
In a chapter of Rethinking Productivity in Software Engineering, researchers Ciera Jaspan and Caitlin Sadowski argue that no single metric can capture developer productivity. Engineers review code, design systems, manage releases, and mentor teammates, all valuable work that may never show up in a code count.
Even when you’re only looking at code contributions, volume tells you very little about quality.
A 1,000-line solution isn’t inherently better than a 100-line solution. But 100 lines aren’t inherently better than 1,000 either.
The question is whether the code solves the problem well.
Consider what happened with Apple’s Lisa team in 1982.
Management began tracking how many lines of code individual engineers wrote each week. Around the same time, engineer Bill Atkinson rewrote part of QuickDraw using a simpler, more general algorithm.
The result? Region operations ran almost six times faster, and the rewrite eliminated roughly 2,000 lines of code.
So when Atkinson was asked to report how many lines he had written that week, his answer was:
-2,000.
By the metric, Atkinson had produced negative output. By any sensible assessment of the result, he had dramatically improved the software.
This matters when you’re hiring, too.
If you evaluate engineers primarily by the volume of code they produce, it’s easy to undervalue exactly the kind of judgment you’re trying to hire.
In 1982, Bill Atkinson had to explain why he’d written negative 2,000 lines of code.
Today, a developer can ask an AI coding assistant to generate 2,000 lines before lunch. We’ve made producing code dramatically easier. Figuring out whether that code is any good is another matter.
Research from DX across more than 500 engineering organizations found that the share of AI-authored code increased from 24% to 52.7% over three quarters. Median weekly pull-request throughput also increased 37% over four quarters.
However, developers’ confidence that their changes wouldn’t break something fell 6.1% over the period studied. AI helped teams produce more code, but that didn’t automatically translate into greater confidence in what they were shipping.
AI coding tools can accelerate development, reduce repetitive work, and help engineers move faster. But someone still needs to understand the problem, review the output, catch mistakes, and decide whether the proposed solution makes sense.
A developer who generates 5,000 lines of AI-assisted code hasn’t necessarily accomplished more than one who uses AI to deliver a clean, reliable solution in 500.
AI has changed how quickly we can produce code. It hasn’t changed what makes code valuable.
Give two developers the same problem and access to the same AI coding tools, and they may still approach it very differently.
A less experienced developer may start building immediately, whereas a senior engineer is more likely to interrogate the problem first.
Do we actually need to build this?
Can something we already have handle it?
Could the architecture be simpler?
What happens when this needs to scale?
Who will maintain it?
Does solving this problem here create another problem somewhere else?
Those questions can dramatically change what gets built.
Sometimes the result is 100 lines instead of 1,000. Sometimes it’s a small change to an existing component. Sometimes the right solution really does require 1,000 lines.
The amount of code isn’t the point. The quality of the decision behind it is.
Companies don’t hire senior engineers because they type faster.
They hire them for pattern recognition, technical judgment, architecture, prioritization, problem solving, and foresight.
Experienced engineers have seen more things go wrong.
They’ve seen the clever solution that became impossible to maintain. They’ve watched small architectural decisions become major bottlenecks. They know when something needs to be designed for scale and when a simpler solution will do the job.
That experience affects decisions before coding starts.
Senior engineers can also increase the effectiveness of the people around them. They identify problems during code reviews, establish better patterns, mentor less experienced developers, and push back when a proposed solution introduces unnecessary complexity.
A lines-of-code count captures none of that.
The answer isn’t to replace lines of code with another magic number. Engineering performance needs context.
When evaluating an engineer, we’d look at five areas.
Did the engineer solve the problem the business actually needed solved? A technically impressive solution isn’t particularly valuable if it addresses the wrong problem.
Did they choose an appropriate solution for the requirements, constraints, and stage of the product? Strong engineers know when sophistication is necessary and when it isn’t.
What did they leave behind? Good engineering shouldn’t create unnecessary complexity for the next person who has to work in the codebase.
How much direction does the engineer need to move a problem forward? For senior hires in particular, companies should be looking for people who can navigate ambiguity, identify tradeoffs, and make sound decisions without having every step prescribed.
Do they make the engineers around them better? Strong senior engineers improve code reviews, technical discussions, architecture decisions, and the work of less experienced developers. Their individual output may be only part of the value they create.
Nearshoring conversations often start with cost, and that’s understandable. Access to engineering talent at a different cost structure is part of the appeal.
But salary or hourly rate can be just as incomplete a measure of engineering value as lines of code.
Hiring three lower-cost developers isn’t automatically better than hiring two highly experienced ones. The reverse isn’t automatically true either.
The better question is: What level of engineering capability and judgment are we getting for our investment?
That’s where nearshoring gets interesting. The opportunity isn’t simply to find developers who cost less than equivalent U.S. hires. It’s to find engineers with the experience to solve difficult problems, make good decisions, and operate independently at a cost that makes sense.
Batting average isn’t a bad statistic. It just can’t tell you everything you need to know about a baseball player.
Lines of code has the same problem.
It can tell you how much code was added or removed. It can’t tell you whether an engineer solved the right problem, made a good architectural decision, avoided unnecessary complexity, or helped the rest of the team perform better.
When evaluating engineering talent, keep three things in mind:
If you want to understand the value of an engineer, don’t start by asking how much code they wrote.
Ask what got better because they were there.
Looking for senior engineering talent in Latin America? Talk to us about building your LATAM engineering team.
