And by 'code' I mean computer code: whether that be Java, C, Python, or LUA, ... the fact is that whatever the language, computer code is expensive.
Very junior level computer programmers can start at a bare minimum of 16k/pa (GBP; extrapolate for your region) and from there on it goes sky-high. At the bank, we start at 30000 GBP and end in 5 zeros. It works like this: You prove yourself and work hard for a year, then you go up a level, not before. [ By the time you're on the higher end of the pay scale, you'll be doing a lot more than just coding. ]
So, surely "more lines of code" equates to "more progress", no?
Taking a (very) short history detour: IBM programmers used to be paid by the number of 1000 lines of code they wrote. It didn't work out for IBM in the end; their programmers worked out how to structure a project to include more lines without really providing more functionality.
Gee, who would have thought.
In reality, it's not how many lines you code, it's what those lines get done. I suppose the mantra of "It's not the number of hours you do, it's what you get done that counts" is still very much the case here.
Let's think about it from a mathematical perspective: A general purpose programming language is Turing-complete in the sense that you could, in theory, complete any necessary task given enough time; it is mathematically adaptable enough to allow you to do anything. i.e. a task of "sum 2 numbers" can be done in an infinite number of ways. But that doesn't mean they are as useful as one another. You can build a castle from the ground up and add the artillery afterwards, or you can start by building the lavatories and finish with the upholstery. Which is better? I suppose it depends on who you are trying to impress...
When programming, a lot of the value is determined by how you get done what you are trying to get done. For a given problem X, you could solve it in a potentially unlimited number of ways (I guess this is a subsequence of being Turing-complete).
So the real question is: how do you choose to get something done out of the millions of different ways possible? Or to view it differently: you can get from point A to point B in any number of ways: why is that particular traversal better for your particular problem?
That's where the real value comes in: execution time, memory space, ability to understand it, ability to adapt it for future needs, ability to use it in other problems, etc.
Taking a (very) estimated guess, code from experienced programmers costs in the order of $10 per line, but it could be much more. Code that breaks often, code that can't be understood, code that does something other than intended, ... are basically not useful (and remember, there are an unlimited number of ways to code those as well).
The value lies in how you get there, not necessarily what it achieves. The future value of the code relies on so many other factors. Did they compensated for the possibility that the input data may not be as expected? Did they understand what the correct response would be in that case? Do we fail on the first bad input (a potentially difficult point to negotiate) or do we attempt to carry on? Was it well tested?
Technically, there are also questions on how it could be achieved quicker, with fewer resources, with a greater ability to scale, or just an easier way. In my experience, those problems are often secondary to other factors, at least at a higher level. Low-level optimization has typically already been performed for you, at least when working in a large firm with thousands of programmers, but you will still need to optimize the higher-level.
With back of the envelope calculations, I've estimated that 100 lines of raw code is easily worth $5k.
But I've also seen the most difficult bugs solved with just 1 line of code; how much is that worth?
And I've seen experienced programmers knock up a new service in 2000 lines in a couple of days and it just flies.
Any manager worth their salt knows - it's not about the number of lines, it's about what it gets done, and how.
