Programming Languages Are Overrated
One of my favorite tech interview questions for more experienced candidates is, “What did you believe to be true earlier in your career that you now believe is false?”. This question can reveal a lot about growth mindset and the ability to be self-reflective.
For me, the answer has to do with the relative importance of programming languages in software engineering. When I was a junior engineer, I spent a lot of my spare time picking up new languages. Sometimes I’d study the hottest new thing, and other times I’d focus on what employers were looking for. When I was feeling a bit more academically inclined, I would explore languages that emphasized radically different approaches to problem-solving (say, Prolog). And of course, as soon as I finished a toy project or two in a new language, I would add the language to my resume — although I got away from that after a Microsoft manager told me that if he saw a programming language on a resume, he automatically felt free to ask for it to be used on the whiteboard during an interview. (These days, for resume and LinkedIn SEO that might be worth reconsidering…)
But now that I’m a bit “further along” (as it were), I’ve come to realize that
No specific programming language is going to make or break your career, project, or company.
If you look at one of the lists of “top 20” programming languages and throw out the domain- or platform-specific languages like “SQL”, “R”, or “Objective-C”, most tasks that you are likely to encounter on a typical project can be completed in any of them with no radical differences in complexity, developer velocity, or lines of code. Modern package and deployment technologies like containers provide the ability to run most anything most anywhere.
With data-based and distributed applications, the runtime performance of native code vs. bytecode vs. straight-up interpreted code often isn’t even a factor in the user’s perception. Even if you think you know one language will run faster than another, you’re probably wrong until you profile, and again for most applications that’s not even worth the effort.
And most engineers with a year or two of experience in one general-purpose programming language can easily leverage that into a new language and be sufficiently proficient in as little as a week or two.
Thus, the choice of programming language is alow-leverage across most dimensions for individual engineers as well as teams. You’d be much better off to focus your time, attention, and energy on higher-level concerns like architecture, design, or operation, or mastering a specific business domain.
Of course, there are exceptions to every rule. So what are a few reasons for choosing a programming language that are actually good?
If you’re planning to hire a lot of engineers (particularly more junior ones) and you must ramp them up in as little time as possible, it does help if you are using more popular languages that they will already be familiar with.
If you are running a large organization with hundreds or thousands of engineers, it benefits you to standardize on a small handful of languages. That makes it easier to flex resources between efforts, reuse learning and tools, and allow engineers to switch teams.
If you are working on a domain that requires specific tools, that can force you to use certain languages. If you find yourself in one of these situations, you will know it. I already alluded to “R” (for statistics) and “Objective-C” (for MacOS and iOS). Data science should push you toward Python. If you are programming a piece of hardware that only has C-language bindings, you probably don’t want to take up maintaining your own language interop layer and should just use C. And of course, web development is happening in JavaScript or TypeScript (although even that is beginning to change with WebAssembly).
Finally, let me close with a bit of career advice. Regardless of what programming language you specialize in or use every day, I would suggest that there’s an expectation in the industry that everyone can at least read (if not write) code in a Java- or C#-like style. So if you aren’t comfortable with that, it’s probably worth grabbing some resources and getting started. Feel free to reach out if you’d like some pointers!
