Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We stopped roadmap work for a week and fixed bugs

lalitm.com

Post reply on HN
Print view View original

291–300 of 356 posts

Re: We stopped roadmap work for a week and fixed bugs

#291

Post by wahnfrieden »

bluGill wrote: post #290
wahnfrieden wrote: post #288

Earlier quoted context omitted.

You misunderstand: I remove the logging as soon as the task is done. I definitely do not keep the LLM logging around. That's the beauty of it - it's able to add and remove huge amounts of logging per task, so I never need to manage the scale and complexity of logging that outlasts the task it was purposefully added for. With typical development, adding logging takes time so we keep it around and maintain it.

One of my needs is when something breaks in the real world I can figure out why. Bugs that happen at my desk I do what you said, add the logs I need and then delete them when it is fixed. However often there are things that I can't figure out how to reproduce at my desk and so I need logs that are always running on the off chance a new bug happens that I need to debug.

Yea that's valid. I do keep some kinds of logs around for this. But I'm selective with it and most logs I don't need to retain to manage this risk.

Re: We stopped roadmap work for a week and fixed bugs

#293

Post by Capricorn2481 »

sb8244 wrote: post #227
zelphirkalt wrote: post #157

Earlier quoted context omitted.

Yet engineers are pushed to give unknowable estimates of points and when things take "longer" (did you notice that shift right there?) they are either overdue, taking too long, or they don't, and to say: "It takes as long as it takes." is not accepted by middle management.

That's a strawman. It is not really related to the main point and I'm not sure of the point you're trying to make (maybe that tension exists?) Obviously things take as long as they take. I've always been an educator of this back to the business leadership. In my experience, most business people truly have no freaking clue how a product gets built and code gets shipped. Giving proactive updates (meaning not the day it…

I read them as agreeing with you, but pointing out that fixing bugs, at the end of the day, is up to the client.

It's just a predictable dance. You say something will take this long, then you find a bug. You point it out to the client, and they get mad at you because your estimate was off. They try to pressure you into fixing the bug for free, whether you were even around when it was made.

Eventually you just make a judgement call about bugs every time you run into them.

Re: We stopped roadmap work for a week and fixed bugs

#295

Post by LocalPCGuy »

bears123 wrote: post #292

Teams that implement this, or similar, exercise: how do you handle PR Reviews for fixits, if at all? I'd like to implement, but at a smaller team (8 devs, 3 whom approve PRs) the volume would be so high that the 3 senior devs would likely spend all their time reviewing.

In the spirit of that exercise, the fixes should not take an excessive amount of time to review. If they are, it's likely either the scope of the fix is too large for that kind of exercise, or the PR review process is too in-depth.

I would also question why only 3 of 8 devs approve PRs. Even if that can't change more broadly all of the time, this kind of exercise seems like a perfect time to allow everyone to review PRs - two fold benefit, more fixes are reviewed and gives experience reviewing to others that don't get to do that regularly.

So yes, definitely still do PRs, and if that is problematic, consider whether that is an indication the PR process may itself need to be reviewed.

Re: We stopped roadmap work for a week and fixed bugs

#296

Post by LocalPCGuy »

stuartjohnson12 wrote: post #164
invalidusernam3 wrote: post #163

I like the idea of this, but why not just have some time per week/sprint for bugs? At my company we prioritise features, but we also take some bug tickets every sprint (sometimes loads of bug tickets if there aren't many new features ready for dev), and generally one engineer is on "prod support" which means tackling bugs as they get reported

Because marginal work is only marginally rewarded. Spending one week and coming back to whoever with a nice piece of paper saying we fixed 60 bugs will earn a lot more rope from non-technical folk than fixing 3 bugs per week - the latter just looks like cleaning up your incompetence.

I suspect I'm preaching to the choir, but that is a communication issue and a sign the "rewards system" is out of whack, not a "reason" not to push for regular maintenance/tech debt/bug cleanup work.

It should be understood that there WILL be bugs, that is NOT a sign of incompetence, and so cleaning them up should be an ongoing task so they do not linger and collect (and potentially get worse by compounding with other bugs).

Re: We stopped roadmap work for a week and fixed bugs

#297

Post by dijksterhuis »

machomaster wrote: post #277
nsingh2 wrote: post #256

Earlier quoted context omitted.

> Be kind. Don't be snarky. Edit out swipes [1] [1] https://news.ycombinator.com/newsguidelines.html

"Please don't post shallow dismissals" Same source. Don't trivialize my useful feedback. If a person tries to communicate, but his stylistic choice of laziness (his own admission!) gets in the way of delivering his message, it is very tangibly useful information to tell, so that the writing effort could be better optimized for effect. I wasn't even demanding/telling him what to do. I simply shared my observation, but…

> appearing or claiming to be one thing when it is really something else

https://dictionary.cambridge.org/dictionary/english/ostensib...

ostensible laziness => not actually laziness.

although yes it is a stylistic choice (which i wont be changing as the result of our interaction).

Re: We stopped roadmap work for a week and fixed bugs

#298

Post by wiredfool »

RossBencina wrote: post #81
j45 wrote: post #66

Earlier quoted context omitted.

Bugs taking less than 2 days are great to have as a target but will not be something that can be guaranteed.

Next up: a new programming language or methodology that guarantees all bugs take less than two days to fix.

I think this, like many problems, can be reefactored into the halting problem. Which we know how to solve…. Right?

Re: We stopped roadmap work for a week and fixed bugs

#299

Post by oldestofsports »

ChrisMarshallNY wrote: post #16

I love the idea, but this line: > 1) no bug should take over 2 days Is odd. It’s virtually impossible for me to estimate how long it will take to fix a bug, until the job is done. That said, unless fixing a bug requires a significant refactor/rewrite, I can’t imagine spending more than a day on one. Also, I tend to attack bugs by priority/severity, as opposed to difficulty. Some of the most serious bugs are often qui…

> It’s virtually impossible for me to estimate how long it will take to fix a bug, until the job is done.

I understood it as the whole point of the 2 day hard limit - you start working on a bug that turn out to be bigger than expected, so you write down your findings and move on to the next one.

Re: We stopped roadmap work for a week and fixed bugs

#300

Post by oldestofsports »

kccqzy wrote: post #285
Aurornis wrote: post #274

Earlier quoted context omitted.

All of the buggy software projects I've been employed to work on have had some version of this rule. Usually it's implicit, rather than explicit: Nobody tells you to limit work on bugs to 1-2 days, but if you spend an entire week debugging something difficult and don't accumulate any story points in Jira, a cadre of project manager, program managers, and other manager titles you didn't even know existed will descend…

I hate this kind of management culture that misuses story points. Story points are supposed to take into account difficulty. So if you spend an entire week debugging a difficult bug, you should’ve accumulated about the same amount of story points as colleagues debugging ten easy bugs.

Every one have different approaches to story points and every one thinks their way is ”the right way”. In the end they just turn into an abstraction layer for man hours.
Post reply on HN