Return to Answer

Committed line count is the measure I use. I find it is reasonably reliable. There is a big difference between a guy who is committing 15,000 lines a year and another who is committing 3,000 lines a year, and another who is committing 60,000 lines a year. Back in the day when I wrote a lot of code I maxed out at about 50,000 lines a year. The best programmers I have had personal experience with do about 200,000 lines a year. Guys that do that, the real burners, have to be very heads down and are hard to find. One guy I knew who was that level is a VP now and makes $500,000 a year.

You also have to take into account whitespace. There are some guys who put every brace on its own line, so you have to multiply by 0.8 to adjust for all the white space. In general, though, its just tweaking. Usually the good programmers will be producing double or triple or quadruple what the weakies do, so the whitespace doesn't really matter much in the long run.

The very first year I worked full time as a programmer I wrote an MS Access DB application. It took me the whole year to write it. After the whole thing was written and fully debugged and working, I did a line count. It was 400 lines of code. Nowadays, I could write that same application in a single day. Gives you some idea of the difference in skill. Nowadays, if I go all out, like its Goole Code Jam or something I can write about 1000 working/debugged lines a day, so in theory I could do 250,000 lines a year if I did nothing but program. Of course, I spend all my time now going to meetings, writing specs, winning new business and answering questions on SO, so I do a lot less than that.

Because of this last factor, you have to weigh what the person is actually doing. Do you have them spending weeks writing specs or help files? That is going to hit their line count. Are they talking to clients or bidding for business. Ditto. The line count is mainly an accurate measure for guys who are strictly coding.

Note that you have to take into account what phase the project is in. If the project is new, the line count will be a lot higher than an old project that is getting debugged. Also, as projects get big and hairy, the line count decreases somewhat.

You will find some "manglers" out there who have the idea that measuring by commit count will encourage people to commit junk code, but in practice that is not what happens. Anyone who commits a lot of junk ends up wasting a lot of time debugging, so they don't really gain anything by committing junk. In general, the more productive a coder is, the higher quality their code is, and in fact, it has to be. If you are writing 1000 lines a day, they better be GOOD or you will spend a lot of time debugging.

Committed line count is the measure I use. I find it is reasonably reliable. There is a big difference between a guy who is committing 15,000 lines a year and another who is committing 3,000 lines a year, and another who is committing 60,000 lines a year. Back in the day when I wrote a lot of code I maxed out at about 50,000 lines a year. The best programmers I have had personal experience with do about 200,000 lines a year. Guys that do that, the real burners, have to be very heads down and are hard to find. One guy I knew who was that level is a VP now and makes $500,000 a year.

You also have to take into account whitespace. There are some guys who put every brace on its own line, so you have to multiply by 0.8 to adjust for all the white space. In general, though, its just tweaking. Usually the good programmers will be producing double or triple or quadruple what the weakies do, so the whitespace doesn't really matter much in the long run.

The very first year I worked full time as a programmer I wrote an MS Access DB application. It took me the whole year to write it. After the whole thing was written and fully debugged and working, I did a line count. It was 400 lines of code. Nowadays, I could write that same application in a single day. Gives you some idea of the difference in skill. Nowadays, if I go all out, like its Goole Code Jam or something I can write about 1000 working/debugged lines a day, so in theory I could do 250,000 lines a year if I did nothing but program. Of course, I spend all my time now going to meetings, writing specs, winning new business and answering questions on SO, so I do a lot less than that.

Because of this last factor, you have to weigh what the person is actually doing. Do you have them spending weeks writing specs or help files? That is going to hit their line count. Are they talking to clients or bidding for business. Ditto. The line count is mainly an accurate measure for guys who are strictly coding.

Note that you have to take into account what phase the project is in. If the project is new, the line count will be a lot higher than an old project that is getting debugged. Also, as projects get big and hairy, the line count decreases somewhat.

