8 ms·

Wow, as someone who is going to start doing Computer Science next year, I had already heard that most of programming is about thinking, but had no idea that is

Wow, as someone who is going to start doing Computer Science next year, I had already heard that most of programming is about thinking, but had no idea that is was to the point of 5 lines of code per day being exceptional.

javert 12y ago
Don't wait until next year. Start programming now. School is good to learn computer science; school is not needed to learn how to program. Don't read anything into the 5 lines of code per day. This is a pretty old article and even then, that would only be a reasonable figure if you take a large number of people on a large project and compute an average for everyone. In other words, counting refactoring, fixing bugs, re-writing things, doing administrative work, and so on towards the time elapsed. And even then it would vary so much from one project to the next that you couldn't get a reasonable representative number, though 5 LOC per day would certainly be possible.
- jebediah 12y ago
  I have already started programming, it is just that all the problem sets I have solved were easy enough that I could get to coding right away, and when I couldn't I just thought I was dumb
  - javert 12y ago
    Don't ever let yourself think you are dumb. It's a lot more harmful to your psychology and to learning than it may at frist appear. If you can't figure something out, you are just lacking some knowledge you need. I wish I had learned that a long time ago. Being dumb is never the explanation for not understanding or figuring out something.
f2f 12y ago
don't be discouraged, it's par for the course. we're talking about quality lines of code: debugged, qa'd, and working as expected. perhaps even after the customer has had a chance to peruse the beta. you will be surprised how much time you'll spend in meetings and how hard navigating and contributing to large projects becomes. curiously, the number of lines of quality code expected by a developer has not changed much since "the mythical man month" was written, which was about IBM machines in the 60s, despite the obvious advances in programming languages and programming environments. it's still around 10 or so.
aidenn0 12y ago
Remember that you will spend more time debugging, documenting and testing your code. And this is if you work somewhere that doesn't expect you to spend 10+ hours a week in meetings. [edit] And you will also write a lot of code you throw away; sometimes you need to solve 90% of the problem the wrong way to discover the right way.
swatow 12y ago
No, this is just an extreme example of the "don't try to be a smart guy" ideology. In practice 100-500 LOC per day is normal.
- elpachuco 12y ago
  100-500 LOC per day is normal. It is not. You are not writing a novel here. Yes, most of the time is spent thinking. Some days there is no coding because it is spent on just trying to figure out what to do.
  - chroma 12y ago
    While emotions may run high, it's important to remember that this is an empirical dispute. It can be resolved simply by looking at everyone's git history. For myself, the least code I've written on any day in the past year is 20 lines. My average is around 100. The most is a tad over 1500. Of course everyone's different and LoC is a terrible measure and it depends on the language, task at hand, etc. But in general, most of my time is spent "honing" code; testing/fixing corner cases and working around issues in other software. "Other software" includes browsers, filesystems, databases, JITs, but mostly browsers. I personally don't spend much time thinking about software-related problems. At the risk of sounding conceited, I'll admit that most problems I encounter are pretty straightforward. Five minutes of uninterrupted thought is more than enough to get into diminishing returns. It would be very interesting if GitHub pulled an OKCupid and published some statistical analysis of programmer behavior. They could put many of these disagreements to rest.
    - woah 12y ago
      I'm curious to hear about how many problems you solve with these lines of code. I guess that's pretty much impossible to quantify though. Also, what languages do you work in? I'm not that experienced, but I had a notable experience working with a 5000+ loc app that was a nightmare to maintain and extend. The last guy had basically reinvented every wheel. He was even, in my opinion, reimplementing the DOM in places with absolute positioning. Also, the code was poorly organized, with pieces of logic that could have been easily consolidated appearing throughout the app in multiple places so that they could not be abstracted out. After about a month of trudging through his code and making almost no progress, I basically told my manager that we had to rewrite it (I had been thinking this the whole time, but I didn't want to be the junior dev who comes in and demands to scrap everything). Me and a colleague paired on it for about 2 weeks and rewrote the whole thing entirely from scratch, leveraging several open source libraries and writing a few tested "internal libraries". The whole thing ended up being around ~800 loc when we were done, and it had the extra features that needed to be added, and was pretty bug free. I'm not trying to blow my own horn here, in other instances I have spent way too long pondering about code and making it way more concise than necessary. But unless you are a truly great coder who is cranking out 100 lines of good code per day (and I have no doubt that you are), I would be pretty suspicious about the amount that you are writing. I would worry that you are placing a great maintenance load on those who come after you.
deleted 12y ago
[deleted]
barrkel 12y ago
Green-field software should be well in excess of 5 lines a day. If the software is old to the point that nobody fully understands it any more, and previous maintainers have left the company, the number of production lines of code added per day may easily be lower than 5. Older code has a lot more functionality, so every line of code is capable of leveraging more. 5 lines of code in a mature system may do more than 500 lines in a new system. But a bigger factor is figuring out which 5 lines to write. A third of the time can easily be spent researching the code trying to figure out a plan of attack, and the remainder iteratively debugging different variations of 5 lines validating (or invalidating) assumptions made about the code's emergent design during the planning phase. And I'm not counting test code. Test code is usually cheap to write, if the code is testable. Writing lots of tests is an easy way to inflate lines written, should you be stuck somewhere in the dark ages where they actually measure productivity by such a discredited yardstick.
patrickmay 12y ago
When working on an existing system, I find it's a good sign if your SLOC/day count goes negative for a while.
- chrisbennet 12y ago
  That is wisdom...
