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

41–50 of 222 posts

Re: -2000 Lines of Code (2007)

#41

Post by khazhoux »

lakpan wrote: post #26
khazhoux wrote: post #24

Cartoonish anecdotes like this take away from that actual value that LOC can provide to management, when employed judiciously as one data point among many. It is very informative for managers to take a periodic look at the number/frequency of commits from each engineer and their size, and from there dive into each commit and explore the denseness of the code, the cyclomatic complexity, and the overall nature of the c…

Sorry but your argument makes no sense. The 10LOC/day guy is not to be singled out from the 1000LOC/day people because 1000 LOC could be just as trivial; 1LOC could have taken hours to discover.

Right. One data point among many. And managers should be looking at everyone’s code, not just the low LOC ones.

But there are people (I’ve seen this frequently) who constantly represent their work as having been “much more difficult than expected” but then you discover that they actually are struggling with what should be easy tasks, and looking at code (complexity and volume) is a data point. For me, more often than not, it serves as a confirmation of a problem I’ve started to suspect.

Re: -2000 Lines of Code (2007)

#42

Post by exitb »

octopusRex wrote: post #34

Microsoft and IBM Lines of code clash >In the PBS TV series based on Bob Cringely's Accidental Empires, there is a sequence where Steve Ballmer describes the experience of co-developing OS/2 with IBM, how the whole thing became a fantastic clash of corporate culture, with Microsoft having the small-company attitude of getting things done, and IBM being focused on internal measures primarily KLoCs, that is thousands o…

For a bit of context, the TV series this refers to is called „Triumph of the Nerds” and it’s a great watch, even today (maybe ever more so?).

Re: -2000 Lines of Code (2007)

#43

Post by khazhoux »

xandrius wrote: post #32
lakpan wrote: post #26

Earlier quoted context omitted.

Sorry but your argument makes no sense. The 10LOC/day guy is not to be singled out from the 1000LOC/day people because 1000 LOC could be just as trivial; 1LOC could have taken hours to discover.

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.

Re: -2000 Lines of Code (2007)

#44

Post by anonzzzies »

praptak wrote: post #16

The largest impact is sometimes asking simple questions (how are you going to handle X?) which leads to not building something. When this something hasn't ever had a chance to work, you saved the whole cost of trying to build it. This is not only impossible to measure as a numerical metric but also makes you enemies. Kudos to those who dare to do that anyway.

> The largest impact is sometimes asking simple questions (how are you going to handle X?) which leads to not building something.

Which is why I teach new people to have that loop in your head and not start pounding the keyboard at high velocity. The people who find programming to be akin to fast typing show very interesting equivalence with LLMs; fully write/remove/write/remove etc of not very well written code.

Re: -2000 Lines of Code (2007)

#45

Post by mdp2021 »

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.

That makes your point clear, but then what you are looking for is not a scalar value (that may be for instance be subject to a proportional judgement) but a fuzzy threshold.

Re: -2000 Lines of Code (2007)

#46

Post by richrichie »

bickeringyokel wrote: post #33
hinkley wrote: post #19

Earlier quoted context omitted.

It’s why they love claiming “culture fit” on anyone older than them. 28 year old managers feeling threatened by 30 year old employees.

Anecdotally, I have not found much correlation between age and management style. I have had bad managers of all ages! I have had one good manager though, and it's pretty obvious what made them great. First is they listen to what problems you have and actually help you do your best work. Secondly, they protect you from the other bad leaders at the company. Thirdly, they work too hard.

Work too hard?

Re: -2000 Lines of Code (2007)

#47

Post by pflenker »

khazhoux wrote: post #24

Cartoonish anecdotes like this take away from that actual value that LOC can provide to management, when employed judiciously as one data point among many. It is very informative for managers to take a periodic look at the number/frequency of commits from each engineer and their size, and from there dive into each commit and explore the denseness of the code, the cyclomatic complexity, and the overall nature of the c…

LOC as a datapoint provide no value that a manager couldn’t get quicker and with less ambiguity via other sources. For example, identifying engineers struggling for a month on a topic, as you described, can be uncovered way earlier by replacing a reporting-Like „standup“ with collaborative structures that help the team, and the manager, understand progress and potential blockers. LOC are lagging way behind on issues like these and are devoid of any meaning in isolation. I know your counter argument here is „one data point among many“, but mine is: if your other data points are solid, LOC do not add any value.

Re: -2000 Lines of Code (2007)

#48

Post by ZaoLahma »

khazhoux wrote: post #24

Cartoonish anecdotes like this take away from that actual value that LOC can provide to management, when employed judiciously as one data point among many. It is very informative for managers to take a periodic look at the number/frequency of commits from each engineer and their size, and from there dive into each commit and explore the denseness of the code, the cyclomatic complexity, and the overall nature of the c…

There was a bug in an embedded system I worked on that several engineers, software as well as hardware, spent months troubleshooting.

I eventually got called in and fixed it with a while loop and one function call inside of that loop. 4 lines in total, counting the brackets.

A very trivial change if you didn’t know why it was there, what impact it had on the system or how much it would have continued to cost in engineering hours if I hadn’t figured out what went wrong, why it went wrong and how to fix it.

I’ve spent a good chunk of my 15 years as a software developer as a pure “bug killer” and then you don’t really get to write that many lines of code, but the impact per line is big.

Re: -2000 Lines of Code (2007)

#49

Post by mehdix »

hinkley wrote: post #20

Gave myself RSI deleting On the plus side I replaced an O(n²) algorithm with a faster one in the very next commit. Needed to get rid of the ninety copies of the same bad idiom first.

I was giving myself RSI by deleting what was happening) and Can feel you right there.

Re: -2000 Lines of Code (2007)

#50

Post by supriyo-biswas »

lakpan wrote: post #26
khazhoux wrote: post #24

Cartoonish anecdotes like this take away from that actual value that LOC can provide to management, when employed judiciously as one data point among many. It is very informative for managers to take a periodic look at the number/frequency of commits from each engineer and their size, and from there dive into each commit and explore the denseness of the code, the cyclomatic complexity, and the overall nature of the c…

Sorry but your argument makes no sense. The 10LOC/day guy is not to be singled out from the 1000LOC/day people because 1000 LOC could be just as trivial; 1LOC could have taken hours to discover.

I wonder what the grandparent would think about a few LOC/month, there were a few rather gnarly performance issues in the codebase at my work for which the fix was usually a one or two liner, but that took an inordinate amount of research to even know where to start looking.

I guess I should be grateful for having a workplace that has sufficient understanding for the effort it takes to debug such issues.

Post reply on HN