Recommended Free Tools
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
I used to treat a busy diff as evidence that I was becoming a better programmer. More code seemed to mean more progress. I no longer use that shortcut: the amount I write says little on its own about whether the work solves the right problem, is dependable, or can be changed safely.
Why code volume looked like a useful measure
Code is visible. A commit has a count, a diff has a size, and a long session can leave behind a tangible result. When I was unsure how to judge my progress, those things offered a simple answer: I had written a lot, so I must have done a lot.
But activity and ability are not the same thing. A large change can reflect a necessary feature, an overcomplicated solution, or rework. A small change can remove a source of bugs or make a confusing system easier to maintain. The count describes how much text changed; it does not tell me whether the change was useful.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problemsWhat I look for instead
Does the change produce a useful result?
I ask whether the software now does something people need, whether the change works as intended, and whether it addresses the underlying problem. A large implementation that misses the need is not a success just because it took effort. A small fix that reliably removes a painful failure can be valuable.
Can the code be understood and maintained?
I pay attention to whether the solution is sound and whether I or another developer can work with it later. Readability, clear boundaries, tests where appropriate, and the ease of making the next change matter more than the amount of code added. This is not a claim that fewer lines are always better; it is a reminder that the line count does not settle the question.
How much friction did the work involve?
Speed matters, but so does how difficult it is to do good work. I notice whether I can make progress without needless setup, confusing processes, or repeated obstacles. A team that ships quickly by exhausting people or accumulating avoidable rework has not necessarily improved its overall productivity.
Is the pace sustainable?
I also consider whether the way I work leaves room to keep learning, focus, and recover. If a measure rewards visible output while ignoring the conditions that make good work possible, it can push me toward activity for activity’s sake. My own sense of progress includes both the result and whether I can continue producing careful work.
Why one number cannot capture programming ability
The SPACE framework makes the broader point that developer productivity is about more than individual activity or the efficiency of engineering systems, and cannot be measured with a single metric or dimension. Its authors—Nicole Forsgren, Margaret-Anne Storey, Chandra Maddila, Tom Zimmermann, Brian Houck, and Jenna Butler—published the framework in ACM Queue in February 2021. Read the SPACE article in ACM Queue.
Rank #3
That is useful context for my personal shift, not a scorecard for an individual programmer. SPACE concerns productivity across developers and engineering contexts; it does not establish a validated test of my programming ability. The same caution applies to other productivity frameworks: they can help explain what an organization should examine without dictating a universal personal ranking.
DORA’s Core Model, for example, brings together capabilities, metrics, and outcomes from its research program and annual reports. DORA describes it as a conservative guide for practitioners that evolves over time, rather than a single measure of individual performance. See DORA’s Core Model and capabilities.
What research says about quality and productivity
A 2022 Google study examined developers at Google and reported that increases in perceived code quality tended to precede increases in perceived developer productivity in its lagged analysis; it did not find the reverse relationship in that analysis. That finding connects quality and perceived productivity in the study’s setting. It is not proof of a universal causal rule, an objective measure of skill, or a result that applies unchanged to every developer or team. Read the Google Research study.
The practical lesson I take is modest: quality belongs in the conversation about productivity, rather than being treated as a bonus after output. It still does not tell me to calculate a personal quality score. I use it as a prompt to look at whether the work holds up, not as another single number to chase.
Best Value
A wider view can include speed, ease, quality, and wellbeing
Microsoft Research’s EngThrive description, published in May 2026, presents Speed, Ease, and Quality as productivity dimensions and Thriving as a wellbeing guardrail. It pairs outcome-oriented measures with diagnostic submetrics and developer surveys. This is a description of a system developed and deployed across Microsoft’s engineering organization and presented in a research preprint, not an established universal standard. Read Microsoft Research’s EngThrive description.
I find the distinction helpful even outside a company-wide measurement system. Speed asks whether useful work gets delivered; ease asks what helps or hinders that work; quality asks whether the result is sound; and thriving asks whether progress comes at an acceptable human cost. None of those dimensions alone tells the whole story, and their relevance will depend on the work and the people doing it.
How I use this shift in practice
I have not replaced lines of code with a new personal productivity formula. Instead, I treat code volume as a description of activity, then ask a few more grounded questions about the work:
Free tools Windows power users keep installed
One-click scans. No signup required.
- What problem did the change solve, and for whom?
- Does the result behave as intended?
- Can someone understand and safely modify it later?
- What made the work easier or harder than it needed to be?
- Was the pace sustainable?
Those questions leave room for context. A maintenance fix, a new feature, and a design investigation may produce very different amounts of code while each requiring sound judgment. The point is not to minimize output; it is to stop treating output volume as a proxy for the quality or importance of the work.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
