Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lines of code got a better publicist

curlewis.co.nz

Post reply on HN
Print view View original

181–190 of 309 posts

Re: Lines of code got a better publicist

#181

Post by prodigycorp »

JackFr wrote: post #179
prodigycorp wrote: post #166

Earlier quoted context omitted.

Feels doubly so for Anthropic. There's just unbelievable level of glaze, and insane upvote velocity for "blog posts" that are essentially fluffed up feature documentation. Somehow everything boris says has become the word of God. The dude is just an engineer, like you and me, who gets unlimited tokens for free.

Upvoter here. Nothing special -- I like Claude a lot. I found it more ergonomic to work with, and I think its models are state of the art. I believe I'm more productive especially in legacy crufty codebases. I may not be representative of the universe or have a controlled, randomized study to back it up, but that's not what upvotes are for are they?

That's a fair point. To play devils advocate to myself, it's possible that the huge upvote share is due to a much bigger marketshare among our community.

Re: Lines of code got a better publicist

#182

Post by tyre »

QuercusMax wrote: post #168
tyre wrote: post #153

Earlier quoted context omitted.

I had an MoM at Stripe who pushed back on perf designations based on number of PRs. I wish I were joking. (The had never been an engineer.)

Trying to parse your sentence, which is ambiguous... You're saying that the manager-of-managers would argue that the number of PRs should affect perf ratings? Or the MoM would push back against the line managers who were giving ratings based on # of PRs?

They were reviewing perf designations, then pulling up PR count, then arguing against designation based on the number of PRs opened.

Re: Lines of code got a better publicist

#183

Post by sfink »

I largely think that we engineers are to blame for LoC being still perceived as an asset rather than a liability. We are proud of stuff we create, but it turns out that you can't describe how "big" something is without some metric, and so we fall back on the metric that is easiest to compute.

Suggestion: we should all shift our terminology, and in particular make heavy use of phrase "...and it cost N lines of code". And say what we spent those LoC on.

"I implemented new feature X, and it only cost 200 lines!"

"That bug was brutal to figure out, but in the end it only cost 6 lines of code."

"It was doing something in case X that it didn't do in case Y, and it turns out that the distinction wasn't even needed. So I fixed the problem and saved 20 lines of code at the same time!"

Lines of code are a price you pay. We don't go around bragging about how we spent $200 without any mention of what we purchased with that money. Why do we do that with LoC? "I had to pay an extra $200 because I signed up late" and "I only paid $200 for my hand-painted artisanal pottery lamp hanger. Factory-made ones cost upward of $1200 on Amazon!" are two very different statements, and map to exactly the same distinction in code.

Re: Lines of code got a better publicist

#184

Post by esperent »

zaphar wrote: post #177
jeffbee wrote: post #167

Earlier quoted context omitted.

That's certainly a way to look at it. And that repo contains a "third party" directory which itself contains Linux, LLVM, and much of the rest of the open source world. But I would suggest that the largest of those thousands of applications probably has a transitive closure of hundreds of millions of lines of code.

I'm aware. I worked on that specific project (assuming we are talking about the same one) back in the day. :-) There are certainly very large applications in that repo in the hundreds of millions of lines of code. But comparing the entire repo to single applications is not an apt comparison.

Ok, then we can still compare one of those very large applications that have hundreds of millions of lines.

Re: Lines of code got a better publicist

#185

Post by sanderjd »

jghn wrote: post #147
sanderjd wrote: post #133

Earlier quoted context omitted.

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.

I realized after I posted that it didn't quite capture what I meant. For instance if I'm able to do a more complex piece of work all at once in about the same amount of time as it'd previously take me to do a simpler piece of work, than that is a speedup. And that's what I am able to realize. But what's not as much the case is that if I did an A/B test on the same task that I'd be massively sped up because so much of…

Yep totally agreed.

Re: Lines of code got a better publicist

#186

Post by sanderjd »

dijksterhuis wrote: post #175
sanderjd wrote: post #113

Earlier quoted context omitted.

I think engineers tend to over index on this kind of thing being "waste". You didn't waste that investment, you paid for the option to ship that feature or MVP and the research into the question of whether it made sense to ship it.

put simpler, you learned what not to build.

It's definitely that, which is very valuable, but it's also the optionality value additionally. You had the option to launch the thing, which you wouldn't have had if you had never worked on it at all. It's notoriously difficult to properly value optionality, but it definitely has value, and often a lot of value.

Re: Lines of code got a better publicist

#187

Post by MarkusQ »

tyre wrote: post #182
QuercusMax wrote: post #168

Earlier quoted context omitted.

Trying to parse your sentence, which is ambiguous... You're saying that the manager-of-managers would argue that the number of PRs should affect perf ratings? Or the MoM would push back against the line managers who were giving ratings based on # of PRs?

They were reviewing perf designations, then pulling up PR count, then arguing against designation based on the number of PRs opened.

That still doesn't clarify: were they saying "many PRs→good" or "many PRs→bad" or "number of PRs is irrelevant" or...?

Re: Lines of code got a better publicist

#188

Post by grahamgooch »

Large enterprises class systems are notoriously difficult to work Ai. It’s the context window limitation. Assuming 10 tokens per LoC. The best models today cannot wrangle 100k distributed LOC across multiple repos. It’s great for building new and maintaining smallish codebases. All this code being written is fantastic, but maintaining them efficiently over the code lifecycle is tricky.

Re: Lines of code got a better publicist

#189

Post by Sesse__ »

tyre wrote: post #153
sunaurus wrote: 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 had an MoM at Stripe who pushed back on perf designations based on number of PRs. I wish I were joking. (The had never been an engineer.)

It's a signal. It's not a strong signal, and you certainly should not base your entire perf on it, but if the number is unusually high or low, it's a signal that could warrant further investigation.

(I once worked with an engineer that had two PRs, both fairly small bug fixes, in a given calendar year, and when I looked more carefully, they did not have any other obvious output or impact.)

Re: Lines of code got a better publicist

#190

Post by joe_the_user »

SCdF wrote: 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…

Maybe a particular group of software engineer cultivated the need for careful measures. But the programming field never escaped the idea of simple metrics.

That's because you would always have loosely involved but aggressive and demanding bosses (there is unfortunately an economic value to the boss whose primary task is forcing more effort out of the employee and who doesn't help coordination or anything else). So at best you had two intersecting clouds of approaches with actual accomplishment intersecting with LoC and related measurements.

The thing AI is that it provides all the tools to satisfy that loosely involved but demanding boss. So suddenly you are going to have a larger demographic of people who like LoC and feature-additions as metrics 'cause now they are easy.

Post reply on HN