A) One line of code in one language at a higher level of abstraction might be worth twenty in another language.
B) A poor programmer might write 10 lines of code when 5 might suffice (not properly re-factoring into functions), or a poor programmer might write 5 lines of code when 10 would be better (example: skipping error checking).
C) A poor programmer might write 50 lines of code, and have to re-write it later because the first time it was done wrong. Does that mean he wrote 100 lines of code, despite only 50 ending up in the final project?

D) "Measuring programming progress by lines of code is like measuring aircraft building progress by weight."

I like that analogy.

Given that sometimes we write few lines in a day, what is the most that you guys have written in a full work day - assuming good code with few or no bugs and little at most debugging/rewriting?

I've never measured it, so I'm just making up numbers with no evidence*, but I would guess:

1000-3000 LOC/day == you're just typing all day without much thought

10-100 LOC/day == you're writing good code

*Your mileage will vary.

On average, even when not debugging, I don't write that many lines of code a day. Sometimes as low as 10, which leaves most of my time for thinking rather than typing.

Instead of banging out 1000 lines all day long to complete a task, you can probably think about it a little more and accomplish the same task with 100 lines (which is more valuable overall, because it makes maintenance easier in the long run).

My lowest LOC-per-day score was when I was assigned a random memory-corruption bug (which was actually caused by a buffer-overrun by the GPU, due to the VRAM allocator being buggy), which took over a month to figure out. After a month of debugging, the fix was 1 line of code, or about 1/20th of a line per day over that period There was also more than one of us working on the bug, so maybe the real score is 1/50th LOC/day each!

Also, the amount of typing you'll do also depends on the kind of programming that you're doing. If you're building a new API then you'll spend a lot of time thinking about architecture, and very little actually writing the interface based on those thoughts. On the other hand, if you've got a tight deadline, e.g. "we need to show this level at E3 tomorrow!!", but that level in the game hasn't even been started yet, then you might hammer out 1000 lines of poorly written code to script that level's events, for now.

Anyway, in the real world, good managers will adapt to your skill level and speed. I've always been assigned tasks and asked to estimate the time it will take me to complete them by myself (instead of being given the time-frame that the task will take by the manager). You and your manager will slowly learn how quickly you can complete certain types of features, they'll learn which parts of the game it's most useful for you to be working on, and your estimation skills will improve over time too. You'll improve at your own pace, and as you do, your new skills will be recognized with more responsibilities, bigger tasks, and hopefully, promotions

Guys, I have a unique opinion to share about this topic.

How many lines of code you write isn't a good way to measure your coding ability!

...did someone already say that?[/quote]

LOL

Obligatory link: http://folklore.org/StoryView.py?story=Negative_2000_Lines_Of_Code.txt
Code complete (iirc) has that study, though I remember it being 10 lines of code per day, per dev, on average.

In general, I can implement one straightforward feature with tests and documentation and team communication (meetings) in 4 hours. A mildly complex feature takes about a day.

In the end, only two measurements matter:

Does my code do more useful stuff today than yesterday?

Am I more happy with my code today than I was yesterday?

As long as one of these things happen in the short term, and as long as both are happening on the long term, all is well.

i'll throw in a joke answer, and say the magic number is 42.

:)

Given that sometimes we write few lines in a day, what is the most that you guys have written in a full work day - assuming good code with few or no bugs and little at most debugging/rewriting?

I've never measured it, so I'm just making up numbers with no evidence*, but I would guess:
1000-3000 LOC/day == you're just typing all day without much thought
10-100 LOC/day == you're writing good code

*Your mileage will vary.

On average, even when not debugging, I don't write that many lines of code a day. Sometimes as low as 10, which leaves most of my time for thinking rather than typing.
Instead of banging out 1000 lines all day long to complete a task, you can probably think about it a little more and accomplish the same task with 100 lines (which is more valuable overall, because it makes maintenance easier in the long run).

My lowest LOC-per-day score was when I was assigned a random memory-corruption bug (which was actually caused by a buffer-overrun by the GPU, due to the VRAM allocator being buggy), which took over a month to figure out. After a month of debugging, the fix was 1 line of code, or about 1/20th of a line per day over that period There was also more than one of us working on the bug, so maybe the real score is 1/50th LOC/day each!

I wrote 5 lines of code yesterday. Of those lines, 3 were a unit test, and 2 made the test pass.

Anyway, in the real world, good managers will adapt to your skill level and speed. I've always been assigned tasks and asked to estimate the time it will take me to complete them by myself (instead of being given the time-frame that the task will take by the manager). You and your manager will slowly learn how quickly you can complete certain types of features, they'll learn which parts of the game it's most useful for you to be working on, and your estimation skills will improve over time too. You'll improve at your own pace, and as you do, your new skills will be recognized with more responsibilities, bigger tasks, and hopefully, promotions

A good manager, and a good team, will schedule the time each artifact should take, and then record how long it really took.

I have a piece of software that I wrote that helps me with scheduling my people. I keep track, in it, all of the various pieces of software we've written, the feature breakdown of the software, the time each feature took, who did it, my rough estimates of their skill levels... It lets me do lots of things, for instance... I can go into a company (I'm a consultant), sit down with their team of developers, interview them and get an idea of their skill level. Using the years of data I've acquired in my database I can then use it to produce reasonably accurate estimations of how long it will take to perform the work I've been contracted to do.

The more data you gather, the more pieces of information you have, the better and more consistently you can schedule your people, deadline dates, and releases.

Frankly, its more important to learn how to work WITH a developers skill level than the number of lines of code he writes in a day.