- dredmorbius 12y ago
  One contract I had, I dropped the line count of an inherited codebase by 50%. Much of which was necessary to simply be able to run (and debug) it interactively. It still ran. It ran correctly. It ran faster than previously. I never quite grasped what it was doing. The company folded some time after I left it.
hibikir 12y ago
In my experience, as an outrageously well paid programmer, I will touch a lot more than 5 lines a day whenever I am programming, especially if I include changes to the unit tests, integration tests and such. There are two caveats though: First, you will not be coding every day. There's requirements gathering, setting up environments, build systems and such. Depending on what you are working on, this could be over 50% of your time. And second, and perhaps more importantly, most of the lines you touch will replace lines that you, or someone else, has written in the past, instead of just adding more functionality without touching the existing codebase. For instance, 5 months ago I started working on a project that had been written by two junior programmers that did not understand the language they were using, functional programming, or the problem they were solving. The code was full of repetition, bugs, and there was no way to make heads or tails of what it was actually solving. So I started refactoring, working on eliminating duplication, and trying to build abstractions. After a week, I had made a good dozen commits every day, but they were on top of each other: total LOC actually went down. Only after that week of coding that didn't add to the codebase I could see the places where refactoring just wouldn't do anymore, and was able to figure out what to rewrite, and how to add the additional requirements. So I had spent a month on a 15K LOC codebase, and ended up with 12K LOC that did more, had more tests, ran faster, and made sense to the people that would end up owning the product in the long term. But yes, I mucked with over 100 lines of code most days. Situations like that happen to experienced programmers all the time.
jqm 12y ago
For me, lines of code per day varies depending on what is being done and how. If it's a meaty problem that is not well understood, or a language or framework I'm unfamiliar with, or I sense the situation is complex enough that an early bad decision could lead to unforeseen troubles later (and I should tread carefully), very few or no lines are written during the day. On the other hand, if it is similar to a thing I have done many times before, and I'm comfortable with the problem, the language and framework then there is much less time thinking and StackOverflowing and I can go at nearly typing speed. (Likewise, if the code is quick "one of" type things for tests or throwaway stuff). More than several hundred lines of code a day (JS or Python) in cases like these is very achievable. This doesn't count things like html templates, css etc (although sometime that take a bit of thought as well).

javert 12y ago

Don't wait until next year. Start programming now. School is good to learn computer science; school is not needed to learn how to program. Don't read anything into the 5 lines of code per day. This is a pretty old article and even then, that would only be a reasonable figure if you take a large number of people on a large project and compute an average for everyone. In other words, counting refactoring, fixing bugs, re-writing things, doing administrative work, and so on towards the time elapsed. And even then it would vary so much from one project to the next that you couldn't get a reasonable representative number, though 5 LOC per day would certainly be possible.

jebediah 12y ago
I have already started programming, it is just that all the problem sets I have solved were easy enough that I could get to coding right away, and when I couldn't I just thought I was dumb
- javert 12y ago
  Don't ever let yourself think you are dumb. It's a lot more harmful to your psychology and to learning than it may at frist appear. If you can't figure something out, you are just lacking some knowledge you need. I wish I had learned that a long time ago. Being dumb is never the explanation for not understanding or figuring out something.

f2f 12y ago

don't be discouraged, it's par for the course. we're talking about quality lines of code: debugged, qa'd, and working as expected. perhaps even after the customer has had a chance to peruse the beta. you will be surprised how much time you'll spend in meetings and how hard navigating and contributing to large projects becomes. curiously, the number of lines of quality code expected by a developer has not changed much since "the mythical man month" was written, which was about IBM machines in the 60s, despite the obvious advances in programming languages and programming environments. it's still around 10 or so.

aidenn0 12y ago

Remember that you will spend more time debugging, documenting and testing your code. And this is if you work somewhere that doesn't expect you to spend 10+ hours a week in meetings. [edit] And you will also write a lot of code you throw away; sometimes you need to solve 90% of the problem the wrong way to discover the right way.

swatow 12y ago

No, this is just an extreme example of the "don't try to be a smart guy" ideology. In practice 100-500 LOC per day is normal.

