What if a single line change, given it took 2 weeks, fixed 40% of your crash rates? That fix alone is worth millions, almost 100x - 1000x the engineer's hourly salary in down time.
You've only added two lines – why did that take two days?
21–30 of 522 posts
Re: You've only added two lines – why did that take two days?
#22Do 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.
Re: You've only added two lines – why did that take two days?
#23Do 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 was wincing a bit when I made my initial comment fearing I might actually be wrong. This hurts to read.
Re: You've only added two lines – why did that take two days?
#24Earlier quoted context omitted.
I know someone that worked at some skeezy company in Menlo Park that got passed up for a raise after spending months navigating the bureaucracy to save the company millions on their operating costs because they didn't write enough code. This was in the last four years. Edit: And they quit right afterwards.
It’s better to find ways to make more money than to save it. There’s a floor but no ceiling in much of what we do.
[deleted]
Re: You've only added two lines – why did that take two days?
#25The 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.
Unfortunately, working in a big enterprise world, I've seen both sides of this. After a while it becomes somewhat obvious if someone is legitimately asking for more info, or if they are just punting the ticket down the queue. (The former is when you can tell they are becoming focused whereas the latter seems to be more general, swirling questions.)
True, having seen this as well, the motivation driving the dev does eventually become pretty transparent.
Re: You've only added two lines – why did that take two days?
#26Earlier quoted context omitted.
I know someone that worked at some skeezy company in Menlo Park that got passed up for a raise after spending months navigating the bureaucracy to save the company millions on their operating costs because they didn't write enough code. This was in the last four years. Edit: And they quit right afterwards.
It’s better to find ways to make more money than to save it. There’s a floor but no ceiling in much of what we do.
The ceiling is the size of the addressable market.
Re: You've only added two lines – why did that take two days?
#27It's really sad that people (managers) still thinks of code this way. Luckily this has never happened to me, but if it did I think it would be a great sign to change jobs.
Re: You've only added two lines – why did that take two days?
#28The 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.
Unfortunately, working in a big enterprise world, I've seen both sides of this. After a while it becomes somewhat obvious if someone is legitimately asking for more info, or if they are just punting the ticket down the queue. (The former is when you can tell they are becoming focused whereas the latter seems to be more general, swirling questions.)
Agreed, although we (mostly) solved this a number of years ago. Our validation team has screen recording software running all the time. If they see an issue, they attach the video to the bug report. These videos dramatically improve everyone's ability to accurately report bugs and quickly resolve them.
Re: You've only added two lines – why did that take two days?
#29Earlier quoted context omitted.
I know someone that worked at some skeezy company in Menlo Park that got passed up for a raise after spending months navigating the bureaucracy to save the company millions on their operating costs because they didn't write enough code. This was in the last four years. Edit: And they quit right afterwards.
It’s better to find ways to make more money than to save it. There’s a floor but no ceiling in much of what we do.
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.
Re: You've only added two lines – why did that take two days?
#30Do 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.
Were they right about the person being a low performer?
I'm curious if this is "everybody knows this person isn't doing any work, here's a blindingly obvious metric to use to defend this move to HR" because HR orgs often hate things that don't have metrics attached, or if it's "I don't understand what this person is doing, and I don't see any commits, so it must be nothing"?