6 ms·

I recently replaced ~2000 lines of code written my predecessor with about 200 lines. The resulting code also performed 1000 times faster. After many years of r

I recently replaced ~2000 lines of code written my predecessor with about 200 lines. The resulting code also performed 1000 times faster. After many years of real world experience I developed the following rule of thumb. A competent, experienced developer should produce about 20 lines of code per day, on average, to have any hope for a decent code quality. I am talking about high level languages with big standard libraries and reach ecosystems like python. At that rate 300,000 lines of code is ~41 menyears.

simplify 8y ago
You should probably scope and clarify your rule of thumb. For example, writing a function that renders readable error messages to a UI will be far more than 20 lines of code.
- Boxxed 8y ago
  So? That means it will take more than one day to write, by this metric.
  - simplify 8y ago
    If you have your list of possible errors, it really shouldn't take that long to write a `errorObj -> string` function.
- Jtsummers 8y ago
  It’s an average. Novel problems: low SLOC/day. Common or “solved” (but not implemented) problems: high SLOC. EDIT: “Autocorrect” got me.
k__ 8y ago
I think when writing UI or 3D code 20 LoC/day isn't enough, but yes there are probably parts of the stack where this holds true.
- pmiller2 8y ago
  It’s an average. It’s also 20 lines of tested and debugged code per day. Once you factor those things in, it becomes a lot more reasonable as an average.
ams6110 8y ago
I remember when I was in school and first heard that professional developers average about 20 LOC/day. I thought it was ridiculous, because as a student I regularly banged out much more than that in few hours for class assignments. Little did I know what i didn't yet know.
zorga 8y ago
> A competent, experienced developer should produce about 20 lines of code per day, on average, to have any hope for a decent code quality. That's simply measuring the wrong thing altogether. Lines of code per day produced is simply not a valid metric at all. It's just a bad metric period no matter what number you put on it. You cannot measure the quality of a dev by the lines of code he produces, at all.
- deleted 8y ago
  [deleted]
