750 LOC/hour on average? The secret to that is either having a very loose definition of code (e.g. counting generated files, copy and pasting huge amounts of boilerplate, etc) or a very loose definition of honesty. Nobody is that productive, especially not working 10 hours a day. If I do 750 LOC in a week, that's a good week!

> If I do 750 LOC in a week, that's a good week!

I'm so glad I'm not the only one who feels this way.

If I can do -750 net LOC in a week (while maintaining or extending functionality), that's a great week!

In my experience aspiring to this would be a mistake.

You can pull off very high production numbers for a while [under whatever metric you choose] before you start babbling in a corner somewhere, but invariably i's mostly crap and you'll end up replacing every 100k lines with 10-20k lines later, but this time it will be well though out, tested, and maintainable.

I've met a few people who have convinced themselves this isn't true, but nobody who has managed to convince anyone else.

So you can paint yourself into a corner where all you can do is crank as fast as your tooling allows, but it's like deficit spending, it will cost you more in the long run than doing it right would. Of course, if having a long run at all to worry about this depends on your current output, crank away.

I have an excellent command of JavaScript and AngularJS, which allows me to focus on the problems themselves and not get fussed up with language subtleties...usually. I also have been working 70+ hour weeks for the past month, often 75 hours. There have been multiple times I had to shut my brain for the night because my focusing ability starts to deteriorate if I code too long. I also try to get a good night of sleep most nights - 7-8 hours prove optimal for me, although I often end up with 6.

A good portion of those loc have been complete rewrites based on existing code to clean it up and meet unforeseen changes in requirements that nobody planned for. Honestly, the amount of code I pumped out is a miracle, I'm hoping I don't get stuck in such a situation again at my current job.

That is under 7.2 seconds per line, nonstop. [1]

I'm a fast typist, and I can't type that fast.

[1] 75 hrs/week * 4 weeks * 3600 sec/hr / 'over' 150,000 lines = 'under' 7.2 sec/line

And don't forget- its not nonstop; he's managing others during the day and setting his fingers on fire before & after work, its probably under 4 seconds per line!

Which, as long as you never under any circumstances have to actually read, build, run, or debug any of the code, is totally do-able.

Even if this physically impossible feat of coding were true, that's 150,000 lines of code to debug, written while tired. Enough to set a full engineering team back for a year.

I work with Angular and Javascript as well. I don't think you should count the html code, if that is what you did. Count the javascript-code only and see how many lines you write in a week. And if the number still is as high as you've said I must wonder what kind of system you are building? Normally you rewrite everything that is repetetive into services/controllers/functions to keep the line count down. There was a talk recently from Google about some large application they had written in Angular, the problems they ran into and what they learned from that. They provided some line counts and it wasn't millions of lines even for them and they still had a team of something like 10-20 developers.

Others are downvoting you, possibly bc they think you're exaggerating, but I just find your claims to be curious and would be really interested in meeting you. That is, if you ever have time to meet other people. Let me know, contact info is in my profile.

I don't think he was suggesting you aspire to that.

And both 10 hours and 5 days are probably underestimates of the time he is spending.

The claim was he did this mostly while others weren't in the office. If you assume they work a straight 8 hours (and why would they at crunch time) that leaves 14hrs/day to eat/sleep/work. 10/5 isn't so unreasonable approximation

But hey, another way to look at it. 150,000/30 = 5000 lines/day. At 16 hrs/day, that is 312.5 lines/hour, or 5 lines/minute non-stop.

Not killing myself, and leaving the typos in that wouldn't affect compilation, I generated the code below in 36 seconds; I knew what I was going to program ahead of time - there was no thinking involved. I honestly could have typed faster, but I also didn't want to type faster than I could sustain for 16 hours nonstop. I haven't had my coffee yet, so that is a factor.

So that is right at the target rate. I don't think I could maintain that 16/7 for real problem. I'm going to have to stop to think, to look up things, to make mistakes, to write tests, to document. Unless we assume I am perfect, I'm going to have to spend time debugging. This is for a stupid Euclidian distance function, whereas the claim was it was difficult, critical code. And the claim is not 16/7, it is "before/after" office hours.

    import math

    def distance(x,y):
        """ compute striaght line distance between x and y"""

        return math.sqrt(x**2 + y**2)

I agree with your conclusion.

Worth adding this doesn't even find the two dimension distance between two points, it finds a hypotenuse length using the Pythagorean theorem and doesn't accept two points as parameters (unless they are on a number line, and in that case math.abs(x - y) would be the correct code).

That... and I shiver to think of the amount of buggy code being churned out. 150k lines of crappy code isn't something to be proud of.

More code = more points of interaction = more bugs.

Caveat: This is assumption based. I assume that much code is due to "quantity not quality". Boilerplate code, copy/pasta, 10 lines of actual code, 100 lines of test, etc