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

461–470 of 522 posts

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

#461

Post by jameshart »

manquer wrote: post #279
jameshart wrote: post #219

Earlier quoted context omitted.

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…

It is not just only research that is exploratory, even the kind of bug fixes the article talks about can be hard to predict. replication of an issue or understand a new module can be uncertain, race conditions or data specific issues are uncertain too. Identifying and solving something similar to [1] with a team is not simply possible when you plan with agile. I am likely going to go the next item once I mitigate the…

Ah - you’ve been subjected to management-by-scrum. I am sorry.

Scrum is a collaboration hack for creative problem solving teams, not a managerial accountability tool. The version of scrum where stand ups are for checking on the team’s progress and velocity is reported on up the org is using the tools of scrum to solve a very different problem than the one that it was designed for.

I’m sorry you don’t believe it’s possible but I can tell you from experience that it is possible to use the processes of scrum and the principles of agile to help a team collaborate on open ended creative problem solving tasks.

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

#463

Post by hutzlibu »

Cthulhu_ wrote: post #395
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…

FB Marketplace - or, you know, actually ebay or amazon - are all viable if said friend just wants to sell some shit online.

No no, it was not about selling things, it was about creating a marketplace.

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

#464

Post by White_Wolf »

That sort of question is ussualy asked by a someone that either has no clue how programming works or are just from the sales team. I do admit I left one software company because of a manager like that that. Fixing bugs is painful(to say the least) if you don't know the code properly. Even worse when you have to "hit the ground running" and take over a project because the main guy for it left "due to personal circumstances" or "difference in oppinion". Ever since then: - "If you think it can be done faster please go ahead." - "It will take as long as it takes, not a minute more" - "if you really want a time estimate: it will take me 4* "

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

#465

Post by danjac »

jameshart wrote: post #461
manquer wrote: post #279

Earlier quoted context omitted.

It is not just only research that is exploratory, even the kind of bug fixes the article talks about can be hard to predict. replication of an issue or understand a new module can be uncertain, race conditions or data specific issues are uncertain too. Identifying and solving something similar to [1] with a team is not simply possible when you plan with agile. I am likely going to go the next item once I mitigate the…

Ah - you’ve been subjected to management-by-scrum. I am sorry. Scrum is a collaboration hack for creative problem solving teams, not a managerial accountability tool. The version of scrum where stand ups are for checking on the team’s progress and velocity is reported on up the org is using the tools of scrum to solve a very different problem than the one that it was designed for. I’m sorry you don’t believe it’s pos…

Maybe it's finally time to give up on Scrum. Whatever good intentions the original inventors had, whatever idealized situations it may work with perfect unicorn teams, the general experience in the wild of this benighted framework is a tool in the hands of mediocre, inexperienced managers to micromanage, infantilize and monitor developers. It's essentially warmed up command-and-control Taylorism with some feelgood buzzwords and neologisms thrown in. I would even prefer the old horrible Waterfall approach, at least we didn't have all the endless, pointless groomings, standups and retros to attend along with the "we so agile" gaslighting.

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

#466

Post by crispyambulance »

Jtsummers wrote: post #120
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…

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…

One thing I learned very early in workplaces where there are "project management professionals" is to NEVER to casually mention even the implication "dates" and "completion" anywhere near each other.

Someone is bound to jot that down and interpret it as a hard commitment regardless of any other details or conditions.

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

#467

Post by r_c_a_d »

rburhum wrote: post #439

My most challenging bug was fixing a memory overwrite of a COM reference counter (of all things!) that would only happen under very rare conditions - when a 3rd party C library that was compiled with different calling convention would be called with a certain amount of parameters. It took me a month to chase down - frankly, it would have been impossible for me to figure out if Visual Studio did not have data breakpoi…

Nice! I had something similar. It took over a week and the fix was to _remove_ one line of code.

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

#469

Post by raducu »

corin_ wrote: post #387
raducu wrote: post #381

Earlier quoted context omitted.

"I try and do as much as I can with the information provided." I know I'm guilty of this one, and I've stayed away from high paced jobs and appreciate jobs where people are ok with my reluctance to bother a lot of people even if that means it takes me longer to figure things out on my own. This also means I build a much deeper understaning of the systems I work with, or at least I like to think so, and some people ha…

Their praise is obviously great for knowing how you're doing, but it doesn't confirm the reason for your good insights. Plenty of people manage to be good at what they do without doing 100% the best way possible, so maybe you'd be even better if you changed your approach! Of course I know nothing about you so I'm not trying to give advice, just replying about the "confirmed" being a potential cognitive bias.

I also think I could improve a lot in this regard, asking sooner is my problem and I'm working on solving it, but it is a slow and long process.

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

#470

Post by Sebb767 »

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…

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

Okay, how do you handle a network failure, a full disk or a faulty RAM stick?

I see your overall argument, but at some point you've got to accept that you can't handle everything.

Post reply on HN