| my testing routine included giving it a try in Private Browsing
The 10X programmer (or in this case the 10X bug fixer) has a testing routine that sufficiently covers enough logical scenarios such that they're able to converge on the truth at a 10X speed.
It's basically the same reason why Guess Who is a game. Some people ask better questions that allow them to eliminate irrelevant details at a faster rate.
Had that not been the case, though, there would have been no indication to try using it with multiple windows open, as the error was a general "nothing loads", which is the result of an error condition anywhere in the code.
What I do know is that my programming style is to really dig into every new project I have to work with. Maybe not every part of an application, but everything relevant to the feature I care about. I'm an incredibly judgemental reader (this is sad for personal reasons) and as such, I come up with long lists of "I don't think this would handle that scenario." I don't have time to dig into them, but that list stays there in the back of my mind -- a vague sense that a loop wasn't accounting for a particular kind of array value, etc, etc.
Inevitably, months down the line, some of those bugs surface as actual things. I keep an eye out on tickets, or listen during stand-ups, and I only have to remember just enough of that problem to cut out the investigative time. Eventually I become the person everyone goes to to get them up to speed on any problems within any of the features I've worked in, over people with much more seniority on the team, or often even the people who are responsible for that project. This is also how people seem to always think I've been around twice as long as I have.
I'm not a 10x engineer -- I find it incredibly difficult to stay "on task" and that massively kills my productivity. But the way I approach codebases, outlined above, is just one of many tactics that can, in the right environment, make a programmer far more productive/useful than they would otherwise be.
I guess that's also an additional argument for not being the only person working on a codebase - it's far harder to read it judgmentally if you wrote it.
UI dev/QA is a bit different but this is how things typically go in sysadmin-land. A good engineer can hear a description of an issue and immediately pinpoint one or a few seemingly unrelated potential underlying issues to test. This is just a combination of experience and a deep knowledge of the underlying systems and processes that make things happen. The tough part is that this isn't something that's "teachable" -- some guys just "get it", others, while having superficial knowledge of the infrastructure, just can't seem to be able to mentally walk though a system or process and identify where the trouble might be originating from.
I don't think that would be possible, because there are literally hundreds of potential errors that could have the described behaviour as a result.
* 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.
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.
They also might have looked at the code and said "oh hey, that won't work with multiple windows, I'll just change that".
In this case, I was also the person dealing with the person reporting it. Having had to close it with "cannot reproduce, won't fix" would have been a pretty disappointing outcome, and would make it really hard to discern between a 10x engineer and someone who's just bad at debugging...
I'm not quite sure I understand your point.
"Dramatically more effective" does not mean "dramatically more effective in every single scenario you can think of."
This one had me baffled for a bit, though, and I was fearing having to spend a couple of days on tracking it down - or having to give up. Sometimes those happen, and it'd be great if there are ways to have that happen less often.
What lessons about our architecture could we draw from this? What kind of test suite should we write?
So... At the start of this week I was trying to solve a bug that only occurred when someone had multiple browser windows open. I usually have just one browser window open.
The person who reported the bug did not mention that they had multiple windows open (and why would they). I got lucky when trying to reproduce it: my testing routine included giving it a try in Private Browsing, which meant opening another window.
If I had not done that, I would not have been able to reproduce the bug. How would such a dramatically more effective programmer have been able to reproduce that bug more quickly?
(Also note that the symptoms did not indicate anything relating to multiple windows. The report was simply: nothing happens when I try to run it.)