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

471–480 of 522 posts

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

#471

Post by wazoox »

MBCook wrote: post #231
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…

We had a hard and fast rule at my last job. ALL demos were either 100% real, or were mock-ups from Balsamiq. If it looked like someone doodled it on paper we didn’t have to worry it would be taken as working. We came to this rule after far too many incidents where some sort of mock up (Photoshop, HTML, whatever) was shown and taken as done. Then we got the questions (possibly unhappily) about where it was and when it…

Ah yeah, I had a marketing/sales friend who did that the other way around: he made nice mock-ups, he even built powerpoint presentations that seemed to show the UIs actually working; he made credible ads and sales documentation with it, and he sold countless non-existing snake oil products this way ("available soon!").

As he simply was the marketing/sales guy, in case he found himself cornered he could always pretend that the failure was on the dev/technical side... "see with the support".

He could also successfully sell himself this way: once a billionaire proposed him to be the sales director of some company. He set the meeting at 7AM at the Ritz bar, and got the job (not for long : he had negotiated to keep the perks when leaving anyway).

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

#472

Post by akhilcacharya »

andrewflnr wrote: post #230
akhilcacharya wrote: post #110

Earlier quoted context omitted.

The defense I've seen is that it works reasonably well as a measure of productivity _if_ you're working in a similar team and in a stable codebase. From what I understand a lot of product teams at FB have nearly frictionless development tooling for their use cases so the pressure is to produce volume.

I call bullshit. Even if you have high-powered tools you still have to spend time thinking about how to use them, and you still continually improve them to reduce line count.

Perhaps, but it’s designed to be a consistent process. At least that’s the defense I’ve heard.

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

#473

Post by willcipriano »

lmm wrote: post #458
mikro2nd wrote: post #449

Earlier quoted context omitted.

Consider, then, that your experience might be limited in ways that you're unable to see due to that experience-bias.

Unlikely. I used to go looking for tasks that couldn't be broken down; I'd get excited when someone would claim that their task couldn't be broken down. But they always could, and it was never even hard.

My task is to implement a model that takes advantage of unified field theory to simulate arbitrary bodies in spacetime, first the mathematical models behind it need to be created then implemented in software.

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

#474

Post by bpyne »

So much good in this short piece. He sounds like someone I want on my team.

Users who work with IT often tend to give better descriptions and test cases. Quite often I need more information though. He's right that you try not to bother the reporting user. Sometimes there's no other way.

Reproducing a bug is often the most time-consuming part of a bug fix. It's doubly difficult when you have a shared test environment and the bug leads you into a shared data set. For instance, we have a scheduling table that's used by many applications. I can't change the data, even on test, because it can easily mess up other teams. So I have to make a copy of it to my schema, alter data, and point the code to the altered copy.

"If some code is throwing an error, you could just wrap it in a try..catch statement and suppress the error."

Yes, these developers exist. I worked with several over my career. They are frustrating because they leave damage for other people to fix, often at the worst time.

"Finding the exact cause of a problem, and looking at all the ways to get there can provide valuable insights."

Yes a thousand times. Bug fixes are opportunities to learn more about a system and, often, the user area for whom we wrote the software.

"I want a fix that isn't likely to cause confusion or other problems in the future."

A good fix takes into account the overarching software design and fits it if possible.

"I don't want a bug to be found in the future and for me to have to come back to this code when I've mentally moved on. Context switching is expensive and frustrating."

Writing software is building an abstract machine in your mind. These machines get complicated. Even when you're fixing a system written by someone else, you need time to "load" the machine into your mind.

The only time I don't like fixing bugs is when I'm against a deadline on writing/modifying another system. The context switching is a deadline killer. But, it happens. Nowadays I let the project manager know that I'm switching to a bug fix, give an estimate of how long I'll be away from his/her project, and my best guess on whether or not it'll cause a deadline slip.

Great post.

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

#475

Post by kmclean »

> I know that reporting errors can be hard, and I'm grateful for anyone who does. I want to show appreciation for error reports by trying to do as much as possible with the information provided before asking for more details.

This might be coming from a noble place but sounds a little like shooting yourself in the foot. Bugs that can be reliably reproduced are the easiest to fix, and I've found the quickest way to get to a set of reliable reproduction steps is just to ask exactly what the user was doing when the problem happened. They don't always remember, but often do. Sometimes they even remember the time, which can be really useful for digging through logs, which otherwise are too voluminous to be relevant.

Maybe it's a cultural difference. But maybe we could "show our appreciation" for the bug report by just saying so ("Thank you so much for taking the time to report this issue. Users like you play a big role in helping us improve our software"), instead of soldiering on in the dark for 2 days.

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

#477

Post by pkilgore »

buddhiajuke wrote: post #452
ioulian wrote: post #413

Earlier quoted context omitted.

And this reminds me about another story, I can't find the link but it was something like this: A game developer was making a game for PlayStation and they were over their memory limit. They were approaching a deadline but couldn't remove anything else from the game to fit it in memory (or disk, I can't remember). So a senior dev came by, changes the code in 1 minute and everything could fit into memory now. The thing…

There’s an episode of “Star Trek: the Next Generation” where Scotty, the engineer from the original Shatner Star Trek tells the next-century engineer LaForge that this is how it’s done. You never tell the captain all that you have so you keep something to squeeze at the fatal moment.

"The Scotty Principle" https://www.urbandictionary.com/define.php?term=Scotty%20Pri...

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

#478

Post by hhas01 »

kqr wrote: post #357
bfdm wrote: 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!

Perhaps because “unfinished” offers stakeholders the opportunity to make major contributions, whereas “finished” means it’s already too late to make changes now so anything they do say will just be ignored.

Yeah it’s all perception, but cultivating the right perception is vital to effective, productive communication.

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

#479

Post by ravenstine »

Cthulhu_ wrote: post #398
ravenstine wrote: post #323

Earlier quoted context omitted.

This reminds me of a story from my first job. The business I worked at was a typical office, like the one you saw in Office Space. Departments had their own TV screens on the wall that showed performance of individuals in a department; the sales department had a screen that showed who was making the most sales that day. After we'd pretty much finished working on the web apps that supported these TV screens, the CEO m…

Did you write something with fake data that trended upwards every week so all of you got raises and bonuses regularly?

I didn't have the chance to. ;) Getting another job doubled my salary anyway.

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

#480

Post by pkilgore »

hinkley wrote: post #335
pkilgore wrote: post #140

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.

This is a UI trick, I couldn't imagine doing this for backend services but then again, I've never been asked to demo those!
Post reply on HN