Sometimes the hardest thing in programming is not developing new software or fixing bugs but finding out what the actual issue is.

When you have clients and users spanning the globe and not always mastering the use of English (lingua franca of the software developers) it can be hard to understand what is the problem that the reporter was facing.

Whenever I find myself in such a scenario, these are three tricks I use to get to the end of it.

1. Ask for more details

Seems obvious, right? I'm sure there are people reading this right now and rolling their eyes but the devil's in the details (pun somewhat intended).

If the person reporting the issue knew how to offer more details perhaps they would have done it from the get go. So the trick is to guide them yourself by asking them the relevant questions and giving them a list of informations you might need.

For example:

• what is the operating system that was used? What browser was used and what was it's version?
• can you give us a link to a page where the issue occurs?
• what are the exact steps that need to be followed? What buttons do you click, in which order and what were the values in the inputs?

By providing a concise and useful list of questions that you need the answers to, you make both your life and the user's much easier.

2. Ask for a video

That's it. As simple as it sounds, a screenshare session or a recording can reveal details that you might not be able to discover otherwise.

I had bugs discovered by someone who used to play Counter Strike semi-competitively and was causing problems by clicking too fast. Something that I would have never reproduced myself, even with the steps (double click on a button), because I'm simply not that fast, was solved with the help of a video demonstration.

3. Describe the standard behaviour

In more than one occasion what was thought to have been bugs were simple misunderstandings on how the platform worked. Thereore, whenever I felt that might have been the case, instead of asking for details, I went on a different route.

I began by describing the standard use case and the steps they need to follow in order to achieve their result and then I waited to hear from them on what they were doing different.

And also on more than one occasion their answer was they were not aware of certain aspects or they were doing things differently,