Live data from Hacker News

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

mrlacey.com

421–430 of 522 posts

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

#421

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…

I have the opposite experience working on the front end team. I get delivered API’s that are done. Then when I start calling them I get errors. Turns out done for them means they made a basic REST interface, but the API just returns mock data.

Now my boss is happy that I’ve demoed API integration, but every next meeting he asks me why nothing has changed. It’s because I’m still waiting for something that is done.

For some reason the fact that it’s not done is always the fault of the front end team. I’d love to get an actually finished API for once...

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

#422
post #357
post #309

Earlier quoted context omitted.

Honestly, that feels like a huge waste of your own time to game a broken system. And I'm guessing it is, but that it's a defensive move because the darker timeline is miserable. Sucks it has to be this way so often.

What's broken are humans. For some psychological reason, a thing that looks unfinished gets much higher quality feedback than something that looks polished. There's no way around that flaw in people, so making prototypes look unfinished is something we have to do anyway!

[deleted]

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

#423

> You've only added two lines – why did that take two days? If this is hard for them to understand, the confused look when you reveal a change was a net removal of lines/statements must be amusing! > Because the issue was reported with a vague description of how to recreate it This is something my current management fully understands, but I wish we could get through to our clients. Short of being actively rude about…

Decent logging of all changes and error happening on the platform I work on usually lead me to pretty much the following dialog :

" - I have a problem, the platform is broken" " - Sure, do you have any rough idea when that happened " (I discovered that weirdly, people are very good to report a bug a day or even more after it actually happened) " - Around [some hours range]" (Get the logs for this time and this user) " - Ok, I see every information I need in the logs, it will be fixed soon"

And that's pretty much it. Oftentimes, I don't even need the time bit, just finding the user history in the logs is enough.

I'm always puzzled at engineers rambling about "users never learn how to do a correct bug report", but it seems like they themselves never actively learned that and integrated it in their everyday life.

Since users indeed never learn, stop expecting them to !

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

#425
post #403

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…

It reminds me of a pycon talk [0] which, while i dont agree with the whole thing, has the message "we ship features, not code". That also reminds me of "when a measure becomes a target, it ceases to be a good measure". LOC is a decent measure, but features are our targets [0] https://m.youtube.com/watch?v=o9pEzgHorH0&t=1235s

> LOC is a decent measure, but features are our targets

Only if your measure of success is tied to fewer LOC.

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

#426

An alternative take to this article would be that this person wasted two days because he was reluctant to ask more questions from the person who filed the bug report. How often do you actually receive quality bug reports at work? My experience is that external or internal users almost never provide sufficient information and you as a coder are always expected to drill down on what they reported with a barrage of ques…

Almost all the developers I work with never started working on a bug until i gave them the right steps to replicate it - even if the bug is reported by a user. A very stupid example i can think of is this: the developer designed a login form on web and mobile with the password field as expected, but forgot to uncapitalize the first letter of entry in password. Like if your password is abcdef, on mobile keyboard (unle…

After your suggested fix, how does a user enter the first letter of their password in upper case if that's what they want?

Maybe you were expecting the dev to go through all the passwords and fix them so the first letter of all passwords is lower case? Oh but if they were following best practices they don't know the password, they only know its salted hash.

Since the app was already shipping without the first letter being auto-lowercased that would suggest there were plenty of passwords with the first letter already upper cased, also something you can't test for easily if all you have is salted hashes.

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

#427

Earlier quoted context omitted.

After this (and a few emergent race bugs), I started burying the equivalent of setTimeout(() => getFakeData(), 1500) in my similar code. Best part is, I'm almost certain to beat 1500, so I've gotten compliments that it "feels snappier".

A lot of people are building big systems these days and in many cases we have a guess at what is a reasonable amount if time for all of the steps in the process to take if we want an answer in 600 ms. While your trick makes you look good, setting the times to match the budget might be more honest. And when the app slows down you can blame the people who take 250ms to do their part when we agreed to 100ms.

100ms?! That’s insane, if we set the bar at 1000ms then maybe 25% of our requests will qualify.

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

#428
post #248

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…

There was an old look & feel for Java UIs that made them look as if they were drawn on the back of a napkin, specifically as a reminder that the code was a work in progress: http://napkinlaf.sourceforge.net/

Thanks. If only this was available for C++ toolkits or C# WinForms, I'd use it in a heartbeat.

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

#429
post #403

Earlier quoted context omitted.

It reminds me of a pycon talk [0] which, while i dont agree with the whole thing, has the message "we ship features, not code". That also reminds me of "when a measure becomes a target, it ceases to be a good measure". LOC is a decent measure, but features are our targets [0] https://m.youtube.com/watch?v=o9pEzgHorH0&t=1235s

> LOC is a decent measure, but features are our targets Only if your measure of success is tied to fewer LOC.

that just sounds like it will have different unintended consequences like making every line as terse, complicated and unreadable as possible just to get it down to less LOC.

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

#430

At what point we, as an industry, failed to mandate a level of technical education for being a manager? Almost always the non technical people who can't think beyond quarterly profits and their resumes are the biggest problem of this industry.

What industry requires a relevant 'practitioner' education for being a manager?

Aircraft carrier commanding officer must be a pilot...
Post reply on HN