Yes. And this: "Your 1,000 lines should be the essential core that enables a team of programmers to write another 10,000 lines effortlessly."
If you're writing critical core stuff like that, you better spend a lot more than a week on it. I can't imagine working on anything where the team regularly writes 10,000 lines a week. Prototypes by one person can easily grow at 1kLOC per week for a short time, but that's a special case.
I'm a senior engineer who has written over 150k loc the past month :( . I have had to tackle some difficult problems that allowed the other engineers to keep moving.
My workaround so far has been to do most of the critical work during after hours or before everyone comes in the office, since my primary role during regular hours is to keep everyone unblocked. It isn't sustainable though, and I only do it at the moment because we are in crunch mode - 'tis the startup life.
Since no one in HN has called you out, let me do so. You sir, are a liar. 150k LOC? GTFOH! Seriously, how many did you throw out? BS! Being that you are on HN, you definitely have free time, what's your github?
150 000 lines of code / (10 hours * 5 days * 4 weeks) = a sustained 750 lines of code an hour? That's impressive. Can you share a bit more about how you manage to achieve such productivity for those of us who aspire to be like that?
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!
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.
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.
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)
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
I read the essence of that statement without the same time constraint applied to it. i.e. the type of 1000 lines you should be working on each week is the type (systems code) that enables (application) programmers to write the rest of their code effortlessly.
e.g. Rails core (system) vs people who use Rails (applications).
If you're writing critical core stuff like that, you better spend a lot more than a week on it. I can't imagine working on anything where the team regularly writes 10,000 lines a week. Prototypes by one person can easily grow at 1kLOC per week for a short time, but that's a special case.