Live data from Hacker News

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

mrlacey.com

211–220 of 522 posts

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

#212

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…

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 find this sometimes hard to deal with, because society gets more and more technologized. At least a very basic understanding would be helpful.

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

#214
post #170

This article made a number of great points. > I know some developers don't like having to fix bugs, and so do whatever they can to get out of it. Claiming there isn't enough is a great way to look like you're trying to help but not have to do anything. God, this behavior has annoyed me so much at times. I've worked with a few developers that were not bad overall, but would use the slightest excuse to punt on fixing a…

Oddly, I've worked at places where they PREFERRED minimized changes to bugs. i.e. "You made a whole new method to deal with this problem, is there a smaller fix?"

Thankfully most places I've been at -prefer- a smaller fix even if it takes a little longer to figure out.

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

#216
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 have never had anyone indicate to me that this is a problem. However, every time I spend days on a problem that ends up being a trivial number of LOC, I get a feeling of anxiety that I am going to be seen as incompetent. That's been the case my whole career even though I know it's unfounded.

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

#217
post #19

Earlier quoted context omitted.

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

Try changing the colour and getting told it isn't the same shade of red as the drawings presented by the designer on his PDF presentation.

"It looks different on my iPad, we need it to look exactly the same everywhere"

No, No you don't.

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

#218

> I don't like having to fix bugs. ??? I rather enjoy fixing bugs, particularly really hard ones. They can be fun logic puzzles that take some sleuthing to figure out and offer multiple pay outs... First time reproducing it. Figuring out the problem. Figuring out the best fix. Test case fail -> test case pass.

It's kind of a personal style thing. Debugging can be really rewarding to the extent it actually does feel like a puzzle rather than digging through a sewer, but I myself like green-field development lots more.

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

#219
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…

When you’re doing exploratory work, the discipline of stopping, examining what you have learned already, deciding whether the goal still makes sense, and correcting course and reprioritizing seems even more important to me. You don’t know what you will be doing more than a few days ahead? Then your sprint length should be a few days and at the end you recombine and replan.

I mean obviously this only makes sense as a way of organizing a team who are trying to build something exploratory - that’s what scrum is meant for. If you are trying to pursue a solo research project within a team the rest of whom are doing scrum then... that’s not a problem agile can solve.

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

#220

Earlier quoted context omitted.

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

Can you please help your brothers out and hint at what company this is so we can all avoid?

It has other good things that keep me there. Everything's a tradeoff.
Post reply on HN