Nathan Eisenberg wrote:
To: Jeroen van Aart <jeroen@mompl.net>, NANOG list <nanog@nanog.org> Subject: RE: Looking for a Tier 1 ISP Mentor for career advice. Date: Wed, 4 Jan 2012 22:25:40 +0000
Say a coder gets confused when /tmp fills up and being unaware of this thing called a "search engine" and instead will virtually cry "help my puter b0rked, I stuck!" and vice versa.
Hah! In my experience, this phenomenon is not unique to coders, sysadmins, or any other specialization. People prefer to look to other people for their answers. This one has bugged me for a long time, as I'm not sure what to attribute it to - is it a desire to be social, or to have the answer personalized? Is it a compliment indicative of respect of ones peer, or is it an indication of laziness?
This phenomona has been recognized for, well, "forever". The 'reasons' are codified in 'traditional wisdom' like "two heads are better than one", or the modern "The solution to the most intractable problem is immediately obvious to the first unqualified observer." When ones own way of lookinng at a problem isn't working, it is necessary to find a "different way of looking at the problem". The most efficient way to do that is talk to some who thinks differently than you do. "Search engines" are good for finding facts; 'less good' for finding abstract/concept info -- It's much harder to formulate a search query to find something to 'fill in the blanks' in an _incomplete_ conceptualization. If yu can foumulate the search for "what you're missing" the search probably contains the answers you're looking for. Also, the act of 'organizing ones thoughts' to explain the problem to someone who is *NOT* familiar with the background of the problem can lead to _self-recognition_ of the solution. I have phoned a collegue, many times, and/or had a collegue phone me, where the _one-sided_ conversation has gone; <-- "Hello?" --> "Hi! I've got a problem. like _this_ {launches into description}... OH!! never mind, the light just dawned!" <-- "<chuckle> Glad I could help." "Troubleshooting", however, _is_ a special case situation. I can pontificate on this at some length. You have been warned. <grin> Troubleshooting problems is an 'art', not a 'science'. Either you know how to do it, or you don't. And, like any other "art", you can't teach it; you _can_ teach 'mechanics' that help people who have an 'instinctive' (for lack of a better word) grasp of the subject "do it better". But the _ability_ has to be there in the first place. It's similaar to integral calculus -- you have a result, and are looking for the question. (Remember how _hard_ integration was -- until the 'AHA!' moment when, all of a sudden, it all made sense. And you were shaking your head wondering *why* you had so much trouble 'getting it'.) Troubleshooting is much the same. If you've seen "that" problem before, you have an idea of what -may- be causing it. And can start checking for the existing of each possible 'what' that you know about. With experience, you know _which_ "what" is most likely and to start there. Also, what _additional_ things to check, to narrow down the list of 'possibles'. 'Search engines' are good when you have a 'question' and are looking for looking for an 'answer' (like 'differential calculus', to use the math metaphor). But they're "medium lousy", at best, at finding the 'question' that fits the 'answer'. There are some major attempts being made to build computers that _can_ reverse engineer the 'question' from an 'answer'. See 'Watson' -- the IBM research computer project that plays as a contestant on "Jeopardy!" The latest incarnation 'does good' a lot of the time, but when it's wrong it is *very* wrong. I don't think I've ever seen it be 'close, but incorrect'.