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

401–410 of 522 posts

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

#401

Post by eru »

Cthulhu_ wrote: post #392
toong wrote: post #379

Earlier quoted context omitted.

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

Yup, that'll happen, and if you omit it entirely you can get comments going "I'm not seeing this field!". Would it be better to show no progress at all until it's completely done? I know agile methodologies tell you to demo regularly, but I'm more and more under the impression that they are to provide progress feedback / reports to management.

I remember someone suggesting using deliberately crude and hand-drawn looking UI elements in the demo. That communicates to non-technical users that it's just a prototype.

Something like https://wiredjs.com/ might work, if you are building a web-ui.

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

#402

Post by Cthulhu_ »

otikik wrote: post #166

Those two lines took two minutes to write. Knowing which lines to add, and where, took 25 years of experience. That's what you are paying.

There's an anecdotal quote from Picasso to that effect: tl;dr he doodled on a coaster and asked 60K for it. Not because it took him 5 minutes, but because it took him 50 years.

Personal anecdote, the 'old' UI I'm working on had an issue where a dialog window's action buttons would be outside the visible area and people had to scroll all the way down. One guy they hired part-time spent several days trying to figure it out. I came in and added a few lines of CSS and it was fixed. The bug had been open for three years. The CSS in question:

    .dijitDialogPaneActionBar {
      position: sticky;
      bottom: 0px;
    }

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

#403

Post by el_oni »

rubyn00bie wrote: post #69

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

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

#404

Post by thinkingemote »

Cthulhu_ wrote: post #402
otikik wrote: post #166

Those two lines took two minutes to write. Knowing which lines to add, and where, took 25 years of experience. That's what you are paying.

There's an anecdotal quote from Picasso to that effect: tl;dr he doodled on a coaster and asked 60K for it. Not because it took him 5 minutes, but because it took him 50 years. Personal anecdote, the 'old' UI I'm working on had an issue where a dialog window's action buttons would be outside the visible area and people had to scroll all the way down. One guy they hired part-time spent several days trying to figure it…

Another Picasso anecdote: someone saw his doodles and said "pfft, I could do that!" He replied "So why haven't you?"

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

#405

Post by bananaface »

Cthulhu_ wrote: post #400
bananaface wrote: post #393

I sympathize with this, but taking two days to add two lines of code is unproductive. Sorry, that's just not a lot of output. Two-day bugs happen, but they should be rare. The real question is: is this rare, or is it typical for this developer? IMO the real problem is trying to evaluate an employee's productivity on the scale of two days. There isn't enough context to understand the situation.

You CANNOT make any statements about whether or not a code change is productive / unproductive if you do not know the context. It doesn't work like that. Take any random commit on https://github.com/torvalds/linux/commits/master ; most change just a handful of lines but I can guarantee that each of them represents a significant time investment in analyzing, documenting, discussing and testing the code change in quest…

I don't think we disagree. One line per day can be a reasonable rate of change. But usually it isn't. Usually that's too slow, and it's indicative of an unproductive developer.

Everyone in the thread is defending the OP because the issue is relatable. "He's productive, his manager doesn't understand!" Ok, maybe. But also maybe his productivity is way below what he's being paid for. We don't know, we don't have enough context to judge.

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

#406

Post by dt3ft »

LandR wrote: post #251
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…

I was on a call and the client said they wanted something added to a UI. So I very quickly used MS Paint to mock it up... Just so I could clarify that is what they wanted.I shared my screen and someone said "great, you've done it!". Even though I was clearly showing a screen that showed me editing a screenshot of the UI, in MS paint... MS Paint. sigh , they don't tell you in University that the biggest skill you will…

> Developers don't need 3 monitors to get through the working day, they need regular sessions with a psychiatrist.

Amen. I can see this as dev perk in job ads.

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

#408

Post by ankit219 »

elnygren wrote: post #376

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 (unless you are careful), it would be entered as 'Abcdef' and would not work. The issue was reported thrice and he said that there is no error, and did not fix. Then later it struck me (and i tried it on safari while he tried on the mobile responsive version of chrome) that it is this issue. Not saying the developer should not start working right away, but the expectation is that if they actually paid attention to what was reported, it would not have taken this much time to figure out what the issue was. There needs to a midway which varies from org to org depending on their workload.

> is it more probable that this work should be minimised

I guess this is where automated tests can come in. You fix something and see if passes the unit tests. But then everyone has their own approaches. For him, fixing a similar bug twice is worse than finding all possible mistakes at once.

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

#409

Post by hutzlibu »

xwdv wrote: post #234
hutzlibu wrote: post #212

Earlier quoted context omitted.

Today I gave advice to wifes friend friend. Who wants to build something "like ebay or amazon". (but cannot programm and wants to contract) Well, after a while they understood, there is a small difference, between a website - and a virtual market place. Seriously, it is easy to forget, that for most people, all these technical things - is just dark magic in a black box. Which sometimes work and sometimes won't. And I…

There doesn't have to be a difference, you can throw up a static list of items with price descriptions and a number you can text to purchase things. This is how we used to sell drugs in college. It was a simple URL you could go to with pricing and you just sent texts to a burner phone to arrange a transaction.

Yeah, this would be a website. Maybe ok for one primitive shop. And for webshops there are tons of frameworks, also possible with reasonable amoumt of work.

But a virtual marketplace .. where different actors make transactions, is a different story. Consider you have a bug and people loose money because of you. It really needs to be solid.

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

#410

Post by tialaramex »

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…

A friend of mine who works in UX always uses literal paper prototypes.

Not screens that look like doodles, but actual paper and cardboard and maybe some Blue Tac or paint.

Ordinary users apparently behave very differently, because it's obvious that a piece of paper can be changed and they know how to do it so it only takes a little nudging to find out what the customer actually thinks the system should look like.

She still has all the CS background to estimate that a change maybe that seems simple to the user just isn't viable, but using the paper prototypes encourages users to leave that to her and not second guess themselves into accepting a bad design because they're mistakenly assuming it would be hard to make a change when actually this is the perfect time to make such a change.

Post reply on HN