A variant of this that has driven me to quit more than one job is having a non-technical manager look at a UI prototype and consider that 90% of the solution. "The UI guys had this page ready two months ago! Why doesn't this work yet?" It's even worse when you present a working prototype. They simply don't understand that the backend functionality is what's doing the bulk of the work, and just because you can see something, that doesn't mean it's secure, performant, scalable, or even functional beyond demoing with dummy data.
You've only added two lines – why did that take two days?
31–40 of 522 posts
Re: You've only added two lines – why did that take two days?
#32Do 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.
Re: You've only added two lines – why did that take two days?
#33Reminds 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.
Re: You've only added two lines – why did that take two days?
#34Earlier 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.
Making a million or saving a million are equally important in the end assuming one of them doesn't require particularly unreasonable ways. Sometimes it happens that the floor is really close to the ceiling and lowering the floor is the easier thing to do. Go for the low hanging fruit first. If you have too much useless clutter it makes sense to remove it rather than break down walls to expand.
Re: You've only added two lines – why did that take two days?
#35Earlier quoted context omitted.
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.
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.
Re: You've only added two lines – why did that take two days?
#36Do 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.
That’s true. And I guess depending on the job/manager you could replace lines of code with “user-visible changes to app”, etc.
Re: You've only added two lines – why did that take two days?
#37Earlier 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.
Certainly many companies prefer this approach because so many goals are tied to increasing revenue, and certainly personal bonuses are too. Very few people get rewarded for decreasing costs. In my last (big!) company it was never even talked about. Increase revenue was the only goal.
Also making more money is better, because it means growing the company with more employees and more job safety for everyone.
Re: You've only added two lines – why did that take two days?
#38The 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.
I suspect most developers have been on both sides of it. I've most often seen it as a delaying tactic where access/system bureaucracy prevents easy recreation. So generally dysfunctional enterprises.
Re: You've only added two lines – why did that take two days?
#39The 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.)
I too have seen the case when a developer will ask for more information in order to game the process. While this is arguably (and I would agree) a failure of the process since it incentivizes undesirable behavior, you can quickly wind up in a situation where there is a large cadre of developers who will reflexively ask for detail. In this situation you often have good "measured" performance across the engineering org, but there tends to also be a large swath of tickets which find themselves in limbo. Some of these tickets can take months to resolve when a day or two of concentrated effort could have resolved it.
Re: You've only added two lines – why did that take two days?
#40What 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.
A manager would certainly argue the other way around: The person who created the bug costs the company a lot of money. Fixing that single line was just necessary because someone didn't do his work in the first place. So fixing that line is something you should do off-the-clock.
This is just one of the reasons why I appreciate it when managers have at least some coding experience.