Ted Dzuiba wrote a post that boiled down to identifying his own “language bigotry” as a step along the way to software engineering “Mastery”.
He’s absolutely correct about introspecting why one chooses to “fight” other languages. And by saying “languages” I could substitute OS platform, cloud computing, database manager, code editor, car manufacturer, religion, Constitutional Rights, regional sports team, patriotism, etc.
We identify ourselves by our passions and beliefs. As a means of vetting prospective employees, I have long made a habit of asking candidates “what are you?” The answers over the years include things like “mom”, “Catholic”, “firefighter”, “LARPer”, “Mac geek”, “soldier”, “Cisco network engineer”, “hunter”, “professional juggler”, “Red Sox fan”, “clergy”, “MySQL admin”, “mountain climber”, “Chevy nut”, “Java programmer”, and on and on. When someone identifies themselves as a something you can pretty safely assume some other things: A “Red Sox fan” most likely loves baseball, hates the Yankees, also likes the Patriots [American] football team, and is located or grew up in the New England region. A “hunter” most likely feels strongly about their Second Constitutional Amendment Rights, votes centrist or right on the political scale, dislikes leftists, also enjoys the outdoors, probably fishing, and most likely desires to live somewhere more rural than more urban. Everything there is a prejudice for or against something, and it’s perfectly natural. (And yes, it’s stereotyping: that’s how we templatize correlated attributes, please carry on)
The key to finding a good employee is sussing out which of those will get in the way of delivering business value. The key to being a good employee, is introspection about why you have those feelings and if they’re relevant. As Ted says perfectly (I emboldened his italics):
I feel orders of magnitude more useful delivering business value than I feel delivering code.
A clutch statement right there – it’s not about the tools, it’s about the product and its value. I’m not advocating, and I doubt Ted is either, that any intelligent engineer should just clam up and do as they’re told – if there is value or purpose to moving against the grain, then speak up! Your value as an engineer is only partially what is produced, and constructive engagement debating how something is produced is exceptionally important as well. But know when your beliefs- your prejudices- are pointlessly in the way. Introspect on why.
My most recent position requires the use of an Apple Macintosh (gross), is completely hosted using Amazon Web Services (ick), systems scripts almost entirely written in Ruby (*twitch*): all of which I knew in advance of accepting the position. I don’t prefer a single one of those things, but would it have been a better position if they used HP laptops running Linux, had a hardware server farm, and churned out klocs of Perl? Nope. Would it be a better business? Not at all. So I use a Mac for hours a day, architect in concert with AWS’s strengths and weaknesses for hours a day, write Ruby for automation as needed, and am perfectly at peace with all of that.
Sure, I still run Linux on my own hardware, remind my colleagues that if we ran our databases on hardware vs. “the cloud” we wouldn’t have “that” problem (for whatever the problem might be), and occasionally sneak in a quick Perl script that would have taken three-to-six-times as long for me to write in Ruby (not necessarily Ruby’s fault) – but not at the cost of value.
A bad workman complains about his tools. A craftsman works with what is at hand.
