
You only get 1,000 lines of code a week - mmastrac
http://www.onebigfluke.com/2014/11/you-only-get-1000-lines-of-code-week.html
======
methyl
Actually 1,000 lines of code a week is quite a lot. Of course it depends on
language / technology stack, I'm speaking from Rails / JavaScript programmer
point of view.

~~~
phkahler
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.

~~~
Bahamut
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.

~~~
GuiA
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?

~~~
Bahamut
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.

~~~
RogerL
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

~~~
dahart
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.

------
calroc
"... From there it is only a small step to measuring "programmer productivity"
in terms of "number of lines of code produced per month". This is a very
costly measuring unit because it encourages the writing of insipid code, but
today I am less interested in how foolish a unit it is from even a pure
business point of view. My point today is that, if we wish to count lines of
code, we should not regard them as "lines produced" but as "lines spent": the
current conventional wisdom is so foolish as to book that count on the wrong
side of the ledger."

~Dijkstra

[https://www.cs.utexas.edu/~EWD/transcriptions/EWD10xx/EWD103...](https://www.cs.utexas.edu/~EWD/transcriptions/EWD10xx/EWD1036.html)

~~~
christiangenco
Precisely. This should be an automatic trigger whenever "lines of code" is
mentioned as a metric.

I'm reminded of the "-2000 lines of code" story:
[http://www.folklore.org/StoryView.py?story=Negative_2000_Lin...](http://www.folklore.org/StoryView.py?story=Negative_2000_Lines_Of_Code.txt)

------
kabouseng
It depends on what career trajectory a senior developer is. If he is destined
to become a specialist, then this article is spot on.

If instead he dreams of becomming a manager or architect, then he would
actually not be coding the most complicated parts, and make sure to keep
himself off the critical path of the project, so as to free up his time, so he
can spend his time helping his colleagues and clearing the rocks in their
path.

Also as a manager or architect, you better get used to constant interruptions,
degrading the quality of code you can generate. So think hard before assigning
that critical section to yourself.

~~~
mrcsparker
For a manager, I agree. An architect should write the most complicated, not
the least complicated, part of code. This is assuming that the architect is
the most experienced developer on the team.

This doesn't include paper architects, which are pretty much salespeople.

I would like to hear other people's thoughts on this - this is the way that I
have always handled projects.

~~~
ObviousScience
I suppose whether or not I agree depends on what you mean by complicated:
there's complexity of an algorithm implementation and there's complexity of
program structure.

I would think that you'd want an architect to work on non-tight-loop, core-to-
the-control flow complexity, and leave the optimization of tight loops and
such to people with more time to focus on the details of that (eg, what
processor is being used), and instead work on the complexity of the
control/data flow abstractions, which is what he already knows the most about,
having designed their architecture.

This also keeps his role as central organizer of the code and flow through it,
rather than having his time sidetracked (partially) by other concerns.

~~~
kabouseng
That is how I have it as well. With our projects usually the architect would
write the framework of the product at the beginning of project, almost being
the only developer on the project.

As other developers start getting on the project he guides them where their
code should live, and he start to disengage writing and serve more in a
guiding role.

------
pm90
OK, since a lot of comments here are discussing Software Architecture in
general, I would like to ask a question that I've been wanting to for a long
time: As a Developer with ~2 years of experience and desiring to be a Software
Architect, how do I get there? And by that I mean: how do I develop the talent
to design large/complex/distributed software systems, when I'm actually really
working on much smaller things on a day-to-day basis? Is it all just something
I have to learn in my free time? If so, then how should I go about it?

~~~
bad_user
IMHO, there's no such thing as a Software Architect. Take this for what you
will, but people that label themselves as being _architects_ are an instant
red flag, as that's usually corporate slang for _I 'm incompetent, but I can
draw diagrams and have meetings_.

The industry is simply separated in developers that suck (because they lack
either the experience or the ability) and those that don't and that are thus
capable of making good decisions.

As to how to get there, there's no simple recipe, but in general you simply
have to (1) read a lot, like books, papers, other people's source code and (2)
you have to get burned by a lot of bad choices you've made and learn something
from those mistakes. Both have something to do with _getting out of your
comfort zone_.

~~~
Terr_
So what would be the non-"red-flag" way?

I mean things like: "Problems X, Y, and Z are actually all caused by the other
teams trying to work around the bad build-system. We should fix that first."

~~~
nostrademons
Pitch yourself based on what you've done, not who you are. Saying "I'm a
software architect" is a red flag for "I'm incompetent and can't actually
write code", saying "I built this software system (which you can see at this
URL) from the ground up" or "I led a team to build this software system, and
here's why it's hard" communicates exactly what you can do.

~~~
Terr_
You build things the public is ever allowed to see? Lucky. :(

------
thom
I'm not sure anyone grows up with computers wanting to make enterprise
software. For me it was always games. Lots of games, lots of different
mechanics. Maybe I wished for more hours in the day, but I never sat down
wishing I could just write more lines of code. But the ball could always
bounce more convincingly, the TIE-fighters could always explode in bigger
fireballs. Programming was experimenting, exploring.

I didn't end up making games. For the longest time it was billable hours,
deadlines, sprints, features, CRUD, lines of code. Always moving faster,
always choosing better tools, better methodologies. Arguing about those tools,
those methodologies.

Getting older, I've loved the transition from the bums-in-seats, maximum-
throughput kind of programming to "oh shit, how can we possibly make it do
that?" day-long whiteboard sessions. We always want to move faster, we still
argue about how, but we're back to experimenting, exploring.

1000 lines of code a week is bullshit for us, and I don't think this is just
about 'senior' developers. My advice to everyone is to find a place where the
lines of code don't matter. Go make computers do cool stuff, then think long
and hard about how to make it cooler and go do that.

------
sytelus
One of the fact that surfaces from the book _Just for Fun: The Story of an
Accidental Revolutionary_ is that Linus wrote the code for Linux in ~15 months
and it was ~15K LOC. I usually take that as gold standard for productivity of
brilliant programmers. Note that as per the book, he almost exclusively spent
entire time writing code during these months (he would put down the curtains
if it was a rare sunny day outside and skip showers and just about any events
so almost all he does is write code).

------
bemmu
People seem to be focusing on the number of lines. I think the point is just
to recognize you have limits, be realistic on what you can accomplish alone
and accept help from others where it is possible.

------
mikegioia
This is really spot on. The only thing I could add, is that I've found the
only way to continue to write code in the capacity he's talking about, is to
dedicate a day or days of the week to programming. If you're going to make
your 1,000 or so lines meaningful, then the context switch to that mental
state is too high when your day is intermixed with distractions.

Sometimes I can put my headphones on at the end of the day and try to get 2
hours in; or work the graveyard shift at home but that's never as good (or
healthy really).

I tip my hat to the pure engineering managers who don't code at all. They're
more like social engineers than anything, but boy would that be challenging to
do 100% of the time.

~~~
kabdib
The best managers I've had were ex-engineers who realized that they couldn't
write code any more. One of them explained it like this: "You get your work
done by moving lines of code around. I get mine done by moving people to where
they're needed, a little like chess." And it was true: He was tuned into the
technical issues, and knew what his talent pool was, and was quite good at
helping people make decisions about what to work on.

The worst managers I've had have been the ones who thought they could do
engineering plus "the people stuff", whereupon they stunk at both. (Well, not
the _worst_ \-- the absolute worst tried to make all the decisions, too: Code
it this way, little robot. Or neck-and-neck, the managers who made no
decisions at all and left everyone rudderless until they decided on a product
and a deadline; ugh).

Back to coding, that's roughly 50K lines of shipped code a year, which seems
pretty high to me. Well, you can definitely do that in a green fields area,
like a totally new feature or product. But writing that much code in an
existing system is gonna be hard.

------
betadreamer
The point of the article is just to say "make it count". But since everyone is
talking about the number of lines...

This reminds me of the time when this company giving requirement to all their
employers to write down how much line of code they have written this week and
this senior engineer who was working on an optimization problem wrote -1000.
From there on the company removed that policy. (forgot the company, person's
name, and the number)

~~~
cbd1984
[http://www.folklore.org/StoryView.py?story=Negative_2000_Lin...](http://www.folklore.org/StoryView.py?story=Negative_2000_Lines_Of_Code.txt)

Very likely Apple.

~~~
anon4
I would have written that as $LOC_DELETED + $LOC_ADDED (i.e. if it was 3000loc
and I deleted those and rewrote it in 1000loc, I'd put 4000loc). After all,
deleting lines is a net positive change for the project and you need to think
a lot about exactly which lines to delete.

------
Beltiras
I'm spending a lot of time choosing the right backend for an advertising
platform. I haven't really written a line of code for a month that I intend to
keep. Am I 4000 lines behind then? Then again, maybe I'm doing exactly what
the article prescribes: thinking ahead, carefully choosing my libraries,
thinking through every use case and then hopefully saving my future
maintenance programming a ton of headaches.

------
EGreg
People, we can settle this with a line-counting tool. I just used
[http://gitstats.sourceforge.net/](http://gitstats.sourceforge.net/) and it
appears I've been authoring over 1000 lines of code a week.

See for yourself at [http://github.com/EGreg/Q](http://github.com/EGreg/Q)

300k lines of code over about 3-4 years

------
dahart
1k loc / week sounds like a lot. As a teenager, I got a tour of a company
doing contract work for the government making drones. Their manager said they
average 12 lines of "final" code per day per engineer over the course of a
project. I was stunned and shocked it's so low, but it has stuck with me ever
since. After many years more experience, factoring in bug rates and debugging
time and meetings and rewrites and all the other things that eat time, I'm
quite convinced that nobody goes as fast as they they think, and in reality
all software dev is surprisingly slow, measured over the course of a large
project. Granted government / military work is expected to run slower (and
more carefully) than most software. But if you're writing code, you're
creating bugs, and bugs take time to fix, there's no way around that.

~~~
nostrademons
12 lines/day/dev of "final" (tested, debugged, solves a customer problem)
sounds about right.

The thing is - most code is not final. You end up writing exploratory code to
test out a product, code that's rewritten because requirements change, code to
test the actual code, code for projects that go nowhere and end up canceled,
code for throwaway migration tools and other important tasks that aren't in
the product but are necessary to build the product, code to make your job
easier. All of that takes time, but it's not included in the metrics.

When I was at Google I used to joke that the half-life of my code was about a
year, meaning that after a year, roughly half the code I'd written had been
ripped out and replaced. Casual conversations with many other engineers
indicated that their numbers were pretty similar. Over the course of 5.5 year
career there, I wrote IIRC about 230,000 lines (there was a tool where you
could instantly visualize your code delta across all projects you worked on).
With a half life of a year, that's nearly 6 half-lives, meaning less than
1/64th of the code I wrote still exists in the codebase. It works out to about
3 lines of code/day, even though on an instantaneous week-to-week basis I was
coding close to 1000 lines/week.

------
barbudorojo
How do you know that you are going to write 1000 lines a week? Once you begin
to write code you it can happen that the code is more easy to write than to
explain and then you can code hundreds of lines in little time, but also it
could happen that the code requires very special attention and sophistication,
a tough problem, here you can only write a few lines but those are crucial or
very important to write for efficiency or memory constraints. What I would
suggest is to distribute your time according to the complexity of the modules
or parts of the problem, but prior to that you need to have a good
understanding of logic and internal structure of the code you are going to
develop, and this is also another problem that you must address in your
distribution of time.

------
ibz
This is spot on, except I would take it a bit further. You can only accomplish
X things in a week. Now, what do you choose to do with your life? If you are
writing code ask yourself what is the purpose of that? What is the goal of
that app? How are you making the world a better place? Or, as he puts it,
isn't there anything else you could be doing that nobody else can, and that
would indeed make the world a better place? Could be coding on another
project, could be not even coding. But anyway, choose wisely what you do with
your life.

------
chj
Well debugged 1000 lines a week are actually quite a lot. I would be very
happy with 20000 lines per year.

------
mobiuscog
As with most things, the modern age dictates that speed and quantity are
better than quality.

It should be the 'thought' that counts.

