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

171–180 of 222 posts

Re: -2000 Lines of Code (2007)

#171

Post by khazhoux »

wesselbindt wrote: post #84
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…

Here's some counterexamples to that idea: - a bugfix which takes ages to find and ends up being one or two lines of locally trivial code - a senior who spends most of their day unblocking junior devs and keeping the team on track: 0 lines of code - overzealous code formatters: lots of lines of code - a junior writing an overly complicated mess of a solution to a problem that could be solved much more simply: ungodly…

> a bugfix which takes ages to find and ends up being one or two lines of locally trivial code

I once had a junior engineer who took maybe 4-6 weeks to fix an intermittent bug in dynamic lib loading. When he finally fixed it, the fix was No, it's instead the engineer who gives the appearance that they're always doing tough work, but then the commit history shows that they're simply not. The person who says they're implementing a new data structure in the code, but really then take a month to replace a list with a dict in python, or whatever. This happens.

> a senior who spends most of their day unblocking junior devs and keeping the team on track: 0 lines of code

I'm not talking about them at all. I'm talking about people who aren't doing mentoring, advising, architecture, forward-looking design docs, etc.

> overzealous code formatters: lots of lines of code. A junior writing an overly complicated mess of a solution to a problem that could be solved much more simply: ungodly amounts of code

Yup, this happens. This is also something managers will learn by looking at code.

- a developer talking to the client directly and finding out that problem that they're trying to solve is already solved by the product in a way that the client didn't think of, rather than immediately wasting company resources on a feature that's ultimately unnecessary (0 lines of code over lots of lines of code)

Absolutely. The best way to get more work done is to figure out what work you don't have to do.

But if you have an engineer on your team make $200+K/year and they're not writing much code, nor writing design docs, nor advising other engineers, nor guiding the technical strategy, etc... if all the engineer does all day is "not wasting company resources" by doing very little whatsoever, you have a problem on your hands.

Re: -2000 Lines of Code (2007)

#172

Post by khazhoux »

datavirtue wrote: post #108
khazhoux wrote: post #60

Earlier quoted context omitted.

Agree fully. Yours isn't the case I'm talking about. I'm talking about the people that aren't hunting big bugs, aren't serving as advisors or architects, aren't deleting unused code, and aren't implementing a significant volume of features or functionality, but who instead trickle out a small amount of simple code month after month. I claim that when inspecting commit histories, a very low LOC or very low commit-freq…

All you have to do is read commit messages.

Reading commit messages is a poor substitute for reading code.

Re: -2000 Lines of Code (2007)

#173

Post by khazhoux »

peteradio wrote: post #109
khazhoux wrote: post #61

Earlier quoted context omitted.

No, probably not. And most don't try. My point is that --with proper context and thoughtful analysis-- it is data that can be useful.

At the end of the day nothing about the number of commits was used in your thoughtful analysis, it was only the contents of the commits which you attribute any value.

Yes and no. Certainly I know lots of great developers who prefer to commit work frequently and incrementally, others who do slower bigger changes. But I don't think I know any engineers who can create a substantial amount of software with only infrequently and tiny changes.

I encourage you to look at the code produced by whoever you think is the top engineer in your team or company (and I'm talking only about the engineers whose job is still primarily hands-on coding, versus advising/mentoring/architecting etc). Now look at the code by that one person who you know isn't pulling their weight and who you think isn't getting much done. I'll wager that your top engineer is pumping out a ton of strong code, and the other one is a trickle.

Re: -2000 Lines of Code (2007)

#175

Post by michaelcampbell »

datavirtue wrote: post #103
hsjsbeebue wrote: post #30

The moral: even if you are smart as Einstein you are still an employee and need to do employee things.

If Einstein was pressured by metrics we would have never heard of him.

I suspect he was... as a patent clerk. And that may be why we never heard of him THEN.

Re: -2000 Lines of Code (2007)

#176

Post by Moru »

khazhoux wrote: post #63
Moru wrote: post #57

Earlier quoted context omitted.

This is exactly why KLoC is not a good measurement. If you know about this, you will make sure you match everyone else by embellishing your line count with comments, copy and rename functions or extra deep nesting. The manager will still not know anything without looking at everyones code.

A good manager should look at everyone's code. A good manager should recognize that if a developer does nothing but annotate code with comments, and that's not what they're expected to be doing, there's a problem.

Ofcourse, but if the manager is using the KLoC to decide who to look at, that won't happen.

Re: -2000 Lines of Code (2007)

#177

Post by michaelcampbell »

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…

I can't believe no one as yet has trotted out the Dijkstra quote, so I will: https://www.azquotes.com/quote/754979

Re: -2000 Lines of Code (2007)

#178

Post by michaelcampbell »

gabrielhidasy wrote: post #104
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…

Not even that, I'm not a civil engineer, but it looks pretty hard to add a ton of concrete without really helping a skyscraper, but I could add a few thousand lines of code without improving a system one bit, and even more lines to make the system slower, more complex, and still not add any functionality. LoC is about as good a measure of a system quality as weight is for an aircraft project.

You might acknowledge this analogy is popularly ascribed originally to Bill Gates.

“Measuring programming progress by lines of code is like measuring aircraft building progress by weight.” ― Bill Gates

Re: -2000 Lines of Code (2007)

#179

Post by torginus »

I never understood why is it when people talk about LoC of code written, they always use 'lines added - lines removed'. If I do a run 10km run and end up in the same place I started, it's not a 0km run.

Re: -2000 Lines of Code (2007)

#180

Post by michaelcampbell »

rsynnott wrote: post #142
CapitalistCartr wrote: post #136

Earlier quoted context omitted.

"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.

Maybe I've been lucky, but I've been in big (10's of 1000's of employees) firms and small (10's of employees) firms, since the mid 1980's, and have never been measured on LsOC. But I play along with the joke, because it's an easy strawman.

That said, there are other equally bad metrics that are in current use.

Post reply on HN