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

371–380 of 522 posts

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

#371

Post by torgian »

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…

I’d like to pick your brain on how you got this started. My current company seems to run into this problem occasionally, and we use Sketch for a lot of our UI designs.

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

#372

Post by Piskvorrr »

l0b0 wrote: post #329
snidane wrote: post #278

"My point today is that, if we wish to count lines of code, we should not regard them as “lines produced” but as “lines spent”: the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger." ~ Edsger Dijkstra

I'm sure Dijkstra could get away with saying that, but how would you phrase something equivalent to someone above you in the food chain without getting nuked from orbit in response? I can just see how the conversation would go: PHB: You've only added two lines - why did that take two days! Dev: Because it took that long to understand the requirements, understand the code, find the root cause, write a test to verify t…

PHB: Are you calling me a liar? Or just an idiot?

If situation is that far degraded, the answer is "IDK, does the distinction matter?" And it doesn't: either the PHB is putting words in your mouth on purpose, or couldn't hold 30 seconds of context.

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

#373

Post by Piskvorrr »

ornornor wrote: post #346
l0b0 wrote: post #329

Earlier quoted context omitted.

I'm sure Dijkstra could get away with saying that, but how would you phrase something equivalent to someone above you in the food chain without getting nuked from orbit in response? I can just see how the conversation would go: PHB: You've only added two lines - why did that take two days! Dev: Because it took that long to understand the requirements, understand the code, find the root cause, write a test to verify t…

> Don't let perfect be the enemy of the good! Exact quote from my manger, several times. They just don’t get it. And then a trivial feature takes a month to more or less implement because it’s all built on a toppling tower of crap.

"In our case, we're letting good enough be the enemy of barely tolerable."

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

#374

Post by LilBytes »

mcbits wrote: post #201
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".

This reminds me of the infamous Speed-Up Loop. https://thedailywtf.com/articles/The-Speedup-Loop

I'm surprised I haven't seen this before, this is great.

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

#375

Post by LilBytes »

kijin wrote: post #303
distrill wrote: post #252

Earlier quoted context omitted.

it's a good point but pretty cringe tbh

I prefer to just tell the client to go with the guy who says they can do it in a week. Often, the client returns to me in a few months' time, having wasted a lot of time and money on the other guy and equipped with a better understanding of why they require my services.

Had a similar experience selling my car.

It was an old Audi S3, like, 2011 model. Had a guy tell me the car was in better condition and the asking price was less than what I had listed. My car was listed at $10K AUD and that car was listed at $8K.

Them: "Why is your car listed at your price, and not matching this car?"

Me: "Well for starters, that cars in Adelaide, we're in Brisbane. If you want to go to Adelaide to check that car out and find out it's been in a bender and had most of it's body fixed and the listing avoids that. Be my guest."

Them: "I doubt that, I think you're asking too much. Will you match that price?"

Me: "No."

Them: "Why are you wasting my time, I should buy that one just to annoy you.'

Me: "You fucking do that then, laters"

I sold my car the week after this for the price I wanted. Straight up https://www.reddit.com/r/choosingbeggars material.

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

#376

Post by elnygren »

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

ie. if you are not doing https://en.wikipedia.org/wiki/Five_whys then you might be doing it wrong and wasting time because of it.

I'm referring to this:

> Some developers would have immediately gone back to the person reporting the problem and required more information before investigating. I try and do as much as I can with the information provided.

Which seems like being stubborn and making a mistake because of it.

Couple other parts also seem a bit overdoing it:

> Because I investigated if there were other ways of getting to the same problem, not just the reported reproduction steps. > Because I took the time to verify if there were other parts of the code that might be affected in similar ways.

These seem like taking a gamble. Maybe something comes up, but is it more probable that this work should be minimised until there is more proof of "other ways of getting to the same problem"? Developer time is expensive, is this really the best way of using it? Would it make sense to just fix the issue at hand and only put in more time if more bug reports come in after the fix or if there is some other indication that this part of the code might be more broken?

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

#377

Post by Piskvorrr »

musingsole wrote: post #321
l0b0 wrote: post #268

Earlier quoted context omitted.

So far I've worked in one place which didn't use version control in 2007, one place which had reluctantly started using version control just before I started in 2010, several places where automated tests were considered pure waste, where everybody had full access to production, where backups were untested, where one or two people held crucial knowledge which was not shared with anybody else, etc. The real world moves…

Devil's advocate: or best practices are rarely incentivized...because there's little to connect them with real, tangible value in an organization. Having fully linted, automatically tested code doesn't matter if the product isn't valuable and useful. And if the product is truly valuable and useful, it likely would be as well in the absence of these practices.

Fair point. I did take a week's tally of "how much developer time did we burn on hunting for backups and rogue edits", and suddenly SVN was orders of magnitude more attractive (ages ago).

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

#378

Post by benhurmarcel »

bmiller2 wrote: post #306
Izkata wrote: post #300

Earlier quoted context omitted.

Our non-technical stakeholders are almost guaranteed to have some minor design thing they jump on, so our equivalent was to show them only things that were functionally done, no matter how un-polished. That way they were the ones blocking any release.

Always include a duck https://softwareengineering.stackexchange.com/questions/1220...

Never heard that name, nice to know.

We sometimes have to do that in technical reports. The proofreaders always feel like they have to give at least one comment, so you give them a clear mistake to point out to avoid useless debate over minor points.

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

#379

Post by toong »

kgermino wrote: post #266
Jtsummers wrote: post #120

Earlier quoted context omitted.

Also, never use the word "done" in any context in a meeting like that. Do not even say: "I'm not done". They won't hear the "not". Say, "Development is still in progress" or something similar. I got chewed out for something being released (where it was found to be broken) to a customer because I said something like: "I'm about 80% done with testing, but I haven't run into any issues yet." They released it even though…

> Early in my career, I learned a simple 'demo day' rule: never demo things that aren't end-to-end done. I take a different but similar approach when I run into situations where I want to get something small in front of a business user before it’s completely ready: I make sure it’s visibly broken in a way that doesn’t detract from my goal for the meeting. For example: I have a registration form that I want to talk th…

While I agree, the feedback I get from a session like that is useless:

"While you mentioned this during the demo, I noted: 1. Your state-drop down has only 3 entries. 2. There is a validation error 3. You get an error at the end.

We need you to fix this ASAP !!!"

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

#380

Post by JDEW »

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!

> For some psychological reason, a thing that looks unfinished gets much higher quality feedback than something that looks polished.

Does this really imply “humans are broken”? We all have limited resources and I think this could just be a first order prioritization mechanism. Of course one has to be aware of the bias but that’s a different problem.

Post reply on HN