In every language you can take 100 LOC and compress them into less than half if you abstract it and optimize it. What I mean is that LOC doesn't tell you much about your software, but there is a a point where there is probably a lot of repetitive logic and more likely to have issues because it's not abstracted properly.
The hard part about programming is not writing down some syntax that does some function. The hard part is designing the system to scale properly as you add more features, it's dividing the problem into parts that make sense so that they can be easily understood and reasoned about. Typing the solution into an editor is one of the easy steps once you understand the solution.
15 (just 15, not k) is par for a corporate dev on a good team. 100-300 is what you might expect from a "10x engineer" or independent dev consistently in the flow state.
1k lines is too much to even review in a day and I would assume it's useless.
Typical disclaimers "lines != Statements != Productivity" apply. Also I'm not counting things like unit tests and documentation.
My heuristics for assessing the difficulty of changes revolve around "load bearing-ness".
It's basically free to change code no one uses. It's not bearing any load. If your metric is LOC you can be very "productive"! But from another perspective you cannot tell if you are productive yet, the value is not realized until people pay for it and rely on it.
Changes in software that people use affect "load bearing" LOC. There is "pucker factor".
You can kinda multiply together: what is the inherent complexity of the domain, is the change reversible, is your change stateful, how many customers use it, how deeply do they interface with it, how many stakeholders are involved in the change, what are the consequences of failure / mistakes, how many cases / paths do you need to test - to get a feel for the true difficulty of a change.
The difficulty of a change is separate from the value it creates, but often they're related. Why? Because in widely used software if a thing lots of people valued was easy, it would already be done. Of course pathologies do exist where people do difficult things for no good reason or foolishly leave easy money on the table.
Greenfields / startups are a special case / time, where difficulty seems temporarily uncoupled from value. You can make huge and potentially valuable changes quickly and easily if no one is using your thing. But there is no free lunch because the downside is that you are only creating potential value, you still have risk that all the code you wrote is useless.
This is why some some people might say 30 LOC / day is a lot while others might name a much higher number. The people saying the lower number are the ones with existing customers, they are talking about "load bearing" LOC.
I'd say a very useful and simple formula one could device can look something like:
f(n) = x/y.
value = goal/loc.
"goal" here is just arbitrary number of usefullnes of code that aligns with some common uility like say 10 = ASI/eternal happiness and immortaility or whatever
while 1 being 'terminator' and 7, 8 being useful business code so on. loc is self-expplanatory.
So, the very best value possible will be say "d" 10, f(n) = 10/1 - any other of the 4 possible permutations aka options will lead to worse result:
But while such simple formula could illustrate the value of software project overall, a key detail ommited could be the lowest possible number a
great goal may require, most people would agree writing ASI in just <100 words aka 'one line' is just not possible, or anything useful.
It's like complaining you could write 100 000 a day when the project is Operating system or 3dsmax clone, it surely will be better to finish it early and there is a lowest bar possible that cannot be decreased even with F# or whatever language that saves words.
I was not able to make much sense of that, but if you can create 10k+ lines of good C per day regardless of domain complexity, requirements etc, you could create ffmpeg solo including all codecs in under 6 months.
That would make you, approximately, the best programmer in the world.
well maybe but btw i swear this almost looks like P=NP but rather reversed P=NP lol, let me explain...in the classic p=np problem given to explain it it's the subset problem where it's easy to verify a solution, but not find it {25,39,22,12,29,18} - do any 2 numbers add to 47 and yeah the last 2 numbers: 18 and 29 add to 47. Yet here if you use LLM to make great product, you have a "solution" pretty quickly but verifying it will take some time...be it to test functionality or read every single line and understand it. It's such a weird logical puzzle! The llm throws you the solution basically saying 'i did it' and your verification takes longer, another way to look at is that your verification is the real solution while the code generation is the "verification"...confusing a lot.
edit: in my previous post i meant that the higher the challenge of the program / the lowest possible lines of code to implement it will be the best possible software one can make. So a software rated 10/10 in every aspect possible implemented in just a single line of code is the best possible program. If you write it in more lines of code, it's worse in terms of value, if you decrease the quality but keep the loc low...it's still not optimal since you sacrifice quality, if you decrease the quality but increase the loc that's the worst possible case.
It sucks to do a 2-line change that requires 2 weeks of validation :/
Agree that codegen can flip the effort from creating to validating. Some people believe the "true" intellectual capital created by the software development process is the understanding created inside the team's mind as they build it (not the code itself). Like, understanding of the domain, customers, market, how the software works, how they would build it again if they had the chance, their networks and relationships etc.
Probably it does hurt if codegen impacts that process. It's always been possible to externalise some of that understanding, by writing books, articles etc. I suppose what we are starting to see is that kind of intellectual capital will gradually reside in AI also. For well understood problems (TODO app, space invaders, etc) the model will have the actual understanding and everyone generating those apps for the first time would need to build it up.
I agree that 1 LOC that provides infinite value sounds like the "best possible program", but beyond that I can't see any hard and fast rules about LOC vs value, I think they're almost entirely uncorrelated. Mostly it's about what the lines do, but even then it's hard. What's more valuable: the bible, the script to star wars or a set of 747 technical manuals? Should they have used more or fewer words to achieve their goals?
Even with precise specifications the "best" way to implement large scale software is never clear and depends on many factors. Sometimes more duplication is better, sometimes you need more abstraction to reduce it. A lot depends on what your team (or contributors) are comfortable with and their abstraction ceiling.
I spent Friday and today using Copilot on a project and I (or it) wrote about 13k LOC: about 5k LOC of python code, 6k LOC jupyter notebooks and 2k LOC markdown files with agent orchestration. My time was spent waiting for Copilot to do the coding, then running tests and making sure they pass and they are meaningful, and then debugging. The debugging is a very interesting experience. You devise various tests to tease out what's going wrong and narrow down to a very small context so the issue becomes apparent to both you and the LLM. I didn't actually write a single line of python code myself. But a junior developer would have gotten stuck at the first problem that required debugging. These two days felt a lot like hard work. The only difference is that I have much more to show for after 2 days of work than I used to have in the past.
5k in python is tremendous since the lack of {()} will make reading a long function quite the journey, this is of course my naive assumption that some of the functions are very long, in theory you could just put 1000 functions each of which 5 lines but i doubt that's the case in practice, the LLMs tend to give long and detailed statements from time to time.
The 5k lines of code are spread over 44 files. Most of this code is testing code. Just about 2k LOC are functional code. The functions are generally small. Only 5 functions have more than 100 LOC, and all have less than 200 LOC. All the functions have generous docstrings. I set up a system with a manager agent that would create action plans and executor agents that would execute, and then the manager had to review and accept the execution, and if not (it did happen once), the executor had to resume the execution until the manager confirmed the task was done. I stumbled upon this workflow by myself, and so far it looks like it works.
Thousands of lines of code per day is an enormous red flag. That is well beyond your ability to write or review on your own in a single workday.
Pumping out that much code means you're not putting thought, care, or professionalism into the work. You're pumping out garbage and making it everyone else's problem to clean up.
If I saw anyone other than a greybeard developer pushing out code like this, I'd fire them. Very, very few people can actually work at this level and produce good code. Everyone else is just shitting out slop, ruining the product, and dragging down the entire team.
Additionally, only extremely inexperienced and naïve developers even think about LOC counts. If you're focusing on this, it tells me you have no idea what you're doing and that the code you're putting out has about as much value and utility as the shit my dog took this morning.
a good way to look at it is that problems solved is an asset, but lines of code are a liability. you pay the cost of maintaining that code because you want the benefit of the problems it solves.
note that LLM-generated code is even more of a liability because when you go to maintain it you will not have the context of the decisions that went into writing it - it's legacy code from day one.
Rmember when we had to create programs reading the assembler manual and put byte by byte? It was kinda hard. Then someone invented a language. A compiler started to do all the work you did not wanted to do. And the time you took to create a program came from months to minutes.
My only question is, why use something like that Grok since you know who runs that.
It's in the post above lol "couple of days ago" - i had quite the fallout with Grok since like august ~17th when it started ignoring my questions about my mental health (literally just skipping them) on 2 occassions when it was online and 100% operational. I prefer chatgpt, claude is great for code too.
Before that I used it because i guess i was too lazy to signup on openai and just use my twitter profile -> Grok...already logged in etc.
It's a big deal if LOC is proportional to how much money you make. Otherwise it's an unequivocal burden, you can't pay me any amount to adopt a 10,000 SLOC C99 codebase.
In every language you can take 100 LOC and compress them into less than half if you abstract it and optimize it. What I mean is that LOC doesn't tell you much about your software, but there is a a point where there is probably a lot of repetitive logic and more likely to have issues because it's not abstracted properly.
The hard part about programming is not writing down some syntax that does some function. The hard part is designing the system to scale properly as you add more features, it's dividing the problem into parts that make sense so that they can be easily understood and reasoned about. Typing the solution into an editor is one of the easy steps once you understand the solution.
15 (just 15, not k) is par for a corporate dev on a good team. 100-300 is what you might expect from a "10x engineer" or independent dev consistently in the flow state.
1k lines is too much to even review in a day and I would assume it's useless.
Typical disclaimers "lines != Statements != Productivity" apply. Also I'm not counting things like unit tests and documentation.
LOC are not all the same.
My heuristics for assessing the difficulty of changes revolve around "load bearing-ness".
It's basically free to change code no one uses. It's not bearing any load. If your metric is LOC you can be very "productive"! But from another perspective you cannot tell if you are productive yet, the value is not realized until people pay for it and rely on it.
Changes in software that people use affect "load bearing" LOC. There is "pucker factor".
You can kinda multiply together: what is the inherent complexity of the domain, is the change reversible, is your change stateful, how many customers use it, how deeply do they interface with it, how many stakeholders are involved in the change, what are the consequences of failure / mistakes, how many cases / paths do you need to test - to get a feel for the true difficulty of a change.
The difficulty of a change is separate from the value it creates, but often they're related. Why? Because in widely used software if a thing lots of people valued was easy, it would already be done. Of course pathologies do exist where people do difficult things for no good reason or foolishly leave easy money on the table.
Greenfields / startups are a special case / time, where difficulty seems temporarily uncoupled from value. You can make huge and potentially valuable changes quickly and easily if no one is using your thing. But there is no free lunch because the downside is that you are only creating potential value, you still have risk that all the code you wrote is useless.
This is why some some people might say 30 LOC / day is a lot while others might name a much higher number. The people saying the lower number are the ones with existing customers, they are talking about "load bearing" LOC.
I'd say a very useful and simple formula one could device can look something like:
f(n) = x/y. value = goal/loc.
"goal" here is just arbitrary number of usefullnes of code that aligns with some common uility like say 10 = ASI/eternal happiness and immortaility or whatever while 1 being 'terminator' and 7, 8 being useful business code so on. loc is self-expplanatory.
>goal / >loc -> < 10/1 a; <goal / >loc -> < 10/1 b; <goal / <loc -> < 10/1 c; >goal / <loc -> = 10/1 d
So, the very best value possible will be say "d" 10, f(n) = 10/1 - any other of the 4 possible permutations aka options will lead to worse result:
But while such simple formula could illustrate the value of software project overall, a key detail ommited could be the lowest possible number a great goal may require, most people would agree writing ASI in just <100 words aka 'one line' is just not possible, or anything useful.
It's like complaining you could write 100 000 a day when the project is Operating system or 3dsmax clone, it surely will be better to finish it early and there is a lowest bar possible that cannot be decreased even with F# or whatever language that saves words.
I was not able to make much sense of that, but if you can create 10k+ lines of good C per day regardless of domain complexity, requirements etc, you could create ffmpeg solo including all codecs in under 6 months.
That would make you, approximately, the best programmer in the world.
well maybe but btw i swear this almost looks like P=NP but rather reversed P=NP lol, let me explain...in the classic p=np problem given to explain it it's the subset problem where it's easy to verify a solution, but not find it {25,39,22,12,29,18} - do any 2 numbers add to 47 and yeah the last 2 numbers: 18 and 29 add to 47. Yet here if you use LLM to make great product, you have a "solution" pretty quickly but verifying it will take some time...be it to test functionality or read every single line and understand it. It's such a weird logical puzzle! The llm throws you the solution basically saying 'i did it' and your verification takes longer, another way to look at is that your verification is the real solution while the code generation is the "verification"...confusing a lot.
edit: in my previous post i meant that the higher the challenge of the program / the lowest possible lines of code to implement it will be the best possible software one can make. So a software rated 10/10 in every aspect possible implemented in just a single line of code is the best possible program. If you write it in more lines of code, it's worse in terms of value, if you decrease the quality but keep the loc low...it's still not optimal since you sacrifice quality, if you decrease the quality but increase the loc that's the worst possible case.
It sucks to do a 2-line change that requires 2 weeks of validation :/
Agree that codegen can flip the effort from creating to validating. Some people believe the "true" intellectual capital created by the software development process is the understanding created inside the team's mind as they build it (not the code itself). Like, understanding of the domain, customers, market, how the software works, how they would build it again if they had the chance, their networks and relationships etc.
Probably it does hurt if codegen impacts that process. It's always been possible to externalise some of that understanding, by writing books, articles etc. I suppose what we are starting to see is that kind of intellectual capital will gradually reside in AI also. For well understood problems (TODO app, space invaders, etc) the model will have the actual understanding and everyone generating those apps for the first time would need to build it up.
I agree that 1 LOC that provides infinite value sounds like the "best possible program", but beyond that I can't see any hard and fast rules about LOC vs value, I think they're almost entirely uncorrelated. Mostly it's about what the lines do, but even then it's hard. What's more valuable: the bible, the script to star wars or a set of 747 technical manuals? Should they have used more or fewer words to achieve their goals?
Even with precise specifications the "best" way to implement large scale software is never clear and depends on many factors. Sometimes more duplication is better, sometimes you need more abstraction to reduce it. A lot depends on what your team (or contributors) are comfortable with and their abstraction ceiling.
I spent Friday and today using Copilot on a project and I (or it) wrote about 13k LOC: about 5k LOC of python code, 6k LOC jupyter notebooks and 2k LOC markdown files with agent orchestration. My time was spent waiting for Copilot to do the coding, then running tests and making sure they pass and they are meaningful, and then debugging. The debugging is a very interesting experience. You devise various tests to tease out what's going wrong and narrow down to a very small context so the issue becomes apparent to both you and the LLM. I didn't actually write a single line of python code myself. But a junior developer would have gotten stuck at the first problem that required debugging. These two days felt a lot like hard work. The only difference is that I have much more to show for after 2 days of work than I used to have in the past.
5k in python is tremendous since the lack of {()} will make reading a long function quite the journey, this is of course my naive assumption that some of the functions are very long, in theory you could just put 1000 functions each of which 5 lines but i doubt that's the case in practice, the LLMs tend to give long and detailed statements from time to time.
The 5k lines of code are spread over 44 files. Most of this code is testing code. Just about 2k LOC are functional code. The functions are generally small. Only 5 functions have more than 100 LOC, and all have less than 200 LOC. All the functions have generous docstrings. I set up a system with a manager agent that would create action plans and executor agents that would execute, and then the manager had to review and accept the execution, and if not (it did happen once), the executor had to resume the execution until the manager confirmed the task was done. I stumbled upon this workflow by myself, and so far it looks like it works.
Thousands of lines of code per day is an enormous red flag. That is well beyond your ability to write or review on your own in a single workday.
Pumping out that much code means you're not putting thought, care, or professionalism into the work. You're pumping out garbage and making it everyone else's problem to clean up.
If I saw anyone other than a greybeard developer pushing out code like this, I'd fire them. Very, very few people can actually work at this level and produce good code. Everyone else is just shitting out slop, ruining the product, and dragging down the entire team.
Additionally, only extremely inexperienced and naïve developers even think about LOC counts. If you're focusing on this, it tells me you have no idea what you're doing and that the code you're putting out has about as much value and utility as the shit my dog took this morning.
a good way to look at it is that problems solved is an asset, but lines of code are a liability. you pay the cost of maintaining that code because you want the benefit of the problems it solves.
note that LLM-generated code is even more of a liability because when you go to maintain it you will not have the context of the decisions that went into writing it - it's legacy code from day one.
It its just a tool, use it as a tool.
Rmember when we had to create programs reading the assembler manual and put byte by byte? It was kinda hard. Then someone invented a language. A compiler started to do all the work you did not wanted to do. And the time you took to create a program came from months to minutes.
My only question is, why use something like that Grok since you know who runs that.
It's in the post above lol "couple of days ago" - i had quite the fallout with Grok since like august ~17th when it started ignoring my questions about my mental health (literally just skipping them) on 2 occassions when it was online and 100% operational. I prefer chatgpt, claude is great for code too. Before that I used it because i guess i was too lazy to signup on openai and just use my twitter profile -> Grok...already logged in etc.
SLOC as a metric of productivity was always useless. AI only proves this more.
It's a big deal if LOC is proportional to how much money you make. Otherwise it's an unequivocal burden, you can't pay me any amount to adopt a 10,000 SLOC C99 codebase.