Ok, the question is usually, how can one measure a programmer's productivity.
But I want to put a slight twist on the question. How does one measure one's own productivity when coding? Do you measure yourselves by problems solved, questions answered versus asked, or the dreaded "lines of code"?
This is one of the banes and unsolvable problems in our profession. It is a landmine and quagmire.
The real measure is the quality of the product - and that can take years to evaluate.
There are so many problems with lines of code or other measurements. Developers, knowing they are being measured by some metric, will produce for that measurement.
This is not ideal. Lots of lines of code is NOT good compared to fewer lines, but if you are measured by lines of code you will produce lots of lines of code.
Very early in my career I asked my manager about when I could feel like I could go home - basically your question of productivity.
He said to me something like:
"If you feel you accomplished something - then it was a good day"
I measure by the done things that come back to haunt me. The less the better.
You might want to see the answers to this question What is a fair productivity measurement technique for programmers?
Also take a look at books like Peopleware (or indeed anything by Tom DeMarco) - measuring productivity of knowledge workers is inherently difficult.
The right measure is the accuracy of delivery vs. prediction. If you say that you will deliver X features by Y date at Z cost, the variance of actual X, Y, Z is what measures your quality as a programmer.
Whenever you make a commitment to someone, write it down, then go back and look at how accurate your commitments and estimates are. Refine your process to make them as realistic as possible.
In defense of lines of code... Maybe we could say, productivity is directly proportional to the lines of code you create, given that the lines are all necessary and not superfluous. Like, nothing can be removed.
But that type of statement defeats the easiness given by counting lines of code.
Lines of code is an absolute error to be used as measurig programmers productivity.
There may be a smart programmer that finds ways to encapsulate behaviour so well that he can produce multiple classes just inheriting it from a couple of abstract classes and adding differential behaviors methods. Hence not re-programming the whole object every time.
There may be not-so-smart programmers that just can't figure out how to put together similar behavior and do the copy/paste/then-slightly-change here and there approach; resulting in tons of lines of codes, tons of items to be reviewed when there are changes and tones of error prone risks by not having properly replaced the pasted code in the few pieces where it was suppossed to change variable or name.
So, definitely, lines of code are (and have always been, even in the COCOMO times) the worst way to measure a programmers effectiveness.
IMO, SLOCs is a useful metric, when used properly.
We don't use it to measure individual programmer productivity (in fact, there is no such measurement at all used by the company, I do, however, occasionally try to estimate whether we are doing good, in the projects I manage).
However, occasionally during a project, just to see how well we are doing, I compare the team's total output over a given period of time with the total SLOCs. If we're below 1000, I usually discuss this with the team, since I think we have a problem.
What makes this dreaded metric usable for us? The team is stable, people are working highly collaborative, and we mostly work based on pretty detailed designs done ahead of coding. As such, individual programmers don't have much influence on the program's architecture (at coding time, coding doesn't start until programmers are happy with the design). Since there's not much room for improvement on an existing design, other than changing the design itself, programmer effort is pretty much proportional to SLOCs, productivity isn't assessed for individuals but for teams, and code quality problems are treated as a much larger problem than productivity, SLOCs are a proper metric for assessing overall team productivity.
Essentially, I think that SLOCs are a good metric for programmer productivity only when being able to strongly control code quality by other means, when it isn't applied to individuals and when individual programmers have little influence on design, or the influence of design on productivity should not be factored into the productivity estimation.