I didn't intend to comment on this post from Jeff Atwood where he claims we (developers) are typists first and programmers later but since I qouted his blog on my previous post I reconsidered.

I'd have to say that this isn't one of Jeff's most intelligent posts. 
 How many lines of code do you think developers write per day? let's google us some numbers:

Here is one interesting qoute

"Let's see if, quantitatively, there's any truth to the perception that the code velocity (net lines shipped per developer-year) of Windows has slowed, or is slow relative to the industry.  Vista is said to have over 50 million lines of code, whereas XP was said to have around 40 million.  There are about two thousand software developers in Windows today.  Assuming there are 5 years between when XP shipped and when Vista ships, those quick on the draw with calculators will discover that, on average, the typical Windows developer has produced one thousand new lines of shipped code per year during Vista.  Only a thousand lines a year.  (Yes, developers don't just write new code, they also fix old code.  Yes, some of those Windows developers were partly busy shipping 64-bit XP.  Yes, many of them also worked on hotfixes.  Work with me here.)

 

Lest those of you who wrote 5,000 lines of code last weekend pass a kidney stone at the thought of Windows developers writing only a thousand lines of code a year, realize that the average software developer in the US only produces around (brace yourself) 6200 lines a year.  So Windows is in bad shape -- but only by a constant, not by an order of magnitude.  And if it makes you feel any better, realize that the average US developer has fallen in KLOC productivity since 1999, when they produced about 9000 lines a year.  So Windows isn't alone in this.  [KLOC data comes from “Worldwide IT Trends & Benchmark Report 2001”, produced by META Group (now acquired by Gartner)]"

Here is another one from Jeff Atwood himself

But what I really want to focus on here is how you measure a project's size. What's big? What's small? McConnell is using lines of code (LOC) as his go-to measurement. Here's a table that illustrates the relationship between project size and productivity:

Project Size	Lines of code (per year)	COCOMO average
10,000 LOC	2,000 - 25,000	3,200
100,000 LOC	1,000 - 20,000	2,600
1,000,000 LOC	700 - 10,000	2,000
10,000,000 LOC	300 - 5,000	1,600

some of the best numbers I've found:

"

Alien Problems:

problems about which I know nothing, those have seen them for first time:

12 lines of usefull code per hour :((, includes thinking on it 

Some what, I know problems:

problems, that I know about but have not solved before.

33 lines of usefull code per hour, including thinking

Ah, I have done that before:

63.5 lines of useful code per hour"

These numbers shows us the most of the time spent on projects is doing other stuff- as in not typing programs.

but let's say you code 1000 lines of code per day. if you code for 4 hours in that day you would write 4-5 lines per minute - how many words per minute do you think that amounts to? unless you are writing COBOL I would say 3-5 words per line. what sort of typing speed do you need for that?

Note that " lines of code" is not a very good measurement of productivity. e.g. refactoring a design may generate lines of code for you (e.g. extact method) or you may remove lines of code (applying principles like DRY) or you can generate code from templates /wizards)
As John D. Cook says:

"I heard of a study recently that concluded inexperienced and experienced programmers write about the same number of lines of code per day. The difference is that experienced programmers keepmore of those lines of code, making steady progress toward a goal. Less experienced programmers write large chunks of code only to rip them out and rewrite the same chunk many times until the code appears to work. "

In any event,in my experience, you just get better in typing just because you spend all that time at the keyboard - it is defenetly not a goal in itself, just a nice side-effect.