You will find some "manglers" out there who have the idea that measuring by commit count will encourage people to commit junk code, but in practice that is not what happens. Anyone who commits a lot of junk ends up wasting a lot of time debugging, so they don't really gain anything by committing junk. In general, the more productive a coder is, the higher quality their code is, and in fact, it has to be. If you are writing 1000 lines a day, they better be GOOD or you will spend a lot of time debugging.

------Postscript

I think it is pretty comical that the number one answer says there is no way to quantify programming skill/productivity and then recommends that you have a lot of meetings. LOL. The icing on the cake is that the guy is from London, the epicenter of the program-by-having-meetings world.

I guess I should modify my answer somewhat. I was assuming that what you were trying to do is write working computer programs. If you work for a big, rich, entitled company where the goal is to maximize employment, make your government happy, be green, and have a wholesome work environment where everybody is social and nice to everybody, then by all means have lots of the meetings, that's the secret to success. Measuring people is bad, might make them feel inferior, can't have that.

Committed line count is the measure I use. I find it is reasonably reliable. There is a big difference between a guy who is committing 15,000 lines a year and another who is committing 3,000 lines a year, and another who is committing 60,000 lines a year. Back in the day when I wrote a lot of code I maxed out at about 50,000 lines a year. The best programmers I have had personal experience with do about 200,000 lines a year. Guys that do that, the real burners, have to be very heads down and are hard to find. One guy I knew who was that level is a VP now and makes $500,000 a year.

You also have to take into account whitespace. There are some guys who put every brace on its own line, so you have to multiply by 0.8 to adjust for all the white space. In general, though, its just tweaking. Usually the good programmers will be producing double or triple or quadruple what the weakies do, so the whitespace doesn't really matter much in the long run.

The very first year I worked full time as a programmer I wrote an MS Access DB application. It took me the whole year to write it. After the whole thing was written and fully debugged and working, I did a line count. It was 400 lines of code. Nowadays, I could write that same application in a single day. Gives you some idea of the difference in skill. Nowadays, if I go all out, like its Goole Code Jam or something I can write about 1000 working/debugged lines a day, so in theory I could do 250,000 lines a year if I did nothing but program. Of course, I spend all my time now going to meetings, writing specs, winning new business and answering questions on SO, so I do a lot less than that.

Because of this last factor, you have to weigh what the person is actually doing. Do you have them spending weeks writing specs or help files? That is going to hit their line count. Are they talking to clients or bidding for business. Ditto. The line count is mainly an accurate measure for guys who are strictly coding.

Note that you have to take into account what phase the project is in. If the project is new, the line count will be a lot higher than an old project that is getting debugged. Also, as projects get big and hairy, the line count decreases somewhat.

Committed line count is the measure I use. I find it is reasonably reliable. There is a big difference between a guy who is committing 15,000 lines a year and another who is committing 3,000 lines a year, and another who is committing 60,000 lines a year. Back in the day when I wrote a lot of code I maxed out at about 50,000 lines a year. The best programmers I have had personal experience with do about 200,000 lines a year. Guys that do that, the real burners, have to be very heads down and are hard to find. One guy I knew who was that level is a VP now and makes $500,000 a year.

You also have to take into account whitespace. There are some guys who put every brace on its own line, so you have to multiply by 0.8 to adjust for all the white space. In general, though, its just tweaking. Usually the good programmers will be producing double or triple or quadruple what the weakies do, so the whitespace doesn't really matter much in the long run.

The very first year I worked full time as a programmer I wrote an MS Access DB application. It took me the whole year to write it. After the whole thing was written and fully debugged and working, I did a line count. It was 400 lines of code. Nowadays, I could write that same application in a single day. Gives you some idea of the difference in skill. Nowadays, if I go all out, like its Goole Code Jam or something I can write about 1000 working/debugged lines a day, so in theory I could do 250,000 lines a year if I did nothing but program. Of course, I spend all my time now going to meetings, writing specs, winning new business and answering questions on SO, so I do a lot less than that.

