Live data from Hacker News

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

mrlacey.com

61–70 of 522 posts

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

#61
post #20

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

If your revenue can grow exponentially, that's probably the right priority.

Most companies aren't like that though. Know your company!

Also consider if you can run out of money before growth kicks in...

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

#63

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.

I have worked on both sides of this in the enterprise world (as a support agent in the middle of dev team, as a end user and as a developer on the receiving end) and it is never simple. A bug report takes time to make and many times it might take time to reproduce or narrow down to a simple test case. A developer should of course get the information needed to fix a issue, but very often (s)he can find the issue with very little detective work if they know the product. The problem I've seen is that you have a fundamentally broken system where: 1. The devs don't really know the product in the sense that they do not use it. They have very little experience how it actually is used or the workflows and might not have good overview of the code base. 2. The support agents, if they exist, have little clue of either development or the product and just as a filter to remove the absolute majority of known issues but at the same time mess up the communication between end-user and devs 3. The end user have neither time or experience to test or report issues so you get very bad reports that vary wildly.

When working as a support agent I have spent a lot of my time acting as a filter to stop making the end-users go mad with all the requests from the devs and preventing the devs from being flooded with crap reports (of course, some always slip through). That means a lot of time spent on reproducing and testing (and sometimes pointing out where the bug is in the code, even suggesting patches). But very few organisations pay for that knowledge and very few allow agents to muck around for a day with a tricky issue to make sure the devs can fix it without a major hassle.

It is very easy to ask for more information as a dev, and very often it is needed, but a lot of the time it is just pushing the cost to the end-user when a minimal amount of detective work (or even a single quick test) would do the same and save everyone a lot of hassle. I would argue that in a lot of time when we, as devs, ask for more information we do it to push the issue into the future and to save ourself a minuscule of work now, not to have a quicker resolution.

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

#64

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

Yes, very much like the time I replaced a getfakedata() method with a getrealdata() method and then management complained that it was much slower now.

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

#65
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.

One would wish. Personally, I don't think I've ever worked under a manager who understood software development. It tends to be all about what they can see (GUI) or about nearly meaningless metrics on a dashboard (LOC, tickets closed, etc.). Again, just in my personal, limited experience.

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

#66

If someone is measuring productivity in code, based on the amount of lines of code written, then they have never written code. Anyone with a tiny understanding of how programming works would totally get why something so small could take so long.

Seriously, Albert? You spent 7 years and "E = mc2" is all you produced? We need to talk.

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

#67
post #20

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

Yessir, Mr. Belson!

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

#68
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.

Rather than an integer number of lines of code, how about using a boolean : "it works" or "it does not work"? or "Does it meet the spec" or "it does not meet the spec"? Even a mediocre manager should able to test that one out.

Code is often improved by removing code.

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

#69
Oh this reminds me of what went from one of the most infuriating questions I would get asked by investors to one where I almost wanted to bait them into asking it...

"Why/how is this worth X dollars/time? I know someone who says they can do it in a week." To which, I eventually learned to reply: "Wow, well... In that case, let me shoot you an article on how to build a Twitter clone in 15 minutes. [awkward pause while I smile at them] There's a lot more than just literal lines of code that goes into building a successful software product."

Post reply on HN