Live data from Hacker News

Lines of code got a better publicist

curlewis.co.nz

131–140 of 309 posts

Re: Lines of code got a better publicist

#131
post #76

It is endlessly... amusing (?) to me, that we as a community spent decades trying to make it clear that our productivity is not easily measured because what we're doing is complicated and long running, only for AI to come along and suddenly LoC, Nx multipliers, tickets / week etc are held up as useful if not objective measurements. The reasons we rejected LoC and other measurements have not changed (broadly: code out…

The non-technical people are in charge and they're not tethered to reality in the same way that engineers are. Objective reality will win in the end, but that doesn't prevent damage being done in the short term.

[dead]

Re: Lines of code got a better publicist

#132
post #16
post #14

Writing. Code. Is. No. Longer. The. Bottleneck. Deciding what to build. Reviewing Code. And testing code. Are the new bottleneck. So of course we don't see massive productivity gains. Because these parts of the SCLC were always bottlenecked but their capacity matched the throughout. We fired all the dedicated QAs years ago. Sr+ engineers that do all the code review are limited. Teams have not re-organized to match th…

Was writing code ever the bottleneck for anyone other than raw juniors and non-programmers?

There is some truth to this, but in practice I'm finding that yes, removing the writing code bottleneck has improved throughput quite a bit.

My day (excluding the huge amounts of communication overhead) used to progress as a serial operation of: 1. Write some code for one thing, 2. Self review of that thing, 3. Review other peoples' work, 4. Respond to review comments, 5. Get things merged, 6. Back to 1.

Now I have more of a tendency to queue up work on a few things at once, and then the serial steps are the self reviews and reviews of other peoples' work, and some of the review commentary back and forth (though I can automate some of this in parallel as well).

The upshot is that I'm more working in batches now than in serial, which I really do find to be more efficient.

It's not that it has removed all the bottlenecks at all, but no longer being required to focus all my attention for periods of time on physically typing code has removed one important bottleneck, and has changed, and I would say, improved, my workflow significantly.

Re: Lines of code got a better publicist

#133
post #36
post #16

Earlier quoted context omitted.

Was writing code ever the bottleneck for anyone other than raw juniors and non-programmers?

One thing the AI tools have taught me is that it hasn't been my personal bottleneck for at least a very long time. It's made that part faster for me, and that allows me to take bigger bites at the apple each iteration, but it's not meaningfully speeding me up in the way people claim.

I disagree that it's not meaningfully speeding me up. I'm definitely doing a lot more, and more quickly. But the benefit is definitely smaller at the team and organization level, because we still have all the same serialization points - review, validation, decision making - downstream of my work.

Re: Lines of code got a better publicist

#134

It’s worth looking at sectors where LLM code generation hasn’t been very visible, such as certification-accredited flight-control, braking, train-control, medical, or nuclear-control source code involving real-time embedded operating systems. This sector relies on assurance: deterministic scheduling requirements, detailed commit traceability, tool qualification, configuration management, independent verification, etc…

This study showed that people writing computer games had little interest in productivity tools (because they are producing something that is really used). But people who produce things that not really used are obsessed with productivity:

> the perennially unprofitable venture-backed startup, for which faux productivity is connected to the generally immaterial nature of its high valuations, versus the game studio that lives and dies by the profitability of its products.

> In a sector of the economy where "it's not about how much you earn, but about how much you're worth," the labors of the companies whose workflows are built on the kinds of productivity apps that today comprise nearly 40 percent of Product Hunt's output are not actually directed at the creation of a thing, but at the appearance of the creation of a thing.

Maybe this is why Silicon Valley seems to have become obsessed with productivity and AI whereas the people in the industries you mention don't seem as excited. It's because they are actually making real things so they don't have to 'look busy' in order to justify themselves.

https://components.news/the-gamer-and-the-nihilist/

https://news.ycombinator.com/item?id=47235774

Re: Lines of code got a better publicist

#135
It is pretty funny how this whole industry in a very short amount of time, with tons of experience and knowledge to lean on, reverted back to dubious measurements of productivity. If you track LoC and tokens used as productivity measurements, developers are going to max their LoC and token usage! Its so predictable that we have a Law named after this phenomenon! The fallout was so predictable I feel like I should have been positioning myself for all of the potential consulting work that's about to be needed.

Re: Lines of code got a better publicist

#136

Earlier quoted context omitted.

Chrome has 50 mil LoC https://openhub.net/p/chrome/analyses/latest/languages_summa...

Chrome is basically reinventing each OS API and libraries. One day they’ll have their own tcp stack and packet filter.

Chrome still has a way to go until Zawinski's Law is satisfied natively.

http://www.catb.org/jargon/html/Z/Zawinskis-Law.html

Re: Lines of code got a better publicist

#137

I think a better metric these days is what percentage of code is not reviewed / understood by humans. That is the real bottleneck. Until we can stop looking at the code, AI barely matters - you are just trading quality for quantity. Thats why it is so amazing for speed runs and prototypes. Here it is legitimately > 10X faster.

You need to retrain managers from seeing a prototype and thinking "yep, ship it" and over to "okay, how do we build this properly?" And I don't think that's gonna happen.

Re: Lines of code got a better publicist

#138

Earlier quoted context omitted.

Please read the full paragraph for the answer instead of cherry picking a quote for a knee-jerk reaction: > Be curious, try the new tools, test the latest models. To not do so is silly. > [...] > you could delay adopting “the cloud” for a couple of years and survive. With AI you might get a few months. The way we work has already changed, and it’s not changing back as far as I can tell.

I read the entire paragraph, and the entire article. Nothing in there explained to me why every engineer should be using AI every day.

If you read the paragraph, then why did you just ask "why?" instead of expressing your opinion about the explanation given in that paragraph?

Re: Lines of code got a better publicist

#139
post #86

Another AI slop article urging me to use AI on the orange AI fanboy site which has guidelines against AI slop comments, but AI slop submissions, that's just fine I reckon... Screenshot since the share button demands I have some social media login. https://imgur.com/a/UW15xVE

Genuinely funny how often I see both "HN is an AI hate site" and "HN is an AI fanboy site".

As dang said in one of these threads recently, opinions are just spilt on this!

Re: Lines of code got a better publicist

#140
post #6

I'm constantly thinking about that Microsoft guy who posted something like "we want 1 million LoC per engineer per month", which basically read as satire to most engineers I talked to, except apparently it was not satire at all, and indeed seemed to reflect the position of many CEOs etc when it comes to LLM code generation. I do think that over the past few months, it feels like the hype around producing unmaintainab…

I once worked in a company where there was an 80% code coverage requirement. Some enterprising contractor had a script that generated a single file with its own covering test suite the size of which could be tuned to achieve 80% over the whole codebase. Mostly the code was untested.
Post reply on HN