This is what I always think of when someone tells me that AI will replace coders. I tell them: "A coder can only write about 100 lines of good code a day, but I look forward to when the AI can write 100 million lines of code a day."
-2000 Lines of Code (2007)
121–130 of 222 posts
Re: -2000 Lines of Code (2007)
#122Earlier quoted context omitted.
heh, I note your recent comment history is you being salty about everything you deem "cargo cult agile", and people patiently responding to that. Yes, having a chat between the team for fifteen minutes every day is in fact quite useful, believe it or not. We're not talking about hour long waterfall-y management progress review meetings here.
Daily status updates are not useful. Linux kernel developers don't do them. I trust that nothing is stopping your engineers from having a chat and that their manager doesn't need to schedule their chats for them.
Cargo-culting someone else's process is a bad way to develop good process for your specific team and its needs.
You could use the same logic to claim that "issues and PRs are not useful" because the Linux devs use a mailing list and patches. I think that's obviously absurd, all that this example shows is that a mailing list and patches can be a useful way to develop programs. It says nothing about alternatives at all.
Re: -2000 Lines of Code (2007)
#123There is a deeper lesson here: Someone was thinking of lines of code as an asset, not a cost. It's a an error you also see in junior programmers writing reams and reams of code. The lesson is a harsh one for us code lovers, at least it was for me: Code is a means to an end, and an expensive one at that. The best code is the code never written. Our job is to solve problems, not to write code. You can use LOC as a crud…
This sentiment goes too far in the opposite direction for me. Code that solves a problem is an asset. To carry your analogy forward, code is the concretization of the solution of the problem. The idea of the skyscraper is useless on its own and requires the concrete that materializes it. The skyscraper would become a lot less valuable if you removed the concrete...
Of course, you also don't make the skyscraper better by indefinitely adding concrete. A balance must be found with the right amount to be load bearing but not too much. Just like code.
Re: -2000 Lines of Code (2007)
#124There is a deeper lesson here: Someone was thinking of lines of code as an asset, not a cost. It's a an error you also see in junior programmers writing reams and reams of code. The lesson is a harsh one for us code lovers, at least it was for me: Code is a means to an end, and an expensive one at that. The best code is the code never written. Our job is to solve problems, not to write code. You can use LOC as a crud…
This sentiment goes too far in the opposite direction for me. Code that solves a problem is an asset. To carry your analogy forward, code is the concretization of the solution of the problem. The idea of the skyscraper is useless on its own and requires the concrete that materializes it. The skyscraper would become a lot less valuable if you removed the concrete... Of course, you also don't make the skyscraper better…
It's not a spectrum, instead a duality. An engine is an asset, yet it needs maintenance. Because software is soft, existing assets become yet more stuff to understand, more stuff to fix and keep in sync.
Compare for example a building made of stacked stone, brick, concrete, or modular carbon sheets on rebar
Another example, 100 hotel rooms, rearrange the layout and it's 101 things to do.
The analogies still fail, software updates are more akin to welding an airplane on to a car attached to a subway train. It's less, oh, we need to rework these weldzhere, it's often trying to make the software do something that is radically different. Like inserting a romance chapter into a mystery novel that starts as a chemistry how-to
Re: -2000 Lines of Code (2007)
#125Earlier quoted context omitted.
Daily status updates are not useful. Linux kernel developers don't do them. I trust that nothing is stopping your engineers from having a chat and that their manager doesn't need to schedule their chats for them.
Cargo-culting someone else's process is a bad way to develop good process for your specific team and its needs. You could use the same logic to claim that "issues and PRs are not useful" because the Linux devs use a mailing list and patches. I think that's obviously absurd, all that this example shows is that a mailing list and patches can be a useful way to develop programs. It says nothing about alternatives at all…
What specific needs are met by daily status updates? Professionals outside of software don't do that. The best software projects don't do that. It's very popular in CRUD projects led by non-technical middle management with trust issues.
Re: -2000 Lines of Code (2007)
#126If you measure productivity by LOC, then generally what you will get is lots of LOC. Cut and paste is easy if that's what makes you look good. Of course what companies should really be incentivizing is well written code that is easy to maintain and extend, not bloated cut-n-paste garbage.
And when somebody figures out how to metricize "well written" then that will turn to fecal matter. Re: Goodhart's Law [1] (admittedly meant to be economic, yet applies to most metrics).
Also related to Enshittification (see fecal matter), the platform shifts, no longer prioritizes quality, and instead shifts to whatever "well written" is defined as.
LLM's and especially online song choice algorithms have a heavy dose of this. "Make whatever pop music says is 'well written'" You have included all the keywords necessary to SEO your billboard submission.
Re: -2000 Lines of Code (2007)
#127A corresponding thought-experiment is to consider the results of the opposite situation: if a manager read this article, and simplemindedly decided to measure by lines of code removed instead. Would that make things better or worse?
Cue the perl one line challenges.
Metrics that are team level dashboards and not shared outside of the team are different from pay and promotion incentivized metrics. The same metric can have very different behavioral outcomes between the two scenarios
Re: -2000 Lines of Code (2007)
#128There is a deeper lesson here: Someone was thinking of lines of code as an asset, not a cost. It's a an error you also see in junior programmers writing reams and reams of code. The lesson is a harsh one for us code lovers, at least it was for me: Code is a means to an end, and an expensive one at that. The best code is the code never written. Our job is to solve problems, not to write code. You can use LOC as a crud…
This sentiment goes too far in the opposite direction for me. Code that solves a problem is an asset. To carry your analogy forward, code is the concretization of the solution of the problem. The idea of the skyscraper is useless on its own and requires the concrete that materializes it. The skyscraper would become a lot less valuable if you removed the concrete... Of course, you also don't make the skyscraper better…
Agreed. And a point that keeps getting missed whenever this discussion comes up is there's a big difference between junior and senior programmers. What should a junior programmer do? Write as much code as possible! KLOC is a pretty good measure of progress for junior programmers, how else do you get better at programming? To know when not to write a line of code, you have to know how to write the line of code in the first place.
Re: -2000 Lines of Code (2007)
#129A corresponding thought-experiment is to consider the results of the opposite situation: if a manager read this article, and simplemindedly decided to measure by lines of code removed instead. Would that make things better or worse?
Any line-based metric should be suspect, but 'delta-SLOC' is probably the least bad. I would count added lines and removed lines separately, so a +50,-150 patch would be 200 ΔSLOC. This isn't a good measure of productivity, especially not in isolation, but it's a reasonable napkin-math metric of change . A developer with a high ΔSLOC count may or may not be more productive than a peer who has a week or two of no ΔSLO…
There is I believe a specific context where removal is good and others where that is not the right measure
I'm working on some java 8 cide that was written by folks still living in java 1.4 land, lots of opportunities there to reduce 20 lines into 3 (plus those devs kinda insisted on doing things in painful and unnecessary ways). In parallel, I'm working on a Greenfield project. Even on the Greenfield, there are times when negative code added is good. Not all programmer activities are equal
It's like measuring gas consumption during emergency braking, during acceleration, and during normal highway cruising. Sometimes it firs, or kinda fits, other times it's just the wrong metric. Programming is not a homogeneous activity
Re: -2000 Lines of Code (2007)
#130There is a deeper lesson here: Someone was thinking of lines of code as an asset, not a cost. It's a an error you also see in junior programmers writing reams and reams of code. The lesson is a harsh one for us code lovers, at least it was for me: Code is a means to an end, and an expensive one at that. The best code is the code never written. Our job is to solve problems, not to write code. You can use LOC as a crud…
Not even that, I'm not a civil engineer, but it looks pretty hard to add a ton of concrete without really helping a skyscraper, but I could add a few thousand lines of code without improving a system one bit, and even more lines to make the system slower, more complex, and still not add any functionality. LoC is about as good a measure of a system quality as weight is for an aircraft project.
> Not even that, I'm not a civil engineer, but it looks pretty hard to add a ton of concrete without really helping a skyscraper.
I am also not a civil engineer but I can think of a lot of ways to add concrete to a skyscraper in ways that are somewhere between nonhelpful and burdensome.