elpachuco 12y ago
100-500 LOC per day is normal. It is not. You are not writing a novel here. Yes, most of the time is spent thinking. Some days there is no coding because it is spent on just trying to figure out what to do.
- chroma 12y ago
  While emotions may run high, it's important to remember that this is an empirical dispute. It can be resolved simply by looking at everyone's git history. For myself, the least code I've written on any day in the past year is 20 lines. My average is around 100. The most is a tad over 1500. Of course everyone's different and LoC is a terrible measure and it depends on the language, task at hand, etc. But in general, most of my time is spent "honing" code; testing/fixing corner cases and working around issues in other software. "Other software" includes browsers, filesystems, databases, JITs, but mostly browsers. I personally don't spend much time thinking about software-related problems. At the risk of sounding conceited, I'll admit that most problems I encounter are pretty straightforward. Five minutes of uninterrupted thought is more than enough to get into diminishing returns. It would be very interesting if GitHub pulled an OKCupid and published some statistical analysis of programmer behavior. They could put many of these disagreements to rest.
  - woah 12y ago
    I'm curious to hear about how many problems you solve with these lines of code. I guess that's pretty much impossible to quantify though. Also, what languages do you work in? I'm not that experienced, but I had a notable experience working with a 5000+ loc app that was a nightmare to maintain and extend. The last guy had basically reinvented every wheel. He was even, in my opinion, reimplementing the DOM in places with absolute positioning. Also, the code was poorly organized, with pieces of logic that could have been easily consolidated appearing throughout the app in multiple places so that they could not be abstracted out. After about a month of trudging through his code and making almost no progress, I basically told my manager that we had to rewrite it (I had been thinking this the whole time, but I didn't want to be the junior dev who comes in and demands to scrap everything). Me and a colleague paired on it for about 2 weeks and rewrote the whole thing entirely from scratch, leveraging several open source libraries and writing a few tested "internal libraries". The whole thing ended up being around ~800 loc when we were done, and it had the extra features that needed to be added, and was pretty bug free. I'm not trying to blow my own horn here, in other instances I have spent way too long pondering about code and making it way more concise than necessary. But unless you are a truly great coder who is cranking out 100 lines of good code per day (and I have no doubt that you are), I would be pretty suspicious about the amount that you are writing. I would worry that you are placing a great maintenance load on those who come after you.

deleted 12y ago

[deleted]

barrkel 12y ago

Green-field software should be well in excess of 5 lines a day. If the software is old to the point that nobody fully understands it any more, and previous maintainers have left the company, the number of production lines of code added per day may easily be lower than 5. Older code has a lot more functionality, so every line of code is capable of leveraging more. 5 lines of code in a mature system may do more than 500 lines in a new system. But a bigger factor is figuring out which 5 lines to write. A third of the time can easily be spent researching the code trying to figure out a plan of attack, and the remainder iteratively debugging different variations of 5 lines validating (or invalidating) assumptions made about the code's emergent design during the planning phase. And I'm not counting test code. Test code is usually cheap to write, if the code is testable. Writing lots of tests is an easy way to inflate lines written, should you be stuck somewhere in the dark ages where they actually measure productivity by such a discredited yardstick.

patrickmay 12y ago

When working on an existing system, I find it's a good sign if your SLOC/day count goes negative for a while.

chrisbennet 12y ago
That is wisdom...
dredmorbius 12y ago
One contract I had, I dropped the line count of an inherited codebase by 50%. Much of which was necessary to simply be able to run (and debug) it interactively. It still ran. It ran correctly. It ran faster than previously. I never quite grasped what it was doing. The company folded some time after I left it.

hibikir 12y ago

In my experience, as an outrageously well paid programmer, I will touch a lot more than 5 lines a day whenever I am programming, especially if I include changes to the unit tests, integration tests and such. There are two caveats though: First, you will not be coding every day. There's requirements gathering, setting up environments, build systems and such. Depending on what you are working on, this could be over 50% of your time. And second, and perhaps more importantly, most of the lines you touch will replace lines that you, or someone else, has written in the past, instead of just adding more functionality without touching the existing codebase. For instance, 5 months ago I started working on a project that had been written by two junior programmers that did not understand the language they were using, functional programming, or the problem they were solving. The code was full of repetition, bugs, and there was no way to make heads or tails of what it was actually solving. So I started refactoring, working on eliminating duplication, and trying to build abstractions. After a week, I had made a good dozen commits every day, but they were on top of each other: total LOC actually went down. Only after that week of coding that didn't add to the codebase I could see the places where refactoring just wouldn't do anymore, and was able to figure out what to rewrite, and how to add the additional requirements. So I had spent a month on a 15K LOC codebase, and ended up with 12K LOC that did more, had more tests, ran faster, and made sense to the people that would end up owning the product in the long term. But yes, I mucked with over 100 lines of code most days. Situations like that happen to experienced programmers all the time.

jqm 12y ago

For me, lines of code per day varies depending on what is being done and how. If it's a meaty problem that is not well understood, or a language or framework I'm unfamiliar with, or I sense the situation is complex enough that an early bad decision could lead to unforeseen troubles later (and I should tread carefully), very few or no lines are written during the day. On the other hand, if it is similar to a thing I have done many times before, and I'm comfortable with the problem, the language and framework then there is much less time thinking and StackOverflowing and I can go at nearly typing speed. (Likewise, if the code is quick "one of" type things for tests or throwaway stuff). More than several hundred lines of code a day (JS or Python) in cases like these is very achievable. This doesn't count things like html templates, css etc (although sometime that take a bit of thought as well).