Ninja Programmers Wanted: Drupal Ninja. Ninja IA. mySQL Shinobi. HTML5 Super Ninja.
I was hoping this trend would have died a few years back when it began but in doing some recruitment scouting for an open developer position we have at my company I ran across the dreaded monkier again, and again, and… again!
Why this dark crusader has become the mascot for the technology community I do not understand. I, for one, don’t want shinobi anywhere near the precious code that inherently provides my income. There is nothing historically correct in hiring a ninja programmer unless your goal is to bring on-board the Anonymous hacker collective.
The cache of looking for, or calling one’s self, a ninja programmer is most likely born out of a lack of self-confidence. Any attempt at over-qualifying anything usually by trying to be hip reeks of insecurity and none moreso than terms like rocksar, guru and the dreaded ninja. Hiring managers do it because they aren’t confident in the description they cobbled together of a “does everything developer” and programmers do it because they aren’t comfortable enough in being called just that.
Ninja have that idyllic comic book imagery treading somewhere between some ironically hip turtles and how Storm Shadow was G I Joe’s variant of the idollic Boba Fette. Attaching one’s self (or job description) to such a nerd driven dynamic somewhat makes sense, except in the fact I don’t really want to hire Giant Ninja Koopas or Urban Jersey Ninja She-Devils, sorry folks.
Ninja emerged as mercenaries in the 15th century during the Sengoku period in Japan, particularly within the Iga and Kōga clans, and were primarily recruited to act as temporary covert operatives for espionage, reconnaissance, assassination, sabotage and terrorism.
A cursory dissection of that list provide core traits that are not exactly at the forefront of my needs list. There isn’t a redeeming trait among the definition of what constitutes an actual ninja or their deeds and yet, we signify to our own coding recruits we value these?
I find it’s particularly demoralizing personally when taking into consideration one important, internationally recognized definition: “is motivated to take part essentially by the desire for private gain with no originating allegiance to mission other than contracted material gain.” That is mercenary as paraphrased to remove the arm conflict references from Protocol Additional to the Geneva Conventions 1977 Article 47 and the United Nations ICARUFTM Article 1. Don’t like that one? Random House: “working or acting merely for money or other reward; venal. grasping, acquisitive, avaricious, covetous.” Collins: “influenced by greed or desire for gain” and “any person who works solely for pay.” And, here’s one final for good measure: Douglas Harper Entomology: “late 14c., “one who works only for hire,” from L. mercenarius “one who does anything for pay,” lit. “hired, paid,” from merces (gen. mercedis) “pay, reward, wages,” from merx (see market). The adj. is recorded from 1530s.”
Look at the time frame of the final reference and note while the Japanese language was creating the word shinobi Western language was simultaneously doing the same with the word mercenary, which is why I want to hammer the point home about the two being synonyms. Mostly, we’re hiring programmers as part of a team. Someone we can rely on for the longer term. Someone who will be vested in the projects they are part of. Someone who will provide real value in the development cycle. If you need a temp hire, a contractor, a freelancer, that’s fine, but typically that’s not what I see attached to the job descriptions and it’s certainly not applicable to most of the dev teams I rely on day-in and day-out to create a visionary value proposition for the end consumer.
However, lets not stop there.
Covert operatives work in stealth outside of the normal authoritative controls. Although we would like our coders to break conventions and do things differently in order to problem solve, the overall mission of CovOps in the military is more akin to, say, the United States Department of Defense “an operation that is so planned and executed as to conceal the identity of or permit plausible denial by the sponsor” or the more complex legal definition found in 50 USCA S426. Do you really want your programming team to work covertly with that in mind? Perhaps if you are a manager who fears responsibility that’s exactly what you want. Otherwise, you want to know what your team is tearing down or building code wise with full internal transparency. That’s essentially the opposite of the ninja normalcy which is all about secrecy.
Espionage, commonly referred to as spying, and reconnaissance could be viewed within the lens of a positive when it comes to perhaps the hacker mentality of dismantling other people’s code to provide insight into optimizing one’s own. If you are a company seeking clandestine intelligence gathering one might have to question your moral and ethical position and if you are recruiting openly for one remember, if someone is willing to engage in it for you, who’s to say they wouldn’t just as easily sell your secrets. After all, that’s the classic double-agent sting and definitely not outside the realm of the ninja’s shadow world. Besides, with many programmers leveraging the community for answers and the value of open source code there are few instances where true industrial espionage is going to be anywhere near the mindset of most programmers responding to your advertisement, and those that it might be probably signed non-compete and non-disclosure agreements to begin with.
Assassination and sabotage: I’m not quite sure how you want to try and rectify these, actually. Is there something reasonable you can parallel between your programmer and the ninja? Is it the assassination of buggy code you’re after? Is it the terrorism we are looking for? Striking fear into our enemies (technology rivals and indirect competitors) through intimidating code, extraordinary user experience and overall brain-bending flexibility of our staff. Yeah, somehow I just don’t see most of the staffs I’ve worked with suddenly becoming Iron Man and casting fear and dread over anyone. Actually, that’s not even the environment I’d want to foster within the team.
Maybe I lack imagination when I am dissecting the need for a code ninja.
Since good and bad are largely subjective and ninjas and mercenaries have been employed by all sides of conflicts over the millenia perhaps it is the other attributes that ninja possessed which make them uniquely viable as a metaphor as a code warrior.
Mastery of the craft could be any number of positive references and isn’t solely just a ninja. Same with economy of effort, resourcefulness and confidence. Being able to work both independently and within the context of a group too is a dynamic many employ.
Perhaps it is resourcefulness since ninja are supposedly legendary for their unorthodox problem solving skills (as applied to the other acts they were hired for). Perhaps it is that they were men of mystery. Those who were not visible in the action but were responsible for action. But gain, I feel like there are so many comparisons that are less corny and cliche that could be made and are overlooked because they aren’t nerdy enough, or maybe too nerdy?
Perhaps it is something I’m overlooking that someone can fill me in on, but from what I understand as the traditional use of a ninja I am having a difficult time qualifying why I would want one in charge of my code. That is, probably, until I receive SCI clearance and run tactical technical teams… and we ALL know that ain’t gonna happen!