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

441–450 of 522 posts

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

#441

Post by el_oni »

k3liutZu wrote: post #425
el_oni wrote: post #403

Earlier quoted context omitted.

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

> LOC is a decent measure, but features are our targets Only if your measure of success is tied to fewer LOC.

I'm not sure I got across what I mean.

Ones target should be shipping features. If you use 10k LOC to get a feature out, or 500 lines of more concise, optimised code, what matters is the feature.

If you have LOC targets to meet you are incentivised to produce the former rather than the latter.

My point is that a high number of lines isn't as important as good features. Though the two can get conflated

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

#442

Post by WrtCdEvrydy »

ww520 wrote: post #222

The one that drives me up the wall is the schedule/cost anchoring question, "this should be easy to do, right?" every time they asking for a new feature. It's set to manipulate you to lower the schedule or the cost. If you say it's not easy, they would question your competency. If you say it's easy, they would say, well then you can get it done this week. It always gives me a pause, and then I would double the schedu…

> "this should be easy to do, right?

Yeah, couple of months - me, every time.

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

#443

Post by Aeolun »

bavila wrote: post #154
duderific wrote: post #131

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

What an absurd response from your manager. If you give a construction worker a design to build a wall, and the worker is given 2,000 bricks that must be used to build the wall, then, yes, of course the worker must lay down all 2,000 bricks to build that wall. However, if I am asked to build a computer-simulated model of said wall, and if there is a way to build the model with 200 lines of code that looks and performs…

Hell, if you can find a construction worker that somehow, magically can build the wall with 200 bricks instead of 2000, everyone would want to hire them because they’re saving them 90% of the cost.

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

#444

Post by notsag-hn »

The only mistake of the procedure is that if you don't have enough info you should ask for help before. This is very common and I have done that so many times to understand it's a waste of time. The only exception IMO is when you really need to understand certain parts of the codebase at a very low level so spending time solving things by yourself it's well worth as an exercise and helps a lot. If it's a part of the codebase you're not likely to be working on any time soon, just don't do it. Talk to whom reported the bug and also talk to the last person that worked on that piece of code (git blame is your friend here)

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

#445

Post by ankit219 »

greggman3 wrote: post #426
ankit219 wrote: post #408

Earlier quoted context omitted.

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 (unle…

After your suggested fix, how does a user enter the first letter of their password in upper case if that's what they want? Maybe you were expecting the dev to go through all the passwords and fix them so the first letter of all passwords is lower case? Oh but if they were following best practices they don't know the password, they only know its salted hash. Since the app was already shipping without the first letter…

Sorry, it requires more context. The reason this issue wasnt highlighted before was 1/ Many of our users were on laptop and did not use mobile site as much 2/ There was rarely a switch for those who used the mobile site (as in they rarely used desktop, else we would have caught it sooner). The fix was a longer one. We obviously had to have the same convention for a password in desktop and mobile web. For mobile users, after we made a fix, if they had trouble logging in, we asked them to capitalize the first letter of password and try again- when they logged in, we made them change the password and if they could not, they reset it. At the point we found it, we were pushing mobile site to users as an internal growth activity, and we were able to navigate it. It wasnt the best UX to be fair, but we potentially averted a bigger disaster at the time we did it.

PS. Yes, we were hashing the passwords.

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

#446

Post by dreamercz »

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…

> How often do you actually receive quality bug reports at work?

Very, very often. I work as a QA engineer whose main responsibilities is to go through the bugfixing queue and add needed info where necessary. And I have to spend a lot of time every day doing this. Sometimes it gets so bad I have to assign the ticket back to the reporter to add more info, because even I don't know where to look without it.

Interestingly enough, it's always the more senior people at our company who are guilty of writing crap bug reports.

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

#447

Post by Normal_gaussian »

ankit219 wrote: post #408
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 (unle…

I like to use two principles:

* smoke means fire

* a contained smokey fire is sufficient to hide the start of a wildfire

This means:

* keep your errors at 0. If it "can't be kept at 0" you're either too far gone or thinking about the issue incorrectly.

* user complaints are errors. Just because they aren't clear doesn't make them any less so.

There is a perception that users go out of their way to make unfounded complaints. In my experience, getting any complaints is the issue.

There is also a perception that some errors aren't important. If you have a channel to recieve an error its because it has business value. If a dev I was managing ignored a p/w entry bug due to non-dupe / assumed user error without significant digging and user interaction I'd be livid. Most businesses will lose significant value if users perceive the act of logging in as difficult.

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

#448

Post by deergomoo »

satyrnein wrote: post #232
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…

I find it useful to tell people around how many engineers that company has. They won't understand why, but they may understand that they don't understand. I also point out when a requested feature actually exists as a whole company.

I've started doing this too. The director of the company I work at is non-technical and will semi-regularly come to us expecting that we can build a competitor to Product XYZ in 6 months.

Pointing out that Product XYZ has 3000 employees and has been carving out a niche since 1995, while there are six of us with no knowledge of that market, is usually the only thing that gets him to accept that just because he understands what something does, it doesn't mean he understands what it takes to build it.

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

#449

Post by mikro2nd »

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.

Consider, then, that your experience might be limited in ways that you're unable to see due to that experience-bias.
Post reply on HN