OSDev.org

hello
i have one question:
how much code can you "code" at 1 hour.




KMT dk

depends on the mathematical/conceptual complexity of the desired result.
If I'm coding a network device driver, probably 400 lines an hour, if I'm coding SMP initialization, drastically less code per hour.

Can't tell.

No, really. It have been very rare occurrences where I was able to "speed code" anything. Most of my time is spend debugging existing code, trying to figure out how to extend some functionality without breaking other parts, porting stuff, writing / updating documentation...

I consider lines / hour a very, very bad benchmark for anything.

Yes I agree, I can write LOADS of lines in an hour, but it will probably be buggy (if your talking about OS coding, API coding will probably be much less buggy...)...
So overall, I'll spend probably a lot of my time debugging...
Also a 01000101 pointed out, It depends on the complexity of what your coding...
It also depends to a certain extent on environment/mood, if there are lots of distractions where your coding (e.g. coding on your laptop on the beach), your coding will be significantly slower. (By the way using your laptop is an EXTREMELY BAD idea, I still find sand occasionally when I open my laptop...)
And if your annoyed or thinking about other things, you'll obviously code slower...
Jules

recently I didn't do very well, 50 lines per hour or something

kmtdk wrote:hello
i have one question:
how much code can you "code" at 1 hour.

Back in university, my friends and I stayed late one night in the computer lab to finish an assignment due at midnight (I think we finished a linear algebra assignment before we started programming). It was a second year assignment in an intro C course. I only managed about 50 lines per hour. Worse still, I didn't even write 50 lines!

As I recall, they had to use one of their late days... But damned if they didn't write more code in less time than I did*. Now, you have to remember that in university programming, code (IMHO) should be rated in terms of mark/time. In general, I think a better metric would be "How much code do you alter per hour?" But that would probably discourage fixing broken code.

Here's a good story (unlike mine) on the subject:
http://folklore.org/StoryView.py?projec ... f_Code.txt

*This was years ago, and my friends are a lot better at programming now. I just wish I was as good at math as they are (or were for that matter).

I consider 200 lines of fully debugged ASM code per day to be a good day.

I once had a programming gig at a small shop. We were reviewed every 6 months on our performance, and I never had a problem.

Until one review period where I spent all 6 months on bug fixing duty. When it came time for reviews, we were told that the owner of the company was tracking everyone's line of code output for the period, and that would be a huge part of our review. I was shocked, to say the least, and of course I had a very poor review. There was one guy in the shop that had a stellar review. He put out many thousands of lines of code in those months. Very crappy code that I spent all 6 months fixing. So while I was fixing his bugs and got crap for it because my LoC count was far lower than his, he was praised for his output of horribly written and extremely buggy code.

A bunch of us tried to get the owner of the company to see the error of his ways on that review and to see that he was sending the wrong message. He basically came back to us and said "If you don't like it, quit. This is the way it's going to be."


Half of the programming department walked out that day. Yes, I was one of them.

One Google Code Jam problem.

It depends on how much I've planned out, or which nth iteration of a problem I'm working on. I find listening to trance in the background helps (tune distractions out).

I'm working on a program now in which the build script for the help files checks timestamps to see which need to be rebuilt, and it puts the build date in each file, so it generates lots of "-+ 2" lines in commit summaries. Usually I manually revert the files though, don't need all my "extra work" showing up.

[I tend to dislike using my laptop outside period; there's usually too much glare, bits of pollen and junk ends up on the screen, and it makes me consider pouring my beverage on it to cool it off, not fun...]

When working on my realmode emulator at one point I got to about 300 lines per hour, on average I was doing 500 per day, but that also included reading up on opcodes and the like (and eating)

It depends on what I am coding and in which language.

I. e. if I code a 2nd stage bootloader in asm, where I know all hints and things I have to do then I can achieve approx. 400 lines per hour.
If I code in obj-C for iPhone where I have to look up some things it's about 300 lines per hour ...
...

But I don't think that LoC is a value which measures a programmer, a programmer is just as good as his code is, that means a programmer who does approx. 500 lines of code and his code isn't optimized, has faults, pragmatical errors and so on, isn't better than a programmer who just writes 100-150 lines of code per hour without errors and pragmatical faults.

It's a simple equation, 500 lines a lot of errors and 100-150 lines and nearly no errors.
It will take a company longer and more money to correct these 500 lines of code than using the non-faulty code.

If a company measures a programmer by it's LoC value, it will not get very far with this.

I'm a slow coder, I admit. I'm more of an analyst/engineer/manager/architect.

I spend more time doing the engineering thing: laying all the stuff out on paper, thinking it throu' - this takes it's time.

The code which usually falls out of my hands is relatively little, small chunks (components) put together. I tend to code straight forward, easy, lean.
So, to judge a software architect's work by LoC/h is utterly abominable.

Just my two cent.

I'm a slow coder, too. When I code something, I always double-check if it's working or not and when I'm adding something new or fixing it, I always re-compile the code to see if it works (or if it compiles), because I make enough errors to screw something up.

A value of LoC per hour is, I think, totally irrelevant. There's no point writing 200 lines per hour of flawed or non-working code... I always concentrate on stability when coding.

On the other hand, I don't write comments and I don't use any special padding/tabs at all. That's one of the main reasons why my code isn't open source. For me, the code style is irrelevant, when I'm concentrated enough, I can understand my own code inside and out.

Exactly how I feel above. Lines of code per hour is completely irrelevant to me and my project. I base my good days on whether or not I accomplished my todo list for that day. If I can get through it and still have time to practice guitar or have a beer with my friends then I could care less how many lines of code I wrote that day, because to me I just had a GREAT day.

It all depends. On everything. Like if I have a whole bunch of case statements to write, I'll like spend forever trying to come up with a simple program that allows me to input a simple table for input and output and output a switch. Does that make sense. I think I usually waste more time looking for ways to get around repetitive coding than coding, if you take my meaning.