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

161–170 of 222 posts

Re: -2000 Lines of Code (2007)

#161

Post by hyperman1 »

norir wrote: post #123
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 sentiment goes too far in the opposite direction for me. Code that solves a problem is an asset. To carry your analogy forward, code is the concretization of the solution of the problem. The idea of the skyscraper is useless on its own and requires the concrete that materializes it. The skyscraper would become a lot less valuable if you removed the concrete... Of course, you also don't make the skyscraper better…

Costs are not a pure negative. Just like a skyscraper without concrete would be silly, so is an IT solution without code. I have no problem paying for extra code, just like I have no problem paying for an extra server. IF they are worth it. Software engineering is also the act of making a reasonable tradeoff.

Re: -2000 Lines of Code (2007)

#162

Post by kbolino »

edent wrote: post #51
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.

And now you understand why programmers need to be part of a Trade Union. Protection from retaliation and group negotiation on working conditions are brilliant for people who aren't as "important" as Bill.

Unions have their own politics. The good ones will do this. The bad ones will make your life a living hell for causing trouble. Whether it's worth it to unionize will be situational.

Re: -2000 Lines of Code (2007)

#163

Post by papichulo2023 »

gjkood wrote: post #149

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

Yooo, no params == no injection /s

Re: -2000 Lines of Code (2007)

#164

Post by khazhoux »

mavhc wrote: post #88
Ultimatt wrote: post #28

Earlier quoted context omitted.

The main issue is the majority of managers arent especially qualified to make a judgement of the code itself which makes the metric spurious at best. Lines changed is at least a better version than lines added. But it is fairly devoid of meaning removing ten lines can be extremely hard and impactful compared to adding 1000 lines of deeply nested ifs written poorly. Lines changed multiplied by number of files touched…

Any generic measurement of productivity is a sign that the manager is incompetent. If you're a manager and can't tell what your employees are doing, you're a terrible manager. Same reason they hate people working from home, they can't actually tell if someone's a good employee, they have no clue whether anyone is good at their job because they don't understand their job

My entire premise is:

1) A good manager needs to look at code to see what employees are actually doing. They can't just rely on the employees' verbal description.

2) One (correlated though not guaranteed) indicator that an engineer is struggling is when they are producing much less code than their peers or compared to any natural expectation of the role. Yes of course it's 100% that some bugs are super tricky and take a long time to find the magical one-liner fix. But statistically those are not common.

This is premised also on my belief that every engineer manager should be a very strong engineer themselves. This is common at most of the big tech companies.

Re: -2000 Lines of Code (2007)

#165

Post by jen20 »

khazhoux wrote: post #64
eviks wrote: post #54

Earlier quoted context omitted.

Might that hint that the problem that is there is that the metric is bad?

So if you managed a team, and when you look at commit histories you notice that one person has <1 commit a month and you look at the commits and they're trivial... you would disregard any concerns?

I would wonder how it got to the second month, certainly - getting to the point where this kind of post-hoc analysis can actually be done is a serious failing of management.

Re: -2000 Lines of Code (2007)

#166

Post by passion__desire »

araes wrote: post #126
HarHarVeryFunny wrote: post #119

If you measure productivity by LOC, then generally what you will get is lots of LOC. Cut and paste is easy if that's what makes you look good. Of course what companies should really be incentivizing is well written code that is easy to maintain and extend, not bloated cut-n-paste garbage.

And when somebody figures out how to metricize "well written" then that will turn to fecal matter. Re: Goodhart's Law [1] (admittedly meant to be economic, yet applies to most metrics). Also related to Enshittification (see fecal matter), the platform shifts, no longer prioritizes quality, and instead shifts to whatever "well written" is defined as. LLM's and especially online song choice algorithms have a heavy dose…

Where does Uncle Bob fit into this? Because he sure does love to give advice

How small a function should be? https://youtu.be/rXjf8eiGsSI

Re: -2000 Lines of Code (2007)

#167

Post by hyperman1 »

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.

Partially true. One of my less glorious days in IT was spent mopping water out of servers. We've all sbeen in situations where the best course of action was to shut up, sit down, type tons of dumb code, and deal with the fallout later.

But if this happens more than rarely, you either find a new job or stay and live with the fact that you've become a second rate programmer in a second rate company.

Re: -2000 Lines of Code (2007)

#168

Post by jen20 »

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 why wasn’t the response after day 1 of the “tough bug” something like “hey, why don’t you pair with X to get to the bottom of it?”?

Re: -2000 Lines of Code (2007)

#169

Post by jen20 »

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.

What, and I mean this in the nicest way possible, the everliving fuck are you talking about?

Professionals do this constantly. Go sit in an ER and watch the hand off between shifts. Go see any serious manufacturing facility and see them review daily everything that happened the previous day. Go see an effective sales org in action.

The scrumbags may have ruined software, but that certainly isn’t the world.

You make your not entirely unreasonable points sound like the output of a zealot.

Re: -2000 Lines of Code (2007)

#170

Post by syndicatedjelly »

coffeemug wrote: post #155
zac23or wrote: post #91

Counting lines of code as a production metric is very stupid. I remember solving an unsolvable 20 years old bug with a line of code, another 3 years old with a order by. How to measure the impact of a line of code? And in my experience, bad programmers write a lot more code... I will never forget the story[1] of a Microsoft developer rewriting a piece of IBM code that had 33 thousand characters, after rewrite ... 220…

I’m sure there are engineers who fix a critical bug every few months and generate millions of dollars of value, but as a general rule great engineers tend to be prolific and engineers who aren’t prolific tend to not be great.

Engineers who are obsessed with greatness tend to not be great either
Post reply on HN