You do it by ruling out classes of errors, rather than one at a time, and drilling down from the ones you can't rule out. For example:

* Application code error should result in an error message somewhere.

* Application server configuration issue should occur for multiple users.

* Something happening to only one user should be caused by either their configuration or what exactly they were doing.

(And I'm sure there's more cases, but this is what's coming to mind offhand)

From another comment, it sounds like this landed in the third bucket - and better, nothing loading meant it wasn't something they were actively doing.

So it's some configuration specific to that user: Something user-specific from the database on page load, browser choice, add-ons, or - as you found - unusual (to the devs) browser usage, like zoom or multiple windows.

Obviously this isn't thorough and could be wrong depending on the situation (note I said "should" in the bullet points, not "will"), but it should help a bit. Even knowing possibilities like zoom or multiple windows is something you get from experience - now that you know it can be a problem and one of the ways it manifests, you'll know to check it next time you see something similar.

You're right, it was the third bucket. I guess you're right that experience teaches you about the potential sources of problems; it's just that I can already think of many, many such potential problem sources, and the only strategy I have is trying them out in order of likeliness.

But 10x engineer or not, there's always he risk of running into the least likely problem - or, more likely, running into one of the problems in the long tail of individually very unlikely problems. It'd be nice if one could learn to lessen the impact of those worst cases, but I guess the primary thing one can grow in is making them less frequent.