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

231–240 of 356 posts

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

#231

Post by ChrisMarshallNY »

criddell wrote: post #218
ChrisMarshallNY wrote: post #70

Earlier quoted context omitted.

Yes. I often just copy the whole core dump, and feed it into the prompt.

This is something that I've been trying to improve at. I work on a Windows application and so I get crash dumps that I open with WinDbg and then I usually start looking for exceptions. Is this something an LLM could help with? What exactly do you mean when you say you feed a dump to the prompt?

I literally copy the whole stack dump from the log, and paste it into the LLM (I find that ChatGPT does a better job than Claude), along with something along the lines of:

> I am getting occasional crashes on my iOS 17 or above UIKit program. Given the following stack trace, what problem do think it might be?

I will attach the source file, if I think I know the general area, along with any symptoms and steps to reproduce. One of the nice things about an LLM, is that it's difficult to overwhelm with too much information (unlike people).

It will usually respond with a fairly detailed analysis. Usually, it has some good ideas to use as starting points.

I don't think "I have a bug. Please fix it." would work, though. It's likely to try, but caveat emptor.

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

#232

Post by [deleted] »

jorvi wrote: post #228
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…

Yeah, "no bug should take over 2 days" tells me you've never had a race condition in your codebase.

[deleted]

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

#233

Post by ChrisMarshallNY »

jorvi wrote: post #228
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…

Yeah, "no bug should take over 2 days" tells me you've never had a race condition in your codebase.

I'm sure that you're right. I'm likely a bad, inexperienced engineer. There's a lot of us, out here.

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

#234

Post by ljm »

OhMeadhbh wrote: post #55
ChrisMarshallNY wrote: post #24

Earlier quoted context omitted.

In that case, maybe having bug fixing be a two-step process (identify, then fix), might be sensible.

I do this frequently. But sometimes identifying and/or fixing takes more than 2 days. But you hit on a point that seems to come up a lot. When a user story takes longer than the alloted points, I encourage my junior engineers to split it into two bugs. Exactly like what you say... One bug (or issue or story) describing what you did to typify the problem and another with a suggestion for what to do to fix it. There do…

I like to do this as a two-step triage because one aspect is the impact seen by the user and how many it reaches, but the other is how much effort it would take to fix and how risky that is.

Knowing all of those aspects and where an issue lands makes it possible to prioritise it properly, but it also gives the developer the opportunity hone their investigation and debugging skills without the pressure to solve it at the same time. A good write-up is great for knowledge sharing.

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

#235

Post by Windchaser »

ChrisMarshallNY wrote: post #73
OhMeadhbh wrote: post #51

Earlier quoted context omitted.

At Amazon we had a bug that was the result of a compiler bug and the behaviour of intel cores being mis-documented. It was intermittent and related to one core occasionally being allowed to access stale data in the cache. We debugged it with a logic analyzer, the commented nginx source and a copy of the C++ 11 spec. It took longer than 2 days to fix.

I’m old enough to have used ICEs to trace program execution. They were damn cool. I seriously doubt that something like that, exists outside of a TSMC or Intel lab, these days.

/imagining using an internal combustion engine here

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

#236

Post by JJMcJ »

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 like remodeling. The drywall comes down. Do you just put up a new sheet or do you need to reframe one wall of the house?

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

#237

Post by newtwilly »

muixoozie wrote: post #198
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…

I worked for a company that.. Used msql sever a lot and we would run into a heisenbug every few months that would crash our self hosted msql server cluster or it would become unresponsive. I'm not a database person so I'm probably butchering the description here. From our POV progress would stop and require manual intervention (on call). Back and forth went on with MS and our DBAs for YEARS pouring over logs or whate…

Wow, that's pretty epic and satisfying

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

#238

Post by amalcon »

HelloNurse wrote: post #162
fransje26 wrote: post #121

Earlier quoted context omitted.

> searching for the cause of a bug let you discover multiple "forgotten" servers, ETL jobs, crons all interacting together. And no one knows why they do [..] And then comes the "beginner's" mistake. They don't seem to be doing anything. Let's remove them, what could possibly go wrong?

If you follow the prescribed procedure and involve all required management, it stops being a beginner's mistake; and given reasonable rollback provisions it stops being a mistake at all because if nobody knows what the thing is it cannot be very important, and a removal attempt is the most effective and cost efficient way to find out whether the ting can be removed.

I have had several things over the course of my career that:

1) I was (temporarily) the only one still at the company who knew why it was there

2) I only knew myself because I had reverse engineered it, because the person who put it there had left the company

Now, some of those things had indeed become unnecessary over time (and thus were removed). Some of them, however, have been important (and thus were documented). In aggregate, it's been well worth the effort to do that reverse engineering to classify things properly.

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

#239

Post by thfuran »

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…

>I can’t imagine spending more than a day on one.

You mean starting after it has been properly tracked down? It can often take a whole lot of time to go from "this behavior is incorrect sometimes" to "and here's what need to change".

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

#240

Post by georgemcbay »

khannn wrote: post #158
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…

I had a job that required estimation on bug tickets. It's honestly amazing how they didn't realize that I'd take my actual estimate, then multiply it by 4, then use the extra time to work on my other bug tickets that the 4x multiplier wasn't good enough for.

Are you sure they didn't realize it...?

Virtually everywhere I've ever worked has had an unwritten but widely understood informal policy of placing a multiple on predicted effort for both new code/features and bug fixing to account for Hofstadter's law.

Post reply on HN