His first piece of advice really hits home: "Turn on compiler warnings" (and read them).
If it's a runtime bug and there are no errors or warnings from the compiler, I'll check what exceptions are thrown. In .NET on Windows you can use the event viewer to see details of exceptions even in release software. For JavaScript, the browser console often has useful information.
If it's a behavioural bug, i.e. not crashing, just doing something unexpected or out of spec, I'll try and track down where in the code it is happening. This is why modular and OO design is so important. It helps prevent the code base from becoming a big ball of mud.
At this point it's important to write down your assumptions of what a particular piece of code is meant to do and figure out a way you can test those assumptions.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I read Eric Lippert's "How to Debug Small Programs" and it's got some good advice.
His first piece of advice really hits home: "Turn on compiler warnings" (and read them).
If it's a runtime bug and there are no errors or warnings from the compiler, I'll check what exceptions are thrown. In .NET on Windows you can use the event viewer to see details of exceptions even in release software. For JavaScript, the browser console often has useful information.
If it's a behavioural bug, i.e. not crashing, just doing something unexpected or out of spec, I'll try and track down where in the code it is happening. This is why modular and OO design is so important. It helps prevent the code base from becoming a big ball of mud.
At this point it's important to write down your assumptions of what a particular piece of code is meant to do and figure out a way you can test those assumptions.