If I could understand how you approach these bugs and how they are fixed, what method do you use, and how do you look at the code to fix them? Then, honestly, it would be invaluable to me.
Also, if you could please share any resources or articles, I would be very interested in looking at them; I could take some lessons from them.
Thanks.
dcminter•9mo ago
• What happens?
• What did you expect to happen?
If they're the same then NOT A BUG, and WONTFIX :D Assuming it's a bug, the next important thing is to be able to reproduce it. Ideally with a test case. A test case allows you to:
• Rapidly test whether your fix (when you have one) has worked
• Ensure that the bug doesn't reoccur (avoid "regressions")
Sometimes it can be very hard to reproduce a bug, but of course if you can't reproduce it you will never be sure your fixes have worked.
The bug spotting process consists of iterations of:
• Gather data
• Form hypothesis
• Test hypothesis
It's basically the scientific method. Data can be all sorts of things; events occurring in logs, facts about the user's interaction, versions of databases etc. If you have no hypothesis about what's going on, gather more data until you do.
Oh and write your data, hypothesis, and test results down somewhere so you don't get into loops of trying the same thing or think you've tested things that you haven't or know things that you don't.
A hypothesis can be as simple as "maybe it's the version of the database" and the test being "change the version of the database and see if the bug disappears" ... or it could be something more complicated and convoluted ("When this thread does this thing and that one races it to do this other thing with this particular piece of input data then....")
If you were able to reproduce the problem, your hypothesis was correct and the test indicated that you had resolved it, then you're good to go. Then it comes back next week and you discover it was slightly more complicated than that ;)
It's a skill and it improves with practice. Good luck.
---
Edit: Originally I wrote "two approaches" but then realised I really just have this one, but one variant of it is "I recognise something I had at the back of my mind when I was writing the code in the first place" - but that's really just that I already have the data, form the hypothesis off the back of that, and still have to test it to be sure.
Also, before you WONTFIX ... do consider why your expectations and the reporters' expectations conflict. Is your documentation confusing? Are your expectations out of whack with what real users want? Most people aren't just idiots, so a raised bug usually indicates that something is wrong even if it's not the code.
timonpimba•9mo ago
I'm a beginner programmer and a Mathematics Undergrad. I learned C++ and thought of applying it to real-world things. So, I picked a GitHub repo and a "good first issue" and started working on it; I was stuck for a long time.
I think this is a fundamental skill that is talked about very little, and strangely it has not been covered on YT, also couldn't find articles.
But I'll keep trying to learn it. As you said, I'll need to do more practice.
You are very kind person. Thanks.
dcminter•9mo ago
My answer, of course, is a bit broad-sweeps. The nitty gritty will depend on the project etc. In your case, if it was flagged as "good first issue" it's probably a relatively small self-contained bug (or the reviewer thought that - they might have been wrong). Well worth seeing if one of the project members can give you a hint.
I wish I could point you to more material but I don't have much at my fingertips. There's a chapter on debugging in "The Practice of Programming" by Rob Pike that I recall being good, but it might be a bit antiquated.
It's worth bearing in mind that there are innumerable different types of bugs and different languages are more or less vulnerable to some of them (e.g. you'll never use-after-free in Java, but you can leak memory just as easily in Java as in C++ - and out-of-memory issues might be a little more likely in a profligate language like Java)
For C++ there are some excellent books by Scott Meyers which, if they've been updated (I was last a C++ dev before 2000) contain a host of little gotchas that can lead to all sorts of weird problems. But hopefully the one you're investigating will be something more straight-forward.
> You are very kind person. Thanks.
It's genuinely a pleasure; I think this is a super-interesting topic. Also I think that debugging is one of the most fun bits of software development - though I know a lot of people would disagree with that!