It's not 'perhaps what he means', it's one of the central points of his article. He doesn't 'perhaps mean' it, he spells it outright -
"I've spent a total of 240 hours on the project, or about 6 working weeks." This is his total time, coding, or otherwise.
"In terms of code there are about 2000 lines of template code, 6000 lines of Python, and 900 lines of migration scripts (done in Python). [...] Given those figures, it looks like I was reasonably productive -- averaging over the complete time that comes to about 37 LOC/hour, which is reasonable."
I.e. 8900 LoC / 240 hours = 37.08 LoC/hr. That's 37.08 LoC/hr where hr is hr of total time spent on the project.
His estimate is low if perhaps you'd read the article.
That still seems incredibly low (and yes I did read and I still think it's low).
Picking the most recent example from my projects..
This project has lasted 2 weeks so far (12 days). About 15 hours according to my commit logs - so that is roughly 24 hours work including debugging. It's almost feature complete (I reckon another 5 hours total to release it).
After I scrap all the js libraries and all my drop-in code the lines I have written in that time comes out as 4940.
That's 205(ish) LOC per hour.
So, yes, his is a low figure (though my figure is easily the maximum I can manage - this was a productive project; I would say 100 is my average)
EDIT: I will agree with his stuff about honey moon period. I would say the bulk of that code came out in the first 10 hours. Half of the code was written on wednesday in a 5 hour coding session (and 3 hrs of debugging).
Perhaps it is to do with how I work and the fact I am well practiced in this language & framework. I sit and write code solidly for 3 or 4 hours. Then spend and hour debugging all that code - that is a good workflow for me but I know others hate that approach! (we regularly argue over it in the office :P)
If you read he learnt a lot of things as he went along - and include them in the metric. So that lowers the value somewhat. If your working with code your well practiced in and using a framework to build on then it's definitely a lot faster.
The main point I was making is his metric seems bad - and the value he comes out with very low. As he bases his whole point on it I think it weakens his fairly good argument.
That said I know a couple of programmers who could slam out and debug a 6000 line web app in a long weekend; and it would mostly work.
I recall studies that claimed 10 LoC per day - that is, debugged, documented, production, finished code.
The odd thing was that it was 10 LoC whether it was assembly or high-level languages - because you could do more in 10 lines of a high level language, it is actually more productive. Not really surprising, I guess; that's the point of good abstractions.
I think the estimate is good. When I write 100 LOC, it probably won't be correct the first time. So I go back, fix, test and fix again. While having another look at it I notice that some things can be condensed or replaced with existing code. When I'm done I end up with half the code I started with. So: did I just spend an hour on 100 LOC or 50 LOC?
It seems low at first, but if you factor in debugging and documentation it is actually pretty good. I wished I could claim that as an average. I've pulled all nighters in a familiar environment starting from a 'blank' page where you get this amazing amount of output but that usually slows down quite a bit by the time the week is up.
But in an hours coding I'd hope to push 100 LOC.