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

-2000 Lines of Code (2007)

folklore.org

Post reply on HN
Print view View original

131–140 of 222 posts

Re: -2000 Lines of Code (2007)

#131

Post by veidelis »

prettyStandard wrote: post #72
veidelis wrote: post #58

Earlier quoted context omitted.

Not much of an achievement, but I once deleted a 45k line Jest snapshot test for a React component that basically asserted that a div is rendered.

Maybe you are being sarcastic... Or you've completely missed the point of the article/story. The point is lines of code are almost meaningless. In this story the person saved 2k lines of code by rewriting a rendering engine, and use somehow think that's less than deleting a 45 k line jest snapshot.

Sorry, if it somehow sounded that my example is somehow more than what was mentioned in the article. Absolutely not. I think that my example also very well demonstrates that lines of code (even that isn't really "code") isn't not a good way of measuring productivity etc. My example could be considered as an example of how a code review didn't "do it's job" for what might have been a newbies mistake. But I also think that code reviewers cannot be blamed for every bad piece of code that gets through (context matters).

Re: -2000 Lines of Code (2007)

#132

Post by kibwen »

hyperman1 wrote: post #99

There 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 is what fills me with dread when it comes to LLM coding assistants.

LLMs solve the problem of "we don't have enough code, so let's generate low-quality code faster than ever", which, to a first approximation, is not actually the problem that anyone has; the problem we have is that we don't have the right code, and the code that we do have is already shit.

But at least managers will be happy that their reports are now checking in +100,000 LoC a day. What could possibly go wrong?

Re: -2000 Lines of Code (2007)

#133

Post by convolvatron »

samatman wrote: post #116
datavirtue wrote: post #107

Earlier quoted context omitted.

I'm on day two of an analysis, zero code written. I don't know what, if anything, needs written. If I had to pound out something to keep from being zero it would be fraud.

The Platonic ideal of the perfect manager is still going to want to know what's going on when a report isn't checking in commits. I vigorously agree that software quality requires that developers be free to take time to analyze, plan, or just think things through, but zero code days can also indicate a blocker or a performance issue, and a manager should be helping with those.

the platonic ideal of a perfect manager grows a culture where if people have issues with other developers, or the organization, or is just stuck, they naturally reach out to other people. I fail to understand this model where 'blockers' are some kind of hidden disease that a manger needs to actively ferret out. in fact, in healthy organizations I've worked in..the whole notion of a blocker doesn't really exist. its more like 'I talked to this person and we decided that they should merge an earlier version of their work, because otherwise I'm not going to be able to start for another 3 weeks and that totally blows our schedule'

and that ideal manager has a much better and multidimensional idea of performance over time than commit rate.

the platonic ideal of manager isn't some kind of school marm whose primary concern is figuring out when people are slacking off

Re: -2000 Lines of Code (2007)

#135

Post by eviks »

khazhoux wrote: post #66
eviks wrote: post #55

Earlier quoted context omitted.

confirmation bias indeed works that way more often than not: it confirms what you already believe

I'm confused which part of this is so off-putting. Joe is always the one in every standup saying the thing he's working isn't done yet because he's wrestling "one last tough bug." As a manager, you wonder if the technical problems are really that tough or if Joe is just struggling. Let's look at the commit history... yeah, something is off here, Joe has 1/10th the commits of his peers and they really don't seem more…

So troubling that you can't propose it cleanly: if you've already defined that "they really don't seem more complex in any way, but look rather trivial", why would you need to count? (another troubling sign is going for the order of magnitude assessments, and another minor point: you've mistakenly replaced volume of code with # of commits)

Re: -2000 Lines of Code (2007)

#136

Post by CapitalistCartr »

hyperman1 wrote: post #99

There 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…

"Our job is to solve problems, not to write code."

My job is what my employers pays me to do. If my employer agrees with that sentiment then it is. If I'm volunteering on open source, I can do my best, but if my employers rewards lines of code, then I produce LOC. Of course, picking a better employer factors in there somewhere.

Re: -2000 Lines of Code (2007)

#137

Post by zelphirkalt »

quelltext wrote: post #14
chii wrote: post #5

> they stopped asking Bill to fill out the form which is only possible because he's so important. imagine doing this as a stack-ranked IC in an org like AWS. The old days of a software as an artisanal craft is long over imho.

I'm by no means important in my org but when something appears like a shitty idea I will raise that (like other ICs around me) and more often than not it works out fine. I'll agree to give something a shot but if it doesn't work it doesn't work and my managers so far have all realized that a bit into the trial period. Reading comments like yours, I guess I should value my work environment more.

I think you are very fortunate then. The number of times I have raised concerns and my warnings have been ignored ... Even when I had direct past learning or experience with the thing they want to do, I can no longer change their mind.

Re: -2000 Lines of Code (2007)

#138

Post by samatman »

seadan83 wrote: post #129
samatman wrote: post #112

Earlier quoted context omitted.

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 time…

I think we agree with each other? Or mostly so.

ΔSLOC is just a metric, and what it measures is change to the codebase. Yes, some changes are very important, and others nearly trivial, so it's quantitive because a qualitative metric is a contradiction.

It certainly means different things in different contexts, if it's even meaningful at all. My claim is that +SLOC is entirely meaningless outside of the tautology that it measures what it is, where ΔSLOC is in fact informative about change to the software, albeit not perfectly so.

Re: -2000 Lines of Code (2007)

#139

Post by samatman »

convolvatron wrote: post #133
samatman wrote: post #116

Earlier quoted context omitted.

The Platonic ideal of the perfect manager is still going to want to know what's going on when a report isn't checking in commits. I vigorously agree that software quality requires that developers be free to take time to analyze, plan, or just think things through, but zero code days can also indicate a blocker or a performance issue, and a manager should be helping with those.

the platonic ideal of a perfect manager grows a culture where if people have issues with other developers, or the organization, or is just stuck, they naturally reach out to other people. I fail to understand this model where 'blockers' are some kind of hidden disease that a manger needs to actively ferret out. in fact, in healthy organizations I've worked in..the whole notion of a blocker doesn't really exist. its m…

> the platonic ideal of a perfect manager grows a culture where if people have issues with other developers, or the organization, or is just stuck, they naturally reach out to other people.

Agreed, and this includes managers reaching out to their reports.

> I fail to understand this model where 'blockers' are some kind of hidden disease that a manger needs to actively ferret out.

You're imputing an attitude to me which I neither hold nor intended to convey.

> in healthy organizations I've worked in..the whole notion of a blocker doesn't really exist.

Weird. The idea that a step in a process can't be completed before another step seems bedrock to me. It's always good to eliminate these dependencies when one can, but that isn't always possible.

> the platonic ideal of manager isn't some kind of school marm whose primary concern is figuring out when people are slacking off

Considering that should be obvious, since an ideal doesn't have negative qualities, I'm forced to conclude you're responding to a bunch of things I didn't say.

Re: -2000 Lines of Code (2007)

#140

Post by HarHarVeryFunny »

threatripper wrote: post #40
solumunus wrote: post #17

Earlier quoted context omitted.

How can it be a KPI if it doesn’t measure performance?

If you type faster you get more LOC. If you slack off all day you get zero. It does measure something, not necessary something useful but zero LOC indicates trouble.

> zero LOC indicates trouble.

It may indicate an employee with nothing to do, but in that situation would you prefer the employee did nothing, or started destroying the code base by adding KLOC of garbage to keep their manager happy and unsuspecting ?

Post reply on HN