Good advice. On your first point, when debugging I find it helpful to apply the scientific method instead of just poking around the debugger and making somewhat random code changes (note: not implying that's what you meant, just as an example I see people often do).
Observe by examining values in the debugger, monitoring the application's behaviour and checking the logs like you said. Then come up with a hypothesis based on what you observed, and derive predictions from that. Then you can carry out tests based on your predictions, not strictly speaking in a TDD fashion but test by changing the data or code, and analyse the results of your changes. There you should gain more insight into the problem if not determine the cause outright.
The point being to make small, specific changes not necessarily just focused on the code, based on your predictions instead of just going on autopilot thinking "oh this tweak will probably fix it." Don't do things without a reason.
This is good advice as a tactic for debugging. Sometimes even just stepping though the code to see where it fails is enough. Some people don’t even do that.
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.
Good advice. On your first point, when debugging I find it helpful to apply the scientific method instead of just poking around the debugger and making somewhat random code changes (note: not implying that's what you meant, just as an example I see people often do).
Observe by examining values in the debugger, monitoring the application's behaviour and checking the logs like you said. Then come up with a hypothesis based on what you observed, and derive predictions from that. Then you can carry out tests based on your predictions, not strictly speaking in a TDD fashion but test by changing the data or code, and analyse the results of your changes. There you should gain more insight into the problem if not determine the cause outright.
The point being to make small, specific changes not necessarily just focused on the code, based on your predictions instead of just going on autopilot thinking "oh this tweak will probably fix it." Don't do things without a reason.
This is good advice as a tactic for debugging. Sometimes even just stepping though the code to see where it fails is enough. Some people don’t even do that.