The easiest way to start a divisive conversation within a group of engineers is to start talking about which programming language, operating system, or software tools are the “best.” Well, like most things in life, if anyone asks you which of any of the aforementioned items are the “best,” the only correct answer is “it depends.”
Right now, I’m working with very large quantities of data. Our install base on mobile devices alone just surpassed 80 million, and it was at 30 million just over a year ago. Basically, if you were to say that our mobile user base is growing polynomially, then you could say that the quantity of data we have to analyze from both our mobile and web applications together is growing at an almost exponential rate.
As a result, much of the work my team does involves extracting that structured and unstructured data using SQL, bash scripts and a variety of command line tools, transforming that data by using Hadoop to run a variety of MapReduce jobs written in Python in order to filter and structure all of our data into a format that’s more conducive to analysis, and then using tools like Google BigQuery to analyze that data via a variety of algorithms and heuristics, and then providing insights to decision makers within our company.
As a result, I’m currently working on my current project almost exclusively within the confines of Mac OS X and Ubuntu in conjunction with Python, SQL, bash scripts, a variety of unix command line tools, and Google BigQuery. Why? Because those are the tools that our team deemed to be the best for the job at hand given a variety of factors including the project’s budget, requirements, team size, etc.
The last project I worked on involved writing a number of regression tests for our RESTful API. So I was constantly spinning up virtual machines on Amazon EC2 via Capistrano scripts and wrote a good deal of node.js code to enhance our suite of asynchronous unit tests.
Prior to that I spent some time working on our Android team to upgrade the library that the application used to access our RESTful API since our API was undergoing a major upgrade. And so, while on that project I spent all of my time writing Java code in Eclipse.
Before that, when I first joined the team, I was asked to essentially build a new Windows Phone application from the ground up to compliment our offerings on iOS, Android, Blackberry, and J2ME. As you might imagine, I spent all of my time working in C# within Visual Studio on Windows 7.
Every one of those decisions was made solely on the basis of pragmatism. In each case, our leadership team first identified a business need, laid out the requirements, and allocated a budget for the project. Then the engineer(s) assigned to the project identified the best tools for the job and worked closely with the design team to craft the best user experience possible.
If you want to be a good engineer, leave your snobbery at the door. If you walk into a project looking to shoehorn a particular technology into the solution, then you’re no longer truly acting as an engineer, instead you’ve allowed yourself to become a *bad* salesperson (good salespeople don’t do that). Chances are that you’ve done this before to some degree, but don’t feel bad, because we all have at some point in our academic or professional careers regardless of whether we realized it or not.
PS – There’s nothing wrong with wanting to learn new skills. That’s why good engineers work on side projects in their spare time. For instance, I recently purchased a Microsoft Windows Kinect, and I plan to experiment with the SDK using C# and C++