Wednesday, October 22, 2014

"Baby-ducking"

Even programmers have urban legends.  Or perhaps, more appropriately, Arthurian legends--at least in the sense that they may be based on something that happened at the misty edges of recorded history.  One of those legends concerns the origins of the term "rubber-ducking," which is short for "rubber duck debugging" or "rubber duck problem-solving."  The basic premise is that the mere act of describing (to someone else) the context of the problem, the problem itself, and what (thus far) hasn't fixed the problem, you force yourself to slow down your thinking enough to arrive at the solution before you even finish your monologue.

I tend to be more an intuitive thinker than a methodically analytical one, so I can totally vouch for this method working.  And not only for computer problems, I should note. 

But there's a term not currently in cant use within the programmer world (though it should be), and that's "baby-ducking."  As in the way baby ducks are known to recognise the first larger thing they see as "Mom" when not reared by their own kind.  (Ducks not the only bird--or even animal--that does this, but somehow they have become synonymous with the concept of "imprinting.") 

A similar phenomenon can be observed with new programmers where languages or frameworks or even tool-sets are concerned.  The first one they are taught is the Last Word On The Subject, and everything else is either a rapidly fossilising anachronism or an over-hyped flash in the pan.  Mercifully, very nearly all of them outgrow it and learn to accept programmers of other languages as siblings.  Mainly because they have no real choice--things just evolve too darned rapidly to stay employed/employable otherwise.   (That, and a good programmer is a curious programmer, which will soon tempt them beyond their comfort zone.)

There are, naturally, exceptions.  A programmer willing to learn and keep current with every last quirk of Structured Query Language (a.k.a. SQL) could conceivably become indispensable in a large enterprise for a decade or more.  Similarly, the C and C++ programming languages have been around since the 1970s and 80s, respectively.  Yet they're enjoying a new vogue in embeddable platforms like Arduino.

In general, however, my considered opinion is that it is a Very Bad Idea to hire a new programmer who only knows a single language...unless you intend to train them in another.  While the idea of a prefabricated (and, let's face it, cheaper) skill-set might seem like a good idea, chances are you're creating your own monster.   So when your project suddenly has to retool for whatever curve-ball Apple or Microsoft or Adobe (or whomever) has just thrown, and the resistance to change ranges from passive-aggressive subversion to pitchfork-brandishing rebellion...  Welp, I don't think you need to look any farther than the mirror for the person to blame.  Sucks to be you.