Live data from Hacker News

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

mrlacey.com

251–260 of 522 posts

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

#251

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 need in this job is patience and learning how to channel your inner zen.

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

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

#252

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…

Nice comeback

it's a good point but pretty cringe tbh

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

#253
post #105
post #89

Earlier quoted context omitted.

Early in my career, I learned a simple 'demo day' rule: never demo things that aren't end-to-end done. When you do, it can easily confuse folks who aren't deeply involved in your project ("haven't I seen this already?") and can hurt team morale because they never get a "shipped it" moment that feels good. More to the point: enforcing this rule incentivizes teams to build things in small, shippable components. Nobody…

I'm still conflicted about this. On the one hand I agree. On the other, I wish we could educate people enough for them to understand Proof of Concepts and Minimum Viable Products.

It depends on the audience. A customer demo is different than an internal demo, and I assume you are referring to an internal demo.

You must demo the product in a form that leaves the right impression of the current state. If you are painting a picture of a polished product, expect polished expectations. Instead, show the bugs and say "we are still working through this section" Show missing pages, show your work in progress. Show wrong colors. Show potential, wave your hands and tell them to imagine this part working. Don't fake it. If that feels wrong, then a demo isn't right.

If you show it in a form that looks complete and polished, even if you say it is not, how can you expect any other conclusion from the viewer other than "it's practically ready!"?

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

#254
post #89

Earlier quoted context omitted.

Early in my career, I learned a simple 'demo day' rule: never demo things that aren't end-to-end done. When you do, it can easily confuse folks who aren't deeply involved in your project ("haven't I seen this already?") and can hurt team morale because they never get a "shipped it" moment that feels good. More to the point: enforcing this rule incentivizes teams to build things in small, shippable components. Nobody…

> incentivizes teams to build things in small, shippable components. Isn't this a bit of a fallacy? Not everything can be broken down into chunks of work that fit into a single sprint. There's a reason I stopped bothering with Scrum a while ago, and this is high on the list.

"Shippable" is not equivalent to "done", in any way.

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

#255
post #240

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…

Classic buy vs build! Are you sure that they were not looking for a simple eCommerce site made using Shopify/BigCommerce? Maybe they are just looking for a side hustle.

Yep. buy vs build was a big change for our company, VP made the decision to stop building but the culture is ingrained and difficult to change.

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

#256
post #59

I recall a story about someone at a government contractor who did a major refactoring and removed thousands of lines of code from a project, increasing its performance, only to be told by management that they'd signed a contract that said the company got paid by lines of code delivered, and his improvement would cost them tens of thousands of dollars, so revert the whole thing.

That's a pretty bad breakdown in communication- the manager should have communicated how the contractor was paid and the programmer should have spent their time working in line with that - whichever end that breakdown happened on that sounds like that led to an awful lot of misery and wasted time - ouch

> That's a pretty bad breakdown in communication- the manager should have communicated how the contractor was paid and the programmer should have spent their time working in line with that

Seems

more

like

a

breakdown

in

negotiating

the

contract

than

a

breakdown

in

communication.

No

customer

is

actually

interested

in

having

the

programmer

do

their

work

in

line

with

a

compensation

scheme

that

pays

more

for

more

lines

of

code.

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

#257
post #33

Earlier quoted context omitted.

They PHB should put extra bonuses on kLOC, like 1k$ per 1kLOC, and watch the codebase increase exponentially and since documentation is better than code, double the amount for line of comments.

That's a literal Dilbert strip, 1998-ish, IIRC.

https://dilbert.com/strip/1995-11-13

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

#259

Earlier quoted context omitted.

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 mak…

sounds about right to me. i've had product managers argue that we fix bugs fast enough that we should not actually try to implement real solution (python2 to python3 upgrade). This lady is like 'every py2->py3 bug takes less than 2 hours to fix. Why would we do the solution that takes multiple sprints?' jaw dropped. since then i'm committed to being the biggest office space corporate schmo possible. let me cog it up,…

Sheesh, python 2 to 3 is definitely something worth taking the time to do.

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

#260
post #122

Earlier quoted context omitted.

Task completion should be the metric, not line counts, otherwise the incentive is creating the most bloated piece of software and the most comprehensive unit-test possible. Any system is going to be (ab)used by the employee to their benefit.

Relevant post: https://news.ycombinator.com/item?id=23762526 Task completion would also be abused, because it's too vague. It simply shifts the burden to the one formulating the task (e.g. preventing holes in the specification like missing performance or hardware requirements). Exaggerated example: if the "task" is to automatically deliver a report containing certain data and formatted in a specified way, the easy wa…

It's even harder then you toss support tickets into the mix, and if the team has other non project work.
Post reply on HN