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

331–340 of 522 posts

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

#331

Post by hinkley »

afterburner wrote: post #302
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 mean... are they dumb, or just playing dumb to bully you?

The person who promoted them doesn’t care which, as long as they are consistent.

I think we spend too much time focused on the trigger man. Whatever person in your org is making your life difficult, there’s a person above them who knows and hasn’t done a goddamn thing about it. Who is the real problem?

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

#332

Post by hinkley »

manquer wrote: post #157
ftio wrote: post #121

Earlier quoted context omitted.

This doesn't require that things fit into a single sprint. It just incentivizes teams to ship their work in smaller chunks. If it helps motivate a team to divide some four-sprint piece of functionality into two shippable chunks that each take two sprints, I'd call that a win. Customers get something a bit faster even if it's not single sprint-sized.

Reiterating what gp said , not all dev is like that, lesser you are doing IT and more comp science or any unfamiliar territory really it is harder to break down ahead of time . Many times I can’t tell you what tasks need to done let alone how much time is needed and break it into smaller chunks during planning phase. If planning has to work you should be familiar with what you are building , with poor information on…

And if you are that familiar, why are you building instead of buying?

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

#335

Post by hinkley »

pkilgore wrote: post #140
mring33621 wrote: post #64

Earlier quoted context omitted.

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

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.

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

#336

Post by deepaksurti »

tardismechanic wrote: post #241
Jtsummers wrote: post #177

Earlier quoted context omitted.

Yes. He came to my desk a week or so after he okayed the release of the software and took me to a conference room. I don't know how long he chewed me out for because I was red with rage but too terrified of losing my job to say anything. I've experienced similar rage with only one other manager [1]. He was 3 levels above me in the management chain, I really liked the two above me (the test manager, as I was in test a…

> that's on them and you are absolutely 100% free to leave. Not if you are on an H1B visa ;-)

>> Not if you are on an H1B visa ;-)

But one must also 100% expect themselves to evaluate thoroughly T&C, pros and cons before signing up for anything, including a visa.

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

#337

Post by hinkley »

lmm wrote: post #243
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.

> Not everything can be broken down into chunks of work that fit into a single sprint. In my experience everything can be broken down if you spend five minutes actually trying to break it down. And the benefits are very much worthwhile.

How much brownfield work have you done?

People can hide the fact that they have a big ball of mud fir a very long time, and they only want to talk about improvement after hunts have gotten miserable.

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

#338

Post by nojvek »

I personally do value velocity not in number of lines, but in terms of unblocking users and other team members.

So:

1) user wants X done. Focus on that. Help the user X done. First iteration you have something crappy, doesn’t look great, too simple. That’s okay. Did it get X done. Cool. If you shipped some pretty UI but users don’t actually use it since it doesn’t solve the problem. That’s not productivity.

2) now that there are users using the tool, watch them use it. Ask questions, look at th me dashboard. Optimize their flow to do X. Make the UI delightful. We know with good certainty that this is a decent solution. Make it fast. Add tests. Harden it up so someone else doesn’t break it accidentally.

So if someone added two lines of using some existing node module that solves the user’s problem, those are very productive two lines.

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

#339

Post by rapnie »

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…

Even worse if non-technical marketing folks get their hands on prototype tools and use it to embellish the product with non-existing features in sales pitches without devs even knowing about it until after the sale. I've been there, and it is terrible. Also a vicious cycle as frustrated sales reps (by 'slow' dev progress in their perception) started inventing more and more of this stuff. A marketing + sales completely out of touch, chasing for bonuses. Brrr.
Post reply on HN