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

81–90 of 522 posts

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

#81

Post by cgrealy »

arendtio wrote: post #40
glouwbug wrote: post #21

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.

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.

To that manager: that bug wasn’t the creation of a single developer. It went through code review. It had unit tests. A QA verified its initial implementation and a Product Owner signed off on the feature as done.

If it wasn’t caught before prod, it’s either such an edge case as to be almost impossible to catch OR (more likely) it’s representative of a systemic failure within the organisation.

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

#82

Post by dgb23 »

trav4225 wrote: post #65
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.

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.

The problem is not "manager/client doesn't understand software development". That's fine.

The problem is lack of trust in you as the expert and possibly a lack of self-awareness (they think they understand).

A manager/client should make mostly strategical decisions like: We should solve this problem, here are the resources. And almost never tactical.

They also shouldn't even care or look at LoC. They shouldn't be worried about metrics of 'effort' at all.

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

#83

Post by samatman »

seneca wrote: post #52
majormajor wrote: post #30

Earlier quoted context omitted.

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"?

Completely valid question, and I think you make a great point here. A lot of baffling managerial behavior is because the manager is working in a baffling bureaucracy. Unfortunately, I think this situation was largely of the latter case, and maybe some motivations I'm not aware of. They were a senior engineer that spent a lot of time coaching the rest of the team, and less time on their own personal work. The commits…

Which leads me to want to fill the rest of the story in: the manager of the senior engineer had a friend he wanted to promote, and this was the expedient way of getting the obstacle out of the way.

That could be completely wrong, of course. But would it surprise you?

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

#84

Post by addicted44 »

If the reporter hasn't provided enough information to recreate the issue (it's obviously not a major deal breaking issue otherwise it would be obvious and easy to recreate) and they are internal to the company, tell them to provide more information before moving forward.

The author's approach is good for external bug reports, but they don't clarify that's indeed the case here.

I have to strongly appreciate the author for finding the root cause and tackling that instead of the symptom.

So often, especially in front end coding, you will see an exception being thrown because of a null value being passed in, and the "fix" checked in by the developer basically returns the default value if null is passed in, when they should be investigating and fixing why a null was passed into the function in the first place.

If your function has a contract that forbids nulls from You resolve the immediate bug, but this almost certainly leads to multiple bugs being created in the future (or worse, something that is quietly wrong, because 1 row in a 100 row table is missing and no one noticed) until the root issue is resolved.

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

#85

Post by addicted44 »

norenh wrote: post #63
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.

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…

Assuming the reporter is internal, you don't need them to go ahead and type out everything. A quick call with a screen share is all that's needed.

Not even reaching out (again, assuming they are internal...if they are external then there are many other considerations) is just not smart IMO.

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

#86

Post by trav4225 »

dgb23 wrote: post #82
trav4225 wrote: post #65

Earlier quoted context omitted.

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.

The problem is not "manager/client doesn't understand software development". That's fine. The problem is lack of trust in you as the expert and possibly a lack of self-awareness (they think they understand). A manager/client should make mostly strategical decisions like: We should solve this problem, here are the resources. And almost never tactical. They also shouldn't even care or look at LoC. They shouldn't be wor…

Ah, agreed. I guess that, in my experience, not understanding SW development tends to go hand-in-hand with not trusting the developer.

I found your phrase "lack of trust in you as the expert" a little jarring because (again, in my personal experience) considering the developer to be a domain expert is somewhat of a foreign concept. I suspect/hope the situation is better elsewhere in the industry. :-)

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

#87

Post by dgb23 »

jedimastert wrote: post #75
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

I agree with this. If you are generally swamped with work, you need to do triage and possibly delegate work.

This isn't perfect behavior. But in some situations the perfect solution isn't feasible.

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

#88

Post by stormdennis »

rriepe wrote: post #43
0xEFF wrote: post #20

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

Thanks. This comment blew my mind. This perspective is so far on the other side of things that I never considered it.

It feels like saving money might also be more environmentally friendly than growth.

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

#89

Post by ftio »

caymanjim wrote: post #31

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…

Early in my career, I learned a simple 'demo day' rule: never demo things that aren't end-to-end done.

When you do, it can easily confuse folks who aren't deeply involved in your project ("haven't I seen this already?") and can hurt team morale because they never get a "shipped it" moment that feels good.

More to the point: enforcing this rule incentivizes teams to build things in small, shippable components. Nobody wants to be left out of demo day multiple weeks in a row.

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

#90

Post by WalterBright »

methodin wrote: post #72
WalterBright wrote: post #32

Earlier quoted context omitted.

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.

Organizations are always imperfect, which is why I strongly recommend taking the lead and being pro-active in keeping management informed of what you're accomplishing.

Out of sight, out of mine I don't believe it is any coincidence that the highest compensated engineers I know also are highly visible through their own efforts.

Post reply on HN