5 ms·

A 10x programmer would read the description of the bug, and from their knowledge of the codebase think "hmm, that should only happen when you have X loaded mult

A 10x programmer would read the description of the bug, and from their knowledge of the codebase think "hmm, that should only happen when you have X loaded multiple times at once making Y happen..." then go on to immediately test and repro with two windows open. 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.

Vinnl 7y ago
> A 10x programmer would read the description of the bug, and from their knowledge of the codebase think "hmm, that should only happen when you have X loaded multiple times at once making Y happen..." then go on to immediately test and repro with two windows open. 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.
- Izkata 7y ago
  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.
  - Vinnl 7y ago
    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.

Vinnl 7y ago

> A 10x programmer would read the description of the bug, and from their knowledge of the codebase think "hmm, that should only happen when you have X loaded multiple times at once making Y happen..." then go on to immediately test and repro with two windows open. 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.

Izkata 7y ago
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.
- Vinnl 7y ago
  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.