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

131–140 of 522 posts

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

#131

Post by duderific »

kevsim wrote: post #5

Do people actually have fights like this with management at their companies? Not trying to knock the author, but I'm just surprised anyone would actually hear this kind of comment in 2020. I'd think by now any and all metrics tying lines of code to productivity would be long dead.

They don't always make the comment out loud, but you can tell they're thinking it.

They absolutely use lines of code metric at my company. I don't miss any chance to tell my manager it's complete bullshit. His answer: "Engineers are supposed to write code, just like construction workers are supposed to build houses."

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

#132

Post by pintxo »

beefield wrote: post #117
kevsim wrote: post #5

Do people actually have fights like this with management at their companies? Not trying to knock the author, but I'm just surprised anyone would actually hear this kind of comment in 2020. I'd think by now any and all metrics tying lines of code to productivity would be long dead.

> Do people actually have fights like this with management at their companies? There was a time when I thought this video was funny: https://www.youtube.com/watch?v=BKorP55Aqvg

Still think it's funny. But yes, it's no fun while you are the expert.

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

#133

Post by qayxc »

kevsim wrote: post #36
WalterBright wrote: post #32

Earlier quoted context omitted.

Many people assume their manager knows what the employee is doing. They often aren't, meaning they go by what they can see, which is lines of code. The smart thing to do is to regularly keep your manager updated on what you're doing, especially if they don't come by regularly and ask you. Especially if you are WFH.

That’s true. And I guess depending on the job/manager you could replace lines of code with “user-visible changes to app”, etc.

That'll be exploited as well. The number of pointless UI and feature changes would skyrocket without the app actually getting better or gaining meaningful functionality.

Meta-metrics might be much more helpful, though harder to come up with, quantify and monitor. Things like defect rates, user reported incidents, user satisfaction, stuff like that.

Things that cannot easily be gamed from within the development process and that are still directly linked to the success and economic viability of the product and its development methodology (though on a higher level).

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

#134

Post by caymanjim »

ddingus wrote: post #130
core-questions wrote: post #115

Earlier quoted context omitted.

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

Why would it be? For all the things that can be atomic like that, it's good practice. The bigger ones just take time, and aren't shown, until ready for use.

It's an anti-pattern to simply not demo any progress until done. If you're doing agile right (loaded statement), the solution is to make sure everyone understands what's being done. If the audience is expecting all demos to show complete products, find a different audience to demo done-but-incomplete work. The idea is to get feedback before you've sunk six months into something that may not meet expectations.

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

#135

Post by seamyb88 »

archi42 wrote: post #19
kevsim wrote: post #5

Do people actually have fights like this with management at their companies? Not trying to knock the author, but I'm just surprised anyone would actually hear this kind of comment in 2020. I'd think by now any and all metrics tying lines of code to productivity would be long dead.

I regularly hear a friend complain about BS like this and variants. "Why did adding a button take a week, it's just a button?!" is also very popular. Not sure what's worse, that or the recurring "that element should be 1px to the left, drop everything you're working on and fix it asap"...

I sometimes battles with myself over things like this. I code for my job and for recreation, the latter being where UI comes in. In order to get anything done in recreational programming you have to concede that you're not building an app with bells and whistles. Yet I lose so much time over $hit that does not matter. Usually aesthetics.

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

#136

Post by tdrp »

We had a non-tech lead at some point (although his title was something like development manager) and he would praise my coworker for how many check-ins he did. Except that coworker would do things like:

1- Copy-paste an entire class into a new class and change a single constant in it, because he was too lazy to do inheritance.

2- "Solve" multiple bugs a day that he had introduced himself the day before.

3- Loudly complain about other people's frameworks/codes.

He was the super confident type even though he was wrong more often than not. But paired with a non-tech lead with his own impostor syndrome, it was a recipe for disaster.

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

#137

Post by D-Coder »

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 seem to remember Joel Spolsky recommending that UI demos be done on paper... with pencil. That way even a manager can see what it will look like without thinking that it's all done. (Can't find a reference quickly.)

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

#138

Post by baddox »

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…

Not even just the backend! Frontend interactivity itself can be very complicated, and it generally is not fully specified by design (do your design specs come with state machines?) A few things that are often missing from a Figma/similar are things like error states, loading states, handling longer text content than the mockup, and responsive design.

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

#139

Post by dgb23 »

trav4225 wrote: post #86
dgb23 wrote: post #82

Earlier quoted context omitted.

The problem is not "manager/client doesn't understand software development". That's fine. The problem is lack of trust in you as the expert and possibly a lack of self-awareness (they think they understand). A manager/client should make mostly strategical decisions like: We should solve this problem, here are the resources. And almost never tactical. They also shouldn't even care or look at LoC. They shouldn't be wor…

Ah, agreed. I guess that, in my experience, not understanding SW development tends to go hand-in-hand with not trusting the developer. I found your phrase "lack of trust in you as the expert" a little jarring because (again, in my personal experience) considering the developer to be a domain expert is somewhat of a foreign concept. I suspect/hope the situation is better elsewhere in the industry. :-)

I meant 'expert' as in the person responsible for the technical side. Not in the sense of 'they know everything they need to know all the time' or anything like that.

> I suspect/hope the situation is better elsewhere in the industry. :-)

I do freelance, client work. Alone and in (very?) small teams. Typically my/our clients only have a superficial understanding of everything technical (if at all). Trust often needs to be earned.

One way to gain trust is being creative/optimistic and explaining feasible possibilities and strategies. Another one is being pragmatic and not selling them something they don't need, or might not need.

And then the most important one is to have conversations about their problems and wishes. Showing that you understand them by asking questions and writing a specification. And explaining your (iterative) workflow: "Let's figure this part out after we've done this other part." I guess this is the "domain" part of the process.

My experience is that if trust is in danger then the work is less valuable, less fun and less sustainable. Indications of this are things like we discussed before and similar:

- Trying to measure effort instead of rewarding value.

- Nitpicking, bikeshedding and other distractions.

- Overstepping their expertise (typical for UI design, a bit less for programming)

Now most of my interactions are good but sometimes I get the above. We're actually discussing of doing more upfront communication work in the offers and initial discussions to prevent these things (even by filtering out clients/collaborators) and to set a tone. Because again, this is unsustainable on multiple levels and it never ends well...

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

#140

Post by pkilgore »

mring33621 wrote: post #64
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…

Yes, very much like the time I replaced a getfakedata() method with a getrealdata() method and then management complained that it was much slower now.

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

Post reply on HN