Too many times to ignore now, I’ve heard managers or recruiters say that any good engineer is interchangeable with any other good engineer. “Sure,” they might say, “the lead engineer chose F# for this project, and there aren’t a lot of F# developers out there, but really any good developer with a couple years experience behind them will be just as good.” Another one I’ve heard goes something like, “Oh I know they’re front end, but we need them on the back end for now. They’re a good developer; it shouldn’t be a big deal.” If you believe that, not only do I have a bridge to sell you, I’m founding the next unicorn startup selling ice to Eskimos! One billion valuation soon, I’m sure! Just invest right here. Seriously, the idea that “good” software engineers are interchangeable is not true. I wonder sometimes about working in software. Do I just have to write on my resume that I have a “proven track record for ramping up on new technologies” and — boom! — I can go anywhere? I can’t believe I’m about to explain this, but let’s take language differences as a starting point. I have actually put code into production in a variety of languages from Scala to C# to Java to JavaScript. Even though I am able to pick up any C-like syntax in a few weeks, and others given more time, I know better than to think that I can just dive in head first to a production code base in a new language. What about industry or business context? I’ve worked in my fair share of them, including health, ecommerce, education, and telecommunications. Should I consider myself qualified to work in social media? What about manufacturing? Aerospace? Cryptocurrency? How far can I stretch the imagination? The same goes for a situation where I’m being asked to make the transition from web to mobile or desktop or IoT. Let me relate a small story. Last year, while working full time as a backend Java web services engineer, I also worked on a team implementing a mobile app in the Ionic Framework, which is an amalgamation of Angular, TypeScript, and some custom libraries. It wasn’t until near the end of the eight month project that I was comfortable doing things the Ionic/Angular/TypeScript way. “Comfortable” may be a generous description, actually. It never stopped feeling weird to me that I should make fields in a controller public just because they needed to be displayed in a view or that constants should be named the same as other variables. By the way, if you want to have static typing in JavaScript you’ll soon discover you can’t carry it very far. Get that “any” type ready! I loved the RxJs subscribers we used, though. At the end of the project, I went on my merry way. It would never occur to me to go around calling myself a TypeScript or a mobile developer now. This isn’t out of some kind of language snobbery. It’s a simple issue of experience: eight months isn’t enough to make that claim. And I’d bet that anyone who has been programming full-time would agree. A developer who has devoted a couple years to a certain language is going to be able to think in that language effortlessly. She’ll have ready access in her mind to all the resources necessary to Get Things Done and move on to the next task. She knows the language landscape and can easily combine standard and third-party libraries into one cohesive new functionality that solves the problem at hand like a key solves a lock. Yet without knowing what’s available, she reinvents the wheel, or worse, she’s at a complete loss. Every language is surrounded by its own idioms, build and dependency management tools, frameworks, libraries, online communities, IDE’s, and more — things which in daily practice have a much higher impact on developer productivity than we think. But hey, it’s all the same right? I mean, C# vs. C++ developers, what’s the difference? Pound and plus signs yadda-yadda. No big deal! Throw ’em to the lions! Now, I’m not saying that no one should ever switch languages, industries, or devices. I’m just saying that programmers are all different. A software team which writes a primarily F# app will not benefit much from my Java experience, even though I’ve spent a good amount of time writing Scala. I’m just saying that we can’t find all the “good devs” and randomly shuffle them off to different teams at management’s whimsy. I’m saying, let’s not treat all “good” developers as interchangeable. The myth of the interchangeable developer is wrong. Long live our differences, and may the best person for the role find it!
