[4] Thanks to Zack Davis for noting that the “good with computers” trait seems to be substantially about the willingness to play around and figure things out.
grimAuxiliatrix [GA] began trolling twinArmageddons [TA] ... TA: 2ee the menu up top? TA: fiiddle around wiith that tiil you open the viiewport. GA: I Did Fiddle With It GA: To No Avail TA: iif you cant fiigure 2hiit out by fuckiing around you dont belong near computer2.
(twinArmageddons has a “typing quirk” related to the number 2; if you didn’t get it, ‘2’ looks like a reversed ‘s’.)
As a professional programmer, I should note that there’s a good kind of blankness—the state of no assumptions, which you should reset your mind to when attempting to figure out a novel problem. Many more things can go wrong in programming than in plumbing, and assuming that you know something about the root cause without sufficient evidence can lead you into a blind alley. Just today, I diagnosed a bug where make_pair(y, z) in user code began failing to compile. This was poorly written to begin with (it should always have been written as make_pair(y, z)), but the original 1998 and 2003 C++ Standards said that it should work anyways—and it did for years. Then the new 2011 C++ Standard changed the definition of make_pair() in such a way that, in general, make_pair(y, z) will fail to compile. (This is intentional—that code is “bad”, and the make_pair() change has other consequences which are very good. The needs of the many outweigh the needs of the few, or the one.) I verified that the Standard Library implementation had been changed in accordance with the 2011 Standard, and almost said “case closed” and sent my E-mail. I had seen this before, and I knew that this was an identical manifestation.
Right before hitting Send, I had second thoughts and took another look. All of my previous analysis was correct, but this case was special (and unlike the previous case I had seen). In this code, make_pair(y, z), y’s type Y was different from X. (X was unsigned int and Y was int—very simple types, I’m just abstracting it further. Despite appearances they are unrelated as far as we’re concerned here, so X and Y are probably better to think about.) The previous case I’d seen had identical types. With different types, successive drafts of the Standard have said different things:
1998/2003: This should compile and work.
2011 v1.0: This should compile and work, but other cases will eat your brains.
2011 v2.0: No brain eating! This shouldn’t compile, and neither should those other cases.
2011 v2.1: The best of both worlds: this should compile and work, but those other cases shouldn’t eat anyone’s brains.
The final piece of the puzzle was that the compiler in question had implemented 2011 v2.0, but not yet v2.1. So the correct thing to do was to change the user’s code, and open a compiler bug.
If I had been slightly more distracted/tired, less caffeinated, or (most perniciously of all) more supremely confident in my cached past analysis, I would have arrived at an incorrect conclusion. Instead of making a last-second save, if I had started from a blank slate, I would have been much more likely to notice X != Y and its interaction with the changing Standardese and compiler implementation.
It should be lightness, not blank slate. Some hypotheses are clearly better than others, but one shouldn’t typically be confident in things that were not observed with sufficient clarity, which means constant search for experimental tests and alternative explanations.
Programming is probably the most intensive mode of application for basic scientific method, by the sheer volume of hypotheses and experiments required to get anything done.
Good post—upvoted!
Quoting Homestuck:
(twinArmageddons has a “typing quirk” related to the number 2; if you didn’t get it, ‘2’ looks like a reversed ‘s’.)
As a professional programmer, I should note that there’s a good kind of blankness—the state of no assumptions, which you should reset your mind to when attempting to figure out a novel problem. Many more things can go wrong in programming than in plumbing, and assuming that you know something about the root cause without sufficient evidence can lead you into a blind alley. Just today, I diagnosed a bug where make_pair(y, z) in user code began failing to compile. This was poorly written to begin with (it should always have been written as make_pair(y, z)), but the original 1998 and 2003 C++ Standards said that it should work anyways—and it did for years. Then the new 2011 C++ Standard changed the definition of make_pair() in such a way that, in general, make_pair(y, z) will fail to compile. (This is intentional—that code is “bad”, and the make_pair() change has other consequences which are very good. The needs of the many outweigh the needs of the few, or the one.) I verified that the Standard Library implementation had been changed in accordance with the 2011 Standard, and almost said “case closed” and sent my E-mail. I had seen this before, and I knew that this was an identical manifestation.
Right before hitting Send, I had second thoughts and took another look. All of my previous analysis was correct, but this case was special (and unlike the previous case I had seen). In this code, make_pair(y, z), y’s type Y was different from X. (X was unsigned int and Y was int—very simple types, I’m just abstracting it further. Despite appearances they are unrelated as far as we’re concerned here, so X and Y are probably better to think about.) The previous case I’d seen had identical types. With different types, successive drafts of the Standard have said different things:
1998/2003: This should compile and work.
2011 v1.0: This should compile and work, but other cases will eat your brains.
2011 v2.0: No brain eating! This shouldn’t compile, and neither should those other cases.
2011 v2.1: The best of both worlds: this should compile and work, but those other cases shouldn’t eat anyone’s brains.
The final piece of the puzzle was that the compiler in question had implemented 2011 v2.0, but not yet v2.1. So the correct thing to do was to change the user’s code, and open a compiler bug.
If I had been slightly more distracted/tired, less caffeinated, or (most perniciously of all) more supremely confident in my cached past analysis, I would have arrived at an incorrect conclusion. Instead of making a last-second save, if I had started from a blank slate, I would have been much more likely to notice X != Y and its interaction with the changing Standardese and compiler implementation.
It should be lightness, not blank slate. Some hypotheses are clearly better than others, but one shouldn’t typically be confident in things that were not observed with sufficient clarity, which means constant search for experimental tests and alternative explanations.
Programming is probably the most intensive mode of application for basic scientific method, by the sheer volume of hypotheses and experiments required to get anything done.