> "Lines of Code are Not a Measure of Productivity in an Isolated, Toy Example"
Calling this phenomenon a toy example is a bit out of touch. I've seen this every single day of my 25 year career. Value is produced by solving problems, not writing code. The solution with fewer lines of code, fewer new abstractions, lower complexity (yes, complexity IS objective and quantifiable) is invariably the best solution. Solutions that involve no code at all are the gold standard.
Adding/subtracting the right code produces value. But adding the wrong code decreases value. The logic of "productivity as code" contains a fatal flaw - it ignores this and assumes all code is right. Reality: everything hinges on the right vs wrong distinction which is inherently subjective. Code is too often a net liability - you must account for the risk!
By contrast, the "productivity as solving problems" approach is entirely objective. You can observe the problem, test hypotheses about the cause, and measure the situation after the intervention. A well stated problem has no ambiguity.
I don't see any support whatsover for the "productivity as code" idea. It's empirically false and lacks logical consistency.
Calling this phenomenon a toy example is a bit out of touch. I've seen this every single day of my 25 year career. Value is produced by solving problems, not writing code. The solution with fewer lines of code, fewer new abstractions, lower complexity (yes, complexity IS objective and quantifiable) is invariably the best solution. Solutions that involve no code at all are the gold standard.
Adding/subtracting the right code produces value. But adding the wrong code decreases value. The logic of "productivity as code" contains a fatal flaw - it ignores this and assumes all code is right. Reality: everything hinges on the right vs wrong distinction which is inherently subjective. Code is too often a net liability - you must account for the risk!
By contrast, the "productivity as solving problems" approach is entirely objective. You can observe the problem, test hypotheses about the cause, and measure the situation after the intervention. A well stated problem has no ambiguity.
I don't see any support whatsover for the "productivity as code" idea. It's empirically false and lacks logical consistency.