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

141–150 of 222 posts

Re: -2000 Lines of Code (2007)

#141

Post by samatman »

ResearchCode wrote: post #125
samatman wrote: post #122

Earlier quoted context omitted.

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.

> Professionals outside of software don't do that.

How do you know this? Have you done an exhaustive search?

For one example, are you quite certain that no part of any military ever does this?

What about every factory?

Re: -2000 Lines of Code (2007)

#142

Post by rsynnott »

CapitalistCartr wrote: post #136
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.

Wait, does anyone _actually_ reward lines of code today, in this future year of 2024? Like, I remember people joking 20 years ago about how it was the sort of thing companies like IBM used to do in the 80s.

Re: -2000 Lines of Code (2007)

#143

Post by rsynnott »

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.

Yeah, honestly over nearly 20 years of working in this industry, I’m not sure that I’ve ever worked anywhere where there’d be significant management pushback on something like this. Now, granted, I’ve mostly worked in small companies, and one rather selective largish companies; maybe things really are much worse in the truly huge companies.

Re: -2000 Lines of Code (2007)

#144

Post by sircastor »

For all the people dismissing lines of code as a metric, I want to point out that very early on a line of code was literally a CPU instruction. While there was certainly something to be said for efficiency of your subroutine, lines of code was not a totally unreasonable measurement of things that your program was doing. Obviously we get removed from that the more we abstract and well constructed code is different from lines of code, but I can see where they were coming from.

Re: -2000 Lines of Code (2007)

#145

Post by rsynnott »

threatripper wrote: post #6
1letterunixname wrote: post #2

+KLoC is a terrible KPI that optimizes for complexity, waste, and artificial job security-seeking behaviors.

But they ARE a KPI that is easy to understand and measure.

KPI stands for “Key Performance Indicator”. Lines of code are clearly not this; they don’t indicate anything about performance one way or another.

(Now, mind you, I’m sure that lots of other ‘KPIs’ are nothing of the sort, either.)

Re: -2000 Lines of Code (2007)

#146

Post by [deleted] »

sircastor wrote: post #144

For all the people dismissing lines of code as a metric, I want to point out that very early on a line of code was literally a CPU instruction. While there was certainly something to be said for efficiency of your subroutine, lines of code was not a totally unreasonable measurement of things that your program was doing. Obviously we get removed from that the more we abstract and well constructed code is different fro…

[deleted]

Re: -2000 Lines of Code (2007)

#147

Post by [deleted] »

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…

[deleted]

Re: -2000 Lines of Code (2007)

#148

Post by rsynnott »

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 most valuable work I ever did, at least in monetary terms, involved zero lines of code (or certainly mergeable lines of code) for significant amounts of time while I figured out if the thing was possible, desirable, tested it, advocated for it… My manager was fine with this.

I’ve got to admit, I found this kind of _frustrating_ at the time, but if I’d insisted on writing something, anything, from the get-go, it would have been a complete disaster, and no-one would have thanked me for it.

Re: -2000 Lines of Code (2007)

#149

Post by gjkood »

Early in my career I once optimized an inherited 10,000+ line C program to less than 500 lines. It was a C program making SQL calls into a Sybase database.

No, not because I had some brilliant insight but for the simple assumption that my predecessor may not have been aware of how to write functions or use parameters to supply variable data to the SQL query. They had literally written the same SQL statement inline with a couple of changed values in each SQL call.

I just rewrote the code making the SQL call as a function call with bind variables as parameters into the function. All the replicated inline code was replaced with the function being called in a loop with the changed bind values supplied from an array.

Re: -2000 Lines of Code (2007)

#150

Post by rsynnott »

khazhoux wrote: post #43
xandrius wrote: post #32

Earlier quoted context omitted.

Exactly! I've myself spent days investigating an issue only happening on a specific Android device (but used by an important client) only to find that the solution was something along the lines of using "opacity: 0.1" instead of 0. That bug was left unfixed for months but now it's solved. Should I have received a talk because of that? (Of course the commit would have had at least 10 LOC more, explaining the reasons a…

> Should I have received a talk because of that? Of course not. But, if your commit history for last 6 months is just one or two of those one-line changes a month, that might hint that there’s a problem.

I mean, seems highly role-dependent. If, in practice, your role is to investigate and fix very difficult problems, that’s precisely the sort of commit history one might expect.
Post reply on HN