- Xophmeister 8y ago
  The OP isn't saying "20loc/day implies good developer", his implication is the other way around. That is, at least how I read it, a good developer -- with high-productivity tools -- nets about 20loc/day.
  - HugoDaniel 8y ago
    if (false) { // my daily 20 lines here // ... }
  - zorga 8y ago
    > That is, at least how I read it, a good developer -- with high-productivity tools -- nets about 20loc/day. And I'm saying that's still a terrible measure and not accurate. LOC is simply not a valid statistic to even look at. It's an example of lying with statistics; you could take a thousand good developers and you'd probably find their LOC per day counts all over the board. The amount of code you write is not a measure of how good a developer you are whether it's high or low. That's not how you measure a good developer. The OP is trying to say looking for high LOC counts are not a measure of a good developer, and he's right; but he's failed to realize yet that the metric itself is what's bad, not the values derived from it. Good developers don't have to be highly productive, but they might be; what matters are the results of their efforts. Do they produce good programs, with few bugs, that age well over time, and are easy to change to adapting circumstances. Good developers write good code; some write more than others, but LOC tells you nothing about how good a developer is whether that number is high or low. Like any writing, it's the quality of the code that matters, not the quantity. You cannot measure quality by looking at quantity.
nostrademons 8y ago
It's implied in the article that 300,000 lines of code is the total written by the company (of which the author is a founder), not by the individual author. With a company that's 3 years old, 41 man-years implies a staff of roughly 15-20, which is quite reasonable for a startup.
- thecatspaw 8y ago
  That sounds reasonable for application code. 15-20 People working on architecture code for 3 years? That sounds like an unreasonable amount of developers dedicated to devops for a startup
  - nostrademons 8y ago
    The startup's whole product is DevOps - their elevator pitch is literally "DevOps as a service".
- ojosilva 8y ago
  And written for "hundreds" of clients according to the author, which basically implies a good chunk of the 300k lines to be duplicates, with a relative ammount of customization.
TheAceOfHearts 8y ago
It's not uncommon to refine things as a project evolves. I've had a few cases where I ended up replacing some huge messy code with a simpler and better performing alternative, however in my case I was also often the one to have written the original. Not that I consider this a bad thing, since it highlights the experience increase and skill progression that took place in-between. I can't say I agree with your rule of thumb. How'd you reach that number? In my experience the number fluctuates wildly depending on what tasks you're working on. Your output will usually shoot up while a project is young or you're working on a new well-defined feature, and it'll go down as you focus on fixing bugs or improving performance. The best days are when you write negative lines of code. Lines of code is usually not a good signal for code quality. If I pull in a huge new dependency in order to quickly solve a problem then it might seem like my project is maintaining high code quality, but that doesn't paints a complete picture. For each included dependency you should probably have at least one person in your team responsible for maintenance, which includes stuff like: keeping it updated, tracking security issues, checking releases for breaking changes or bugs, updating your code to handle changes or notifying others if the scope is too large, etc. Ideally, they should also be sufficiently familiarized with the code-base to fix bugs or other serious issues which affect you. These points are only meant to serve as a rough example of some of the responsibilities one might be expected to shoulder, but it should be understood that requirements vary based on a large number of factors.
ascar 8y ago
The most impactful change I made in 6 years of professional programming was 1 LOC in one file and about 5 LOC in another file. It was a 10x reduction of queries at a billion queries per day scale. I fixed a broken cache and it took me over two weeks to find the issue. On the other hand I put out hundreds of LOC per hour, when writing the basic HTML for an internal crud app. This metric is as useless as it can be. Even as an average. It has too much to do with your role and tasks.
kakarot 8y ago
That's looking at it completely wrong. The important thing is staying up to date with best practices in your field, and automating away anything you do more than twice. Beyond that, if you're only writing 20 lines of code a day each and every single day, then you're either wasting a lot of your and your employer's time, or your role isn't just programming and you have other things to attend to.
zimbatm 8y ago
Terraform code is easily 10x as verbose as normal code, and it involves a lot of copy-and-paste.
- auslander 8y ago
  > ... as normal code True. ... as Cloudformation template code.
  - zimbatm 8y ago
    True. Maybe it's a general property of infrastructure-as-code code.
orbifold 8y ago
Would be interesting to check to what degree that was true for LLVM, Swift or other high impact projects while they were still in their infancy.

simplify 8y ago

You should probably scope and clarify your rule of thumb. For example, writing a function that renders readable error messages to a UI will be far more than 20 lines of code.

Boxxed 8y ago
So? That means it will take more than one day to write, by this metric.
- simplify 8y ago
  If you have your list of possible errors, it really shouldn't take that long to write a `errorObj -> string` function.
Jtsummers 8y ago
It’s an average. Novel problems: low SLOC/day. Common or “solved” (but not implemented) problems: high SLOC. EDIT: “Autocorrect” got me.

k__ 8y ago

I think when writing UI or 3D code 20 LoC/day isn't enough, but yes there are probably parts of the stack where this holds true.

pmiller2 8y ago
It’s an average. It’s also 20 lines of tested and debugged code per day. Once you factor those things in, it becomes a lot more reasonable as an average.

ams6110 8y ago

I remember when I was in school and first heard that professional developers average about 20 LOC/day. I thought it was ridiculous, because as a student I regularly banged out much more than that in few hours for class assignments. Little did I know what i didn't yet know.

zorga 8y ago

> A competent, experienced developer should produce about 20 lines of code per day, on average, to have any hope for a decent code quality. That's simply measuring the wrong thing altogether. Lines of code per day produced is simply not a valid metric at all. It's just a bad metric period no matter what number you put on it. You cannot measure the quality of a dev by the lines of code he produces, at all.

deleted 8y ago
[deleted]
Xophmeister 8y ago
The OP isn't saying "20loc/day implies good developer", his implication is the other way around. That is, at least how I read it, a good developer -- with high-productivity tools -- nets about 20loc/day.
- HugoDaniel 8y ago
  if (false) { // my daily 20 lines here // ... }
- zorga 8y ago
  > That is, at least how I read it, a good developer -- with high-productivity tools -- nets about 20loc/day. And I'm saying that's still a terrible measure and not accurate. LOC is simply not a valid statistic to even look at. It's an example of lying with statistics; you could take a thousand good developers and you'd probably find their LOC per day counts all over the board. The amount of code you write is not a measure of how good a developer you are whether it's high or low. That's not how you measure a good developer. The OP is trying to say looking for high LOC counts are not a measure of a good developer, and he's right; but he's failed to realize yet that the metric itself is what's bad, not the values derived from it. Good developers don't have to be highly productive, but they might be; what matters are the results of their efforts. Do they produce good programs, with few bugs, that age well over time, and are easy to change to adapting circumstances. Good developers write good code; some write more than others, but LOC tells you nothing about how good a developer is whether that number is high or low. Like any writing, it's the quality of the code that matters, not the quantity. You cannot measure quality by looking at quantity.

nostrademons 8y ago

It's implied in the article that 300,000 lines of code is the total written by the company (of which the author is a founder), not by the individual author. With a company that's 3 years old, 41 man-years implies a staff of roughly 15-20, which is quite reasonable for a startup.

thecatspaw 8y ago
That sounds reasonable for application code. 15-20 People working on architecture code for 3 years? That sounds like an unreasonable amount of developers dedicated to devops for a startup
- nostrademons 8y ago
  The startup's whole product is DevOps - their elevator pitch is literally "DevOps as a service".
ojosilva 8y ago
And written for "hundreds" of clients according to the author, which basically implies a good chunk of the 300k lines to be duplicates, with a relative ammount of customization.

TheAceOfHearts 8y ago

It's not uncommon to refine things as a project evolves. I've had a few cases where I ended up replacing some huge messy code with a simpler and better performing alternative, however in my case I was also often the one to have written the original. Not that I consider this a bad thing, since it highlights the experience increase and skill progression that took place in-between. I can't say I agree with your rule of thumb. How'd you reach that number? In my experience the number fluctuates wildly depending on what tasks you're working on. Your output will usually shoot up while a project is young or you're working on a new well-defined feature, and it'll go down as you focus on fixing bugs or improving performance. The best days are when you write negative lines of code. Lines of code is usually not a good signal for code quality. If I pull in a huge new dependency in order to quickly solve a problem then it might seem like my project is maintaining high code quality, but that doesn't paints a complete picture. For each included dependency you should probably have at least one person in your team responsible for maintenance, which includes stuff like: keeping it updated, tracking security issues, checking releases for breaking changes or bugs, updating your code to handle changes or notifying others if the scope is too large, etc. Ideally, they should also be sufficiently familiarized with the code-base to fix bugs or other serious issues which affect you. These points are only meant to serve as a rough example of some of the responsibilities one might be expected to shoulder, but it should be understood that requirements vary based on a large number of factors.

ascar 8y ago

The most impactful change I made in 6 years of professional programming was 1 LOC in one file and about 5 LOC in another file. It was a 10x reduction of queries at a billion queries per day scale. I fixed a broken cache and it took me over two weeks to find the issue. On the other hand I put out hundreds of LOC per hour, when writing the basic HTML for an internal crud app. This metric is as useless as it can be. Even as an average. It has too much to do with your role and tasks.

kakarot 8y ago

That's looking at it completely wrong. The important thing is staying up to date with best practices in your field, and automating away anything you do more than twice. Beyond that, if you're only writing 20 lines of code a day each and every single day, then you're either wasting a lot of your and your employer's time, or your role isn't just programming and you have other things to attend to.

zimbatm 8y ago

Terraform code is easily 10x as verbose as normal code, and it involves a lot of copy-and-paste.

auslander 8y ago
> ... as normal code True. ... as Cloudformation template code.
- zimbatm 8y ago
  True. Maybe it's a general property of infrastructure-as-code code.

orbifold 8y ago

Would be interesting to check to what degree that was true for LLVM, Swift or other high impact projects while they were still in their infancy.