Live data from Hacker News

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

mrlacey.com

91–100 of 522 posts

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

#91
post #57

Conclusions: 1. Picking a good manager is very important! 2. Communicating with your manager is very important!

1. Being in a position where you have the privilege of being able to pick a good manager is important :)

I remember hearing somewhere that the reason n.1 people leave their job was their manager. Don't know if that's true but the idea's there. So it makes sense that your manager should be a major decision criteria when you pick a job (being able to actually pick a job is also a privilege, but it's fairly common in SWE)

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

#93

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.

Maybe print out the data to show them the difference?

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

#95

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.

Lesson learned: make demo functions slower on purpose so the real one matches or exceeds it. It's not even deceptive: you're setting realistic expectations instead of giving a false impression.

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

#97

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 know this can be nuanced, as pointed out in other replies. But as a product manager, I admit to having used this as a form of triage. People have told me they don't have time to write a proper bug report. I tell them if it's not important enough for you to spend five minutes reporting, it's not important enough for a developer to spend five hours fixing.

I of course don't respond to everything as black and white as this, and I'm not expecting them to do the kind of troubleshooting that me or a developer could do much quicker.

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

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

Yes. The industry moves at a snail's pace, and is very different from what you'd read on HN. A huge % of dev jobs are still using old software/processes, with managers that haven't written software in 20 years, if at all.

In 2014 I worked at a company that switched to Git and then started measuring LoC to assess performance/involvement. Engineers took to committing/removing things like node_modules directories to make the data meaningless.

It still happens, even today, quite a bit.

Post reply on HN