Because of this last factor, you have to weigh what the person is actually doing. Do you have them spending weeks writing specs or help files? That is going to hit their line count. Are they talking to clients or bidding for business. Ditto. The line count is mainly an accurate measure for guys who are strictly coding.

Note that you have to take into account what phase the project is in. If the project is new, the line count will be a lot higher than an old project that is getting debugged. Also, as projects get big and hairy, the line count decreases somewhat.

You will find some "manglers" out there who have the idea that measuring by commit count will encourage people to commit junk code, but in practice that is not what happens. Anyone who commits a lot of junk ends up wasting a lot of time debugging, so they don't really gain anything by committing junk. In general, the more productive a coder is, the higher quality their code is, and in fact, it has to be. If you are writing 1000 lines a day, they better be GOOD or you will spend a lot of time debugging.

Committed line count is the measure I use. I find it is reasonably reliable. There is a big difference between a guy who is committing 15,000 lines a year and another who is committing 3,000 lines a year, and another who is committing 60,000 lines a year. Back in the day when I wrote a lot of code I maxed out at about 50,000 lines a year. The best programmers I have had personal experience with do about 200,000 lines a year. Guys that do that, the real burners, have to be very heads down and are hard to find. One guy I knew who was that level is a VP now and makes $500,000 a year.

You also have to take into account whitespace. There are some guys who put every brace on its own line, so you have to multiply by 0.8 to adjust for all the white space. In general, though, its just tweaking. Usually the good programmers will be producing double or triple or quadruple what the weakies do, so the whitespace doesn't really matter much in the long run.

The very first year I worked full time as a programmer I wrote an MS Access DB application. It took me the whole year to write it. After the whole thing was written and fully debugged and working, I did a line count. It was 400 lines of code. Nowadays, I could write that same application in a single day. Gives you some idea of the difference in skill. Nowadays, if I go all out, like its Goole Code Jam or something I can write about 1000 working/debugged lines a day, so in theory I could do 250,000 lines a year if I did nothing but program. Of course, I spend all my time now going to meetings, writing specs, winning new business and answering questions on SO, so I do a lot less than that.

Note that you have to take into account what phase the project is in. If the project is new, the line count will be a lot higher than an old project that is getting debugged. Also, as projects get big and hairy, the line count decreases somewhat.

Committed line count is the measure I use. I find it is reasonably reliable. There is a big difference between a guy who is committing 15,000 lines a year and another who is committing 3,000 lines a year, and another who is committing 60,000 lines a year. Back in the day when I wrote a lot of code I maxed out at about 50,000 lines a year. The best programmers I have had personal experience with do about 200,000 lines a year. Guys that do that, the real burners, have to be very heads down and are hard to find. One guy I knew who was that level is a VP now and makes $500,000 a year.

You also have to take into account whitespace. There are some guys who put every brace on its own line, so you have to multiply by 0.8 to adjust for all the white space. In general, though, its just tweaking. Usually the good programmers will be producing double or triple or quadruple what the weakies do, so the whitespace doesn't really matter much in the long run.

The very first year I worked full time as a programmer I wrote an MS Access DB application. It took me the whole year to write it. After the whole thing was written and fully debugged and working, I did a line count. It was 400 lines of code. Nowadays, I could write that same application in a single day. Gives you some idea of the difference in skill. Nowadays, if I go all out, like its Goole Code Jam or something I can write about 1000 working/debugged lines a day, so in theory I could do 250,000 lines a year if I did nothing but program. Of course, I spend all my time now going to meetings, writing specs, winning new business and answering questions on SO, so I do a lot less than that.

Because of this last factor, you have to weigh what the person is actually doing. Do you have them spending weeks writing specs or help files? That is going to hit their line count. Are they talking to clients or bidding for business. Ditto. The line count is mainly an accurate measure for guys who are strictly coding.

Note that you have to take into account what phase the project is in. If the project is new, the line count will be a lot higher than an old project that is getting debugged. Also, as projects get big and hairy, the line count decreases somewhat.