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

You've only added two lines – why did that take two days?

mrlacey.com

Post reply on HN
Print view View original

71–80 of 522 posts

Re: You've only added two lines – why did that take two days?

#71

Post by touristtam »

WalterBright wrote: post #32
kevsim wrote: post #5

Do people actually have fights like this with management at their companies? Not trying to knock the author, but I'm just surprised anyone would actually hear this kind of comment in 2020. I'd think by now any and all metrics tying lines of code to productivity would be long dead.

Many people assume their manager knows what the employee is doing. They often aren't, meaning they go by what they can see, which is lines of code. The smart thing to do is to regularly keep your manager updated on what you're doing, especially if they don't come by regularly and ask you. Especially if you are WFH.

Task completion should be the metric, not line counts, otherwise the incentive is creating the most bloated piece of software and the most comprehensive unit-test possible. Any system is going to be (ab)used by the employee to their benefit.

Re: You've only added two lines – why did that take two days?

#72

Post by methodin »

WalterBright wrote: post #32
kevsim wrote: post #5

Do people actually have fights like this with management at their companies? Not trying to knock the author, but I'm just surprised anyone would actually hear this kind of comment in 2020. I'd think by now any and all metrics tying lines of code to productivity would be long dead.

Many people assume their manager knows what the employee is doing. They often aren't, meaning they go by what they can see, which is lines of code. The smart thing to do is to regularly keep your manager updated on what you're doing, especially if they don't come by regularly and ask you. Especially if you are WFH.

Indeed and it's why organizations that execute well treat this process as a collaboration rather than a dictation and report-back.

Re: You've only added two lines – why did that take two days?

#73

Post by Piskvorrr »

andi999 wrote: post #33
Piskvorrr wrote: post #6

Reminds me of that time a PHB decided to measure efficiency by kLOC. All the pull requests in the following week had a net negative line count.

They PHB should put extra bonuses on kLOC, like 1k$ per 1kLOC, and watch the codebase increase exponentially and since documentation is better than code, double the amount for line of comments.

That's a literal Dilbert strip, 1998-ish, IIRC.

Re: You've only added two lines – why did that take two days?

#74

Post by touristtam »

archi42 wrote: post #19
kevsim wrote: post #5

Do people actually have fights like this with management at their companies? Not trying to knock the author, but I'm just surprised anyone would actually hear this kind of comment in 2020. I'd think by now any and all metrics tying lines of code to productivity would be long dead.

I regularly hear a friend complain about BS like this and variants. "Why did adding a button take a week, it's just a button?!" is also very popular. Not sure what's worse, that or the recurring "that element should be 1px to the left, drop everything you're working on and fix it asap"...

Try changing the colour and getting told it isn't the same shade of red as the drawings presented by the designer on his PDF presentation.

Re: You've only added two lines – why did that take two days?

#75

Post by jedimastert »

newshorts wrote: post #9

The assumption that asking for more information to recreate the bug is a lazy tactic to get out of the bug fix is also a terrible assumption and discredited the opinion IMO. Often times asking for more information can speed things up and lead to a quicker resolution.

Also, asking for more information lets you work on something else with more actionable feedback while they do so

Re: You've only added two lines – why did that take two days?

#76

Post by neatze »

Jtsummers wrote: post #13
Piskvorrr wrote: post #8

Earlier quoted context omitted.

Because I have spent time thinking, not merely typing. (The error "programmers are just overpaid typists" is widespread)

My first boss and my boss two positions ago both thought that way. It was incredibly frustrating. Along with: If only you programmers would stop putting in bugs we'd ship perfect software every time. (When most of the "bugs" were specification errors and not program logic errors.)

Where does program specification ends and where does program logic starts ?

Re: You've only added two lines – why did that take two days?

#77

Post by arendtio »

aequitas wrote: post #56
arendtio wrote: post #47

Actually this is one of the upsides of web development: Since every line contributes to the file size of your software and therefore to the loading time there is a motivation for keeping the code base small. Sadly, there are many projects out there which obviously failed to reach this target at some point.

This can also go suprisingly wrong when management decides code size is the performance metric needed to improve the site and hires a "performance engineer" who abolishes all structure and abstraction in the code, making it near-impossible to debug and maintain. But at least it runs fast.

True, the quest to reach a small file size can also lead to various down-sides. Cryptic architectures and weird code are just two popular symptoms.

Re: You've only added two lines – why did that take two days?

#78

Post by mateo411 »

seneca wrote: post #22
kevsim wrote: post #5

Do people actually have fights like this with management at their companies? Not trying to knock the author, but I'm just surprised anyone would actually hear this kind of comment in 2020. I'd think by now any and all metrics tying lines of code to productivity would be long dead.

You would hope so, but I've seen an Engineering Director at an otherwise well run software company use number of Github commits as the central reason to put someone on a performance improvement plan as recently as 2019. Granted, this was someone who was a professional manager and hadn't been an engineer for the last 90% of their career, and many people were shocked by it, but it happened.

I think it's fair to use this as supporting evidence. If they are assigned tasks that aren't too difficult and they aren't completing them really fast, and there is a PR process in which changes are landed into the repo, then I think it's fair to use the number of commits to the repo.

If anybody can push commits to the repo, then it's a useful metric. Finally, this sort of action should be take after the manager has worked with their report, by having somebody else help them, or put them on a different project.

Re: You've only added two lines – why did that take two days?

#79

Post by jedberg »

melling wrote: post #35
jedberg wrote: post #29

Earlier quoted context omitted.

I wouldn't say it is better, just different. Both have value. If you find a way to save millions, that might be quite worthwhile, because that might be easier than building something new that makes millions of dollars. It's all about ROI.

People shouldn’t downvote him. He’s right. i’ve done lots of small things to save time and money in the past. Management really doesn’t value it as much as making money or working on more visible projects. Telling someone that it only took me an hour to eliminate an hour of someone’s work every week doesn’t go far.

That's just bad management, not an axiom.

Re: You've only added two lines – why did that take two days?

#80

Post by labcomputer »

newshorts wrote: post #9

The assumption that asking for more information to recreate the bug is a lazy tactic to get out of the bug fix is also a terrible assumption and discredited the opinion IMO. Often times asking for more information can speed things up and lead to a quicker resolution.

Sure, it depends on the context. But I've seen many examples where the reportee is asking for information that's already in the bug report, or can be easily inferred from the report.
Post reply on HN