9 ms·

You only get 1,000 lines of code a week

124 points by mmastrac 12y ago

mikegioia 12y ago
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 12y ago
  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.
methyl 12y ago
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.
- mathattack 12y ago
  That was my reaction too. If you want to force thought and conciseness, make it 100 lines. :-)
- phkahler 12y ago
  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 12y ago
    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 12y ago
      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?
      - cowsandmilk 12y ago
        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.
        12y ago
barbudorojo 12y ago
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.
kabouseng 12y ago
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 12y ago
  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 12y ago
    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 12y ago
      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.
Beltiras 12y ago
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.
bemmu 12y ago
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.
ibz 12y ago
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 12y ago
Well debugged 1000 lines a week are actually quite a lot. I would be very happy with 20000 lines per year.
dahart 12y ago
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.
- Someone 12y ago
  Brooks states 200 lines/year, not counting scaffolding and including management and the time spent designing, documenting, and testing. Seems reasonable for real software (as opposed to 'copy-paste, who cares if the user has to hit F5 once a day?' code) to me.
- nostrademons 12y ago
  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.
pm90 12y ago
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?
- AznHisoka 12y ago
  build your own thing, that's the best way IMO.
- therealdrag0 12y ago
  If you can work on a green-field project, you'll get a LOT more experience implementing new things that exercise your architect muscles, and you'll be around architects that you can ask why they are making decisions they are. Versus working on an existing project, where you tend to just fix bugs or figure out how to hack in a new feature without breaking what's there. (I don't know which of these camps you're already in, but in general I think it makes a big difference.) (Disclaimer: I am a jr dev, but see a world of difference between what I get to learn and others at my level because of my project.)
- mabbo 12y ago
  One would hope your company would be making these investments in you. As a developer at [Large well-known software company], after my first year I started being given leadership roles in minor stories, then major stories, then epics that breakdown into major stories. If the company you work for is not giving you growth opportunities, one might begin to wonder how they picture your future. Side note: "Software Architect" as a role sounds way too Waterfall to me. People should have varying skills at design, and work together to build the best thing they can. Not have an Architect who claims omniscience and designs the whole project up from.
- bad_user 12y ago
  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.
EGreg 12y ago
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
betadreamer 12y ago
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 12y ago
  http://www.folklore.org/StoryView.py?story=Negative_2000_Lines_Of_Code.txt http://www.folklore.org/StoryView.py?story=Negative_2000_Lin... Very likely Apple.
  - anon4 12y ago
    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.
- deleted 12y ago
  [deleted]
calroc 12y ago
"... 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/EWD1036.html https://www.cs.utexas.edu/~EWD/transcriptions/EWD10xx/EWD103...
- christiangenco 12y ago
  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_Lines_Of_Code.txt http://www.folklore.org/StoryView.py?story=Negative_2000_Lin...
sytelus 12y ago
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).
thom 12y ago
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.
mobiuscog 12y ago
As with most things, the modern age dictates that speed and quantity are better than quality. It should be the 'thought' that counts.

124 points by mmastrac 12y ago

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 12y ago
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.

methyl 12y ago

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.

mathattack 12y ago
That was my reaction too. If you want to force thought and conciseness, make it 100 lines. :-)
phkahler 12y ago
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 12y ago
  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 12y ago
    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?
    - cowsandmilk 12y ago
      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.
      - 12y ago

barbudorojo 12y ago

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.

kabouseng 12y ago

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 12y ago
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 12y ago
  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 12y ago
    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.

Beltiras 12y ago

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.

bemmu 12y ago

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.

ibz 12y ago

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 12y ago

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

dahart 12y ago

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.

Someone 12y ago
Brooks states 200 lines/year, not counting scaffolding and including management and the time spent designing, documenting, and testing. Seems reasonable for real software (as opposed to 'copy-paste, who cares if the user has to hit F5 once a day?' code) to me.
nostrademons 12y ago
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.

pm90 12y ago

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?

AznHisoka 12y ago
build your own thing, that's the best way IMO.
therealdrag0 12y ago
If you can work on a green-field project, you'll get a LOT more experience implementing new things that exercise your architect muscles, and you'll be around architects that you can ask why they are making decisions they are. Versus working on an existing project, where you tend to just fix bugs or figure out how to hack in a new feature without breaking what's there. (I don't know which of these camps you're already in, but in general I think it makes a big difference.) (Disclaimer: I am a jr dev, but see a world of difference between what I get to learn and others at my level because of my project.)
mabbo 12y ago
One would hope your company would be making these investments in you. As a developer at [Large well-known software company], after my first year I started being given leadership roles in minor stories, then major stories, then epics that breakdown into major stories. If the company you work for is not giving you growth opportunities, one might begin to wonder how they picture your future. Side note: "Software Architect" as a role sounds way too Waterfall to me. People should have varying skills at design, and work together to build the best thing they can. Not have an Architect who claims omniscience and designs the whole project up from.
bad_user 12y ago
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.

EGreg 12y ago

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

betadreamer 12y ago

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 12y ago
http://www.folklore.org/StoryView.py?story=Negative_2000_Lines_Of_Code.txt http://www.folklore.org/StoryView.py?story=Negative_2000_Lin... Very likely Apple.
- anon4 12y ago
  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.
deleted 12y ago
[deleted]

calroc 12y ago

"... 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/EWD1036.html https://www.cs.utexas.edu/~EWD/transcriptions/EWD10xx/EWD103...

christiangenco 12y ago
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_Lines_Of_Code.txt http://www.folklore.org/StoryView.py?story=Negative_2000_Lin...

sytelus 12y ago

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).

thom 12y ago

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.

mobiuscog 12y ago

As with most things, the modern age dictates that speed and quantity are better than quality. It should be the 'thought' that counts.