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

451–460 of 522 posts

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

#451

Post by a_imho »

l0b0 wrote: post #329
snidane wrote: post #278

"My point today is that, if we wish to count lines of code, we should not regard them as “lines produced” but as “lines spent”: the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger." ~ Edsger Dijkstra

I'm sure Dijkstra could get away with saying that, but how would you phrase something equivalent to someone above you in the food chain without getting nuked from orbit in response? I can just see how the conversation would go: PHB: You've only added two lines - why did that take two days! Dev: Because it took that long to understand the requirements, understand the code, find the root cause, write a test to verify t…

Not just spent, but every loc written adds a small amount of maintenance cost to the TCO. I find non technical people like when engineers use their vocabulary.

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

#452

Post by buddhiajuke »

ioulian wrote: post #413
mcbits wrote: post #201

Earlier quoted context omitted.

This reminds me of the infamous Speed-Up Loop. https://thedailywtf.com/articles/The-Speedup-Loop

And this reminds me about another story, I can't find the link but it was something like this: A game developer was making a game for PlayStation and they were over their memory limit. They were approaching a deadline but couldn't remove anything else from the game to fit it in memory (or disk, I can't remember). So a senior dev came by, changes the code in 1 minute and everything could fit into memory now. The thing…

There’s an episode of “Star Trek: the Next Generation” where Scotty, the engineer from the original Shatner Star Trek tells the next-century engineer LaForge that this is how it’s done. You never tell the captain all that you have so you keep something to squeeze at the fatal moment.

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

#453

Post by bregma »

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…

To a user, the user interface is the software.

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

#454

Post by Uberphallus »

dreamercz wrote: post #446
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. Interesting…

I went from huge shop to medium shop and I really miss that layer of QA engineers before the bugs got to us, it filtered so much nonsense that I had tremendous respect for those guys.

Half of my current tickets barely have 2 sentences in so-so English.

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

#455

Post by Aeolun »

NateEag wrote: post #264
beefield wrote: post #117

Earlier quoted context omitted.

> 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

I used to think that was hilarious. These days I can only look at it and think "the expert is terrible at calm confrontation and good communication. There would be no problem if he had developed those skills."

That has to come from two sides though. The people in this sketch are clearly not interested in listening to what the expert says either.

Getting sensible requirements is not only on the expert.

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

#456

Post by Aeolun »

seneca wrote: post #52
majormajor wrote: post #30

Earlier quoted context omitted.

Were they right about the person being a low performer? I'm curious if this is "everybody knows this person isn't doing any work, here's a blindingly obvious metric to use to defend this move to HR" because HR orgs often hate things that don't have metrics attached, or if it's "I don't understand what this person is doing, and I don't see any commits, so it must be nothing"?

Completely valid question, and I think you make a great point here. A lot of baffling managerial behavior is because the manager is working in a baffling bureaucracy. Unfortunately, I think this situation was largely of the latter case, and maybe some motivations I'm not aware of. They were a senior engineer that spent a lot of time coaching the rest of the team, and less time on their own personal work. The commits…

Yeah, I’ve been in this situation before (without the PIP), where I had to explain to my manager that I can either help everyone get their work done, or do my own work, but given the number of people asking for help it was not going to be both.

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

#457

Post by ankit219 »

Normal_gaussian wrote: post #447
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…

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

I agree with you on most parts, but not about keeping your errors at zero. In a fast moving environment, there will be mistakes or things that are missed. ideally, bugs should not have any attached meaning - yes there was an issue and now it is fixed. Good thing we found it today compared to a few days later. That is it.

Getting complaints from users is a good thing, but yeah missing them or not fixing them when you come across them is. As a user, I would be overjoyed if I reported a small issue, and the company fixed it quickly.

Being livid is natural, but I was pretty sure the developer himself knew he screwed up this time, so no point expressing it. Plus as I explained in the earlier comment, this escaped for so long because we did not have many cross device users. So did not affect that many users. Just for my experience, I check this every single time i test a website before it goes live. (and also check with other keyboards than just Gboard)

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

#458

Post by lmm »

mikro2nd wrote: post #449
lmm wrote: post #243

Earlier quoted context omitted.

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

Unlikely. I used to go looking for tasks that couldn't be broken down; I'd get excited when someone would claim that their task couldn't be broken down. But they always could, and it was never even hard.

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

#459

Post by yetanta »

core-questions wrote: post #115
ftio wrote: 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.

Not to put it bluntly but you can not do even small bits of work in 2-3 weeks?

Sometimes your demo is nothing more than 'here it is in the log doing xyz' or 'I added this thing to this config file'. Not all demos are big flashy ordeals. The team I am on right now most of my demos look exactly like that. I can usually do them right after the standup. Our team allows it because we are mostly remote and talking to each other helps.

I personally use scrum as a weapon to make sure management does not overload our teams. Those made up story points are a good way to say 'you have tasked us with 4 months of work in 2 days'. You have to know your manager too. You have to talk to them. Know what they are looking for. Some take a very hands off approach. Some want the nitty gritty details. For both of those a 'oh that is going to take 3 months' may sometimes work. But it does not give them actionable items to help you. The task broken down into some sort of chunked out work does. Sometimes you do not know. It is OK to admit that. That is when you make a discovery story. Make sure they are onboard with that story is to help you find out what is needed. Even then you will still learn along the way.

I worked with one guy who wanted to task things down to 15 minute increments, 6 months from now. He kept failing. Because he was being too narrow. He refused to do story points. Because they were 'stupid' yet management kept piling more stuff on him to fail at. He was in every weekend and in until 9PM every night. Because he had no tools to push back. Give your management numbers and actionable items or they will assume everything is hunky dory.

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

#460

Post by watwut »

eikenberry wrote: post #162
Jtsummers wrote: post #120

Earlier quoted context omitted.

Also, never use the word "done" in any context in a meeting like that. Do not even say: "I'm not done". They won't hear the "not". Say, "Development is still in progress" or something similar. I got chewed out for something being released (where it was found to be broken) to a customer because I said something like: "I'm about 80% done with testing, but I haven't run into any issues yet." They released it even though…

Did you really get chewed out? That seems pretty much like a deal breaker for me. Managers are collaborators, not parents, and have no place talking to co-workers in such a diminutive manner.

Parents are not supposed to talk to kids the way chewing managers talk to people. Also, business oriented managers are not collaborators in my experience and take such idea as offence.

And yep, I was actively avoiding that environment too.

Post reply on HN