I stopped treating lines of code as a measure of programming ability when I realized they tell me how much text I produced—not whether I solved the right problem, made the software dependable, or left it easier to change. I still notice code volume, but I no longer use it as a verdict on my skill.
Why code volume stopped feeling like a fair measure
For a while, a large change felt like evidence that I had done substantial engineering. A quiet day, a small patch, or deleting code could feel like evidence that I had done less. That equation was appealing because lines are visible and easy to count. But visible activity is not the same as useful work.
As an Amazon Associate I earn from qualifying purchases.
A change can add little and still remove a serious defect. A good solution may be a focused edit, a clarified interface, or code removed because the system no longer needs it. Conversely, a large addition can be difficult to maintain or fail to address the underlying problem. Volume describes the shape of a change; by itself, it does not explain its value.
The SPACE framework, published by Nicole Forsgren, Margaret-Anne Storey, Chandra Maddila, Tom Zimmermann, Brian Houck, and Jenna Butler in ACM Queue in February 2021, makes the broader point: “Developer productivity is about more than an individual’s activity levels or the efficiency of the engineering systems relied on to ship software, and it cannot be measured by a single metric or dimension.” Read the SPACE article in ACM Queue.
#1 Best Overall
That is a framework for thinking about developer productivity, not a validated test of an individual programmer’s ability. Its useful lesson for my own work is narrower: a single activity count cannot tell the whole story.
What I look at now when I judge my work
Did the change produce a useful result?
I start with the problem, not the diff. Did the change make the intended behavior work? Did it help someone complete a task, remove an obstacle, or make a system behave more reliably? The size of the implementation is secondary to whether it produced a useful, functioning result.
Rank #2
Is the result sound and maintainable?
Working code matters, but so does whether it can be understood and changed later. I pay attention to whether the solution fits the surrounding code, handles the relevant cases, and leaves a clear path for future maintenance. These are judgments about the work—not a claim that one simple quality score can summarize a developer.
Free tools Windows power users keep installed
One-click scans. No signup required.
A 2022 Google study is relevant here, with an important boundary: among Google developers in that study setting, increases in perceived code quality tended to be followed by increases in perceived developer productivity in a lagged analysis; the reverse relationship was not found. The result concerns perceived quality and productivity in that context. It does not establish a universal causal rule or measure my individual programming ability. See the study abstract from Google Research.
Rank #3
How much friction did the work involve?
Speed can matter, but speed alone does not tell me whether the environment made good work possible. Microsoft Research’s EngThrive description, published in May 2026, presents Speed, Ease, and Quality as productivity dimensions, with Thriving as a wellbeing guardrail. It pairs outcome-oriented measures with diagnostic submetrics and developer surveys. That is a description of a system developed and deployed across Microsoft’s engineering organization, not a universal standard or an individual scorecard. Read Microsoft Research’s EngThrive description.
For my own reflection, Ease prompts a practical question: could I make progress without avoidable friction? Thriving adds another: did the pace of work come at an unsustainable cost? Neither question has a single code-count answer.
Rank #4
What broader productivity frameworks can—and cannot—tell me
DORA’s Core Model combines capabilities, metrics, and outcomes drawn from its ongoing research program and annual reports. DORA describes it as a conservative practitioner guide that evolves over time. It helps teams reason about the conditions and results of software delivery; it is not a personal programming-ability score. Explore DORA’s Core Model.
SPACE and DORA are useful reminders that work happens within systems and teams, not in isolation. Microsoft Research’s EngThrive likewise combines system telemetry and developer surveys in its described approach. Those broader views can inform how I think about my work, but they do not prescribe one personal scorecard that everyone should use.
Best Value
A more useful personal check-in
When I finish a task, I try to ask questions that connect effort to outcomes without turning the answers into another rigid ranking:
- Result: What changed for the user, system, or team?
- Quality: Does the change behave as intended, and is it understandable enough to maintain?
- Flow: What helped or blocked progress?
- Sustainability: Could I do this work at a healthy pace?
These questions are prompts for reflection, not a universal metric set. Some work is exploratory; some is maintenance; some is valuable because it prevents a problem. The relevant evidence differs with the task. I do not need to turn every day into a numerical evaluation.
What changed—and what did not
I did not stop caring about code. I stopped asking it to prove more than it can. Lines written can describe activity, but they cannot independently establish whether a solution was useful, dependable, maintainable, or achieved under workable conditions.
For me, programming ability is better reflected in the judgment behind the change and the result it enables than in the volume of text it leaves behind. The research supports the limits of a single activity count; the turning point and this way of judging my own work are personal